09-15-2011 06:09 PM
Just encountered this odd behavior in LV 2011 which I reduced to the following example:
- create a new VI and drop an enum control on te FP.
- make this control a typedef and open the corresponding typedef
- create a "case 1" item and a "case 2" item
- save the typedef (I used the name Typedef Control 1) and CLOSE it (this is to allow updating of the original control).
- drop a case structure on the diagram and connect the enum to it:
So far so good. Now create a "Value" Property node for the enum and use it instead of the terminal:
If I now go back to the typedef and add a "case 3" item, save the typedef and close it, the control is updated, but the Property node is not.
How do I know that? For one, the Case Structure contextual menu does not offer to create a case for every value. Also, if I add a "case 3" case manually, it turns red.
Luckily, the magic Ctrl-R key stroke actually does solve this problem.
Tested in LV 2011.
09-15-2011 07:15 PM
+1 kudo for using the "magic Ctrl-R".
09-15-2011 07:24 PM
Sure thing. The problem is that Ctrl-R is dangerous in some cases (sticky dialog box, delicate hardware controlled by the code, etc).
09-15-2011 07:33 PM
Of course.
Have you had a chance to see if the same thing happens in LV 2010 or LV2009? In 2010, the background compile algorithms change significantly. This helped somethings, but slowed down other things, and created some bugs.
For a lot of the issues with the Context Help, I suspect (and this is just my wild guess) that the changes that came about to put the icon and the connector panel on screen side-by-side somehow affected the underlying code that determines subVI linkages.
09-19-2011 02:05 PM
It works even better in LV 2010 if I may say: now the Ctrl-R trick fails to fix the red "Case 3"!
10-05-2011 12:50 PM
If anybody cares about this being fixed, please go there and kudo the suggestion.
10-05-2011 01:14 PM
By Ctrl-R trick do you simply mean running the VI? That is one way to force a recompile, but if you hold down Ctrl while pressing the run button you can recompile without running. This should not be "dangerous" in any situation.
As you have drawn your example, I see no reason not to use a local in that situation (ok, maybe for vanity). Still, I view the behavior you describe as a bug, and it should certainly be fixed for the benefit of local haters out there. You have to be a little careful where you draw the line between what gets handled in real time and what gets handled only at compile time.
10-05-2011 01:20 PM
Yeah, I realized that after a bit...
Gosh, I am confused. So are we allowed to use local and global variables now? And are LV 2 globals good or bad? Should I use a three-button mouse?
10-05-2011 01:55 PM
@X. wrote:
Yeah, I realized that after a bit...
Gosh, I am confused. So are we allowed to use local and global variables now? And are LV 2 globals good or bad? Should I use a three-button mouse?
Only three buttons? Why stop there. I am still waiting for some native graphics tablet support. I want to use the 1024 different pressure levels for something.