LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Just checking on another odd feature: Typedef enum Property Node "Value" not reflecting changes in the Typedef?

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:

 

ScreenHunter_003.jpg

 

So far so good. Now create a "Value" Property node for the enum and use it instead of the terminal:

 

ScreenHunter_001.jpg

 

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.

 

 

 

Message 1 of 9
(3,410 Views)

+1 kudo for using the "magic Ctrl-R".  Smiley Very Happy

0 Kudos
Message 2 of 9
(3,399 Views)

Sure thing. The problem is that Ctrl-R is dangerous in some cases (sticky dialog box, delicate hardware controlled by the code, etc).

0 Kudos
Message 3 of 9
(3,397 Views)

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.

0 Kudos
Message 4 of 9
(3,396 Views)

It works even better in LV 2010 if I may say: now the Ctrl-R trick fails to fix the red "Case 3"!

0 Kudos
Message 5 of 9
(3,369 Views)

If anybody cares about this being fixed, please go there and kudo the suggestion.

0 Kudos
Message 6 of 9
(3,341 Views)

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.

0 Kudos
Message 7 of 9
(3,331 Views)

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?

0 Kudos
Message 8 of 9
(3,328 Views)

@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.

0 Kudos
Message 9 of 9
(3,323 Views)