Error 1446: Can not change tip strip of control on reenrant instance.

[PJM_labview]

While this is a documented error (since there is a number for it) I believe this is to be bug.

If you try to change tip strips of controls located on an instance of a reentrant VI you get that error (1446). I have no clue as to why this is not possible and I am considering this to be a bug.

Note: Attempting the same operation on the "Master" copy of the reentrant VI does work.

PJM

Note: This issue is present in LV 8.2x and 8.5.

[Aristos Queue]

It is not a bug. The reentrant clones are able to support their own panels/diagrams without significant loss of performance because they share large quantities of properties with the master. If you want to start with one VI and do such edits as changing tip strips, start with a VI Template and instantiate from that. Template instances are independent of the original .vit.

[Michael Aivaliotis]

Yes! I won the bet.

PS. This is bad and is definitely a crappy limitation.

[Jim Kring]

QUOTE (Michael_Aivaliotis @ Mar 17 2008, 04:36 PM)

Yes! I won the bet.

PS. This is bad and is definitely a crappy limitation.

I agree. If performance is the issue, then there should be some setting that toggles between these two extremes: clones used for programmatic functionality vs. clones used for user interfaces. Rarely do I care about gray areas in between these two extremes (except when debugging instances).

[PJM_labview]

QUOTE (Aristos Queue @ Mar 17 2008, 03:34 PM)

It is not a bug. The reentrant clones are able to support their own panels/diagrams without significant loss of performance because they share large quantities of properties with the master...

Ok, then, the documentation for Tip Strip is lacking since there is nothing about it not working in reentrant instances (See screenshot below of LV 8.5 help window for this)?

http://lavag.org/old_files/monthly_03_2008/post-121-1205802109.png' target="_blank">

One can argue that there is a bug in the documentation (at the very least). There should be a line like "Available with reentrant instances --> No".

I was not aware of these limitations of using reentrant VIs as reusable UI, but since this is the case, where can I find a list of all the properties (and methods if any) that do not work in reentrant instances?

PJM

[Aristos Queue]

QUOTE (PJM_labview @ Mar 17 2008, 08:05 PM)

I was not aware of these limitations of using reentrant VIs as reusable UI, but since this is the case, where can I find a list of all the properties (and methods if any) that do not work in reentrant instances?

No such document exists. No one has asked for it until now. But I can summarize it pretty easily: If the property/method would cause a change that would be saved with the VI, that operation is not allowed on a clone. No "make current value default", change control to indicator, changing labels/captions, etc. They're called "reentrant clones" for a reason, and I don't think you've been led astray. Again, if you don't want clones, use .vit files.

File a documentation bug report if you want this documented in a future LV version. It won't be an easy thing to document -- there's no line item for that in the configuration of new properties and methods, so someone would have to run each individual property/method and determine whether or not it worked on a clone. That's pretty tedious work that probably wouldn't get a lot of priority.

[Jim Kring]

QUOTE (Aristos Queue @ Mar 17 2008, 07:40 PM)

No such document exists. No one has asked for it until now. But I can summarize it pretty easily: If the property/method would cause a change that would be saved with the VI, that operation is not allowed on a clone. No "make current value default", change control to indicator, changing labels/captions, etc. They're called "reentrant clones" for a reason, and I don't think you've been led astray. Again, if you don't want clones, use .vit files.

File a documentation bug report if you want this documented in a future LV version. It won't be an easy thing to document -- there's no line item for that in the configuration of new properties and methods, so someone would have to run each individual property/method and determine whether or not it worked on a clone. That's pretty tedious work that probably wouldn't get a lot of priority.

If modifying tip strips is editing a VI, then how come we're allowed to do it at run-time? IMO, the design of the tip strips feature is flawed (design bug). I can understand how changing the default value of a tip strip should not be allowed in clones, since default values are necessarily persistent. However, changing the tip strip's current value should certainly be allowed, just as we can change a control's value, run-time menu items, context menus, etc.. It seems to me that any VI/Control property which can be changed at run-time that is also considered a modification that can't be performed on a clone should be broken out into default value and value. :2cents:

[PJM_labview]

QUOTE (Aristos Queue @ Mar 17 2008, 08:40 PM)

...Again, if you don't want clones, use .vit files...

Ok, so I gave a shot back to the old fashion way using .vit. Not considering that they are a pain to work with (can not instantiate instance when template is in memory) I think I will have to go back to using clone (with no tip strip ) because of performance issue. Basically the "Open VI Reference" takes about 800 ms to complete (and this is on a fairly recent machine [core duo]). This is really noticeable in the UI (The UI Opens copy of itself upon user action), and does leave the user with a "this UI is so sluggish" aftertaste.

Note:

• This UI (vit) is not big (~280Kb).
  
• For comparison, the "same" instantiation process with reentrant clone using a static VI ref takes 1 to 5 ms.
  

I think revisiting the "Tip Strip are not working in reentrant instance feature" would be a good thing. :2cents:

PJM

[Aristos Queue]

QUOTE

For comparison, the "same" instantiation process with reentrant clone using a static VI ref takes 1 to 5 ms.

And *why* are you able to get speed and performance from the clones that you can't get from templates? Because they share just about everything with the original master VI. There isn't a separate copy made -- they share the data directly for pretty much everything except the operate data of controls/indicators and the flags for which wires have breakpoints. That includes the tip strips. If we were going to have independent tip strips, we would have to have independent controls to host those tip strips, which means independent panes to host those controls, which means independent front panels, which basically means template VIs.

Some readers are now ready to jump in with something like, "or you could store the tip strip in the dataspace and then change the code for the master VI so that tip strips are always looked up in the dataspace instead of being a part of the control." Under that scenario, we've now expanded the size of the dataspace (so that there's more info to clone even for those clone VIs that never show their front panels), and we've included the tip strips in the part of the data that has to download to realtime and other targets (where panels don't exist), etc, etc, etc. The tip strip data belongs with the front panel. The front panel is single sourced for performance, performance that 99% of the time, users greatly appreciate.

LabVIEW generally does a pretty good job of hiding the "computer science" aspects of programming from you, but this is one of those times when you just have to accept -- if you want independence, you have to be willing to pay the time expense to make the copy. Or, in the words I once heard it described, "Wishes come true, not free."

[PJM_labview]

QUOTE (Aristos Queue @ Mar 20 2008, 11:48 AM)

And *why* are you able to get speed and performance from the clones that you can't get from templates? Because they share just about everything with the original master VI. There isn't a separate copy made -- they share the data directly for pretty much everything except the operate data of controls/indicators and the flags for which wires have breakpoints...

While this is probably part of the performance issue, I am suspecting that the fact that it is not possible to instantiate a vit instance while the template is in memory is probably also reponsible for the performance issues I am seeing. For every vit instantiation, LV has to read the VI from disk. For reentrant VI it is possible to use a static VI reference, thus probably speeding the process as well.

PJM