Major conflict between XControls and LVClasses

[Aristos Queue]

The following bug exists in 8.2 and 8.5. It will not be fixed in the next release of LabVIEW.

If loading an XControl triggers the load of any VI that uses the XControl (either by hosting on the front panel or using property/invoke nodes on the block diagram), then the VI that loads will be broken. In the vast majority of cases, this is an expected break of the VI because it is a recursive use of the XControl (such as hosting the XControl on its own Facade VI). Clearly such VIs cannot be expected to run.

However, when an XControl uses a LV Class, the class will load all of its member VIs, which might use the XControl. Since the XControl doesn't actually use the particular member VI, there is no recursion, and customers might reasonably expect that the VI would not be broken. However, because XControls are expected to be runnable even when the VI that hosts them is in edit mode, we actually end up breaking the member VI as it loads into memory because it wants to run the XControl, but the XControl is not finished loading itself.

A user might go for a long time without noticing this break, because as soon as you edit any VI related to either the class or the XControl, the member VI will notice that now the XControl is fully loaded, will recompile itself, and thus be good. The only symptom that would be noticed during development is a VI that always has unsaved changes because the VI had to recompile.

But when you try to load the app and run it without making any edits, or when you try to build it as a built application, then you run into problems. This might be quite late in your development cycle, when it would be really frustrating to change your architecture.

To avoid this problem, if your XControl uses a class, do not use the XControl in member VIs of the class. If your class uses an XControl, do not use the class in the XControl AND do not make the class a sublibrary inside the XControl (because libraries always load their sublibraries, this results in the same load order problem described above).

The changes necessary in LabVIEW to fix this load ordering problem are extensive. LV R&D cannot predict what release of LabVIEW will have a fix for this bug.

[Tomi Maila]

Hmm... this might explain some weird issues I had with XControls. I did never have time to investigate them in more detail.