Jump to content

Major conflict between XControls and LVClasses


Recommended Posts

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.