X Control Distribution (Bug?)

[jgcode]

Hi Jim

Can you ammend CAR #236395 with this?

AQ said: "Just as important: The Data.ctl and State.ctl of that XControl should *not* show up in the auto built palette"

Cheers

-JG

[Jim_S]

Hell JG,

I was able to reproduce the issue here. I will have to talk with R&D about this one but at this point, I thinking it might be a bug. As soon as I have more information about this, I will post it here.

As for the CAR I will add this in there tomorrow so we should be good there.

Finally, I looked at VI Package Manager and this is pretty cool. I'll have to spend some time looking into it. Also the VIs your VIPM files added are really cool.

[jgcode]

That all sounds like great news Jim!

I am also glad you like VIPM, as I am sure you have seen now that it is very easy to use and a very powerful way to share code (and avoid the issues I had sending you my code in another form). It would be nice if this was a standard for R&D (hmmm that gives me an Idea)

I look forward to (hopefully) creating a CAR out of the palette issue!!

Cheers again

-JG

[Jim_S]

Hello JG,

One of my colleagues found a bug that states "Any VI's belonging to a class that in turn belongs to an lvlib will display a red x glyph when placed on a palette." I am pretty sure this is your case so I added your information to it. The workaround for this is take the class out of the lvlib. This isn't much of a workaround but I thought I would tell you about it.

I appreciate all the time you put into it. This will definitely help us get these things fixed in LabVIEW.

[jgcode]

Thanks Jim

Yes.. the workaround will not help due to maintaining namespacing. 

No probs on the time, as I obviously would love all these issues above to be fixed asap.

Thank you for your time and diligence on this too.

Now some questions:

1) Can you please post the CAR for this Red X Palette bug so I can track it?

2) Is it possible to lodge:

---

@JG wrote:

3. Adding an Xctrl reference to a Class works fine in source, but broke my build at run time.

---

as a CAR as well?

I know that you have "solved" the issue I am seeing as it shows that in help, but I think this functionality is very crucial.

AQ mentioned that lodging functional issues as CARs is a good way to approach these things?

Could you please (insert begging here 🙂 ) lodge this as a CAR?

Cheers

-JG

[TCPlomp]

I don't know how you got this filed as a bug.

I tried to do that in a Beta and it was deferred. eg. not a bug.

Ton

[jgcode]

Hi Ton

Can you please specify which issue you are referring to (as their are four in this thread).

Also can you post a link so I can have a look?

Cheers

-JG

[TCPlomp]

My issue was the missing indexing of xcontrols inside user.lib. It got a car (151138), which got deferred during a beta of LabVIEW (so I cannot share a link with you, I might be trespassing by posting this info).

Ton

[Jim_S]

Hello JG,

The CAR number for the red x glyphs on VIs in a user defined palette is 185059. Sorry about that. After doing some research on "Adding an Xctrl reference to a Class works fine in source, but broke my build at run time.", I found CAR 210033 that matches this description. I have added this forum post to it for there information.

Thanks again for being patience with us while figuring out this issue. I wish we had better answers then it's a bug but now R&D are looking into them so they can hopefully be fixed for future versions.

Hello Ton,

Thanks for posting this CAR number. I looked into this one and it is very close the same issue. I have added that information into CAR 236395 so R&D knows about it. Thanks again.

[jgcode]

Thanks Ton for posting.

As always, thanks Jim for your help.

Do CARs have ETAs attached to them?

Or is it wait and see when a new release/service-pack gets released?