Jon Sweeney

I'm either going crazy, or have forgotten something basic, or this is a bug. :question: I have been away from LabVIEW for some time, working with Visual Basic, so either of the 1st two options is possible. I have tried this example with 3 different LV versions with the same result so I find it hard to believe it's a bug. But ... There is an integer input control with a Data Range of 1-10 and "Out of range action" set to "Coerce". I am unable, from the front panel to set it to anything except values between 1 and 10, as expected. But I also expect any calling parameter to be coerced. That isn't happening. Negative, 0, and values >10 are passed right through without coercion. The simple vi and calling vi is attached (ver 8.0.1). Download File:post-133-1164846160.viDownload File:post-133-1164846242.vi Thanks for any insight, Jon Sweeney

My guess is that it stands for "prefix", since the symbol used with the number represents a prefix (eg, milli-).

Has anyone seen this behavior before? I was building a front panel for a subvi with a table and several enums on it. When I tried to save it, the asterisk that indicates changes would briefly flash off and then appear again, no matter how many times I tried to save it, PLUS one of the enum controls would occasionally dim (as if it had been changed and the changes had not yet been applied. But if I clicked on it, it would be okay again, PLUS the Run Arrow became broken (possibly because of the dim enum). When I clicked on the broken arrow, the vi started running and could not be stopped by the "Abort Execution" (stop sign) control or "ctrl-." Turning on Execution Highlighting showed nothing; looking at the hierarchy window showed no green execution arrows. I tried to close LabVIEW but got a neverending "Resetting vi" dialog. I finally just had to abort LabVIEW using the task manager and lose my table changes. This happened after a fresh reboot that I did, after noticing the save/asterisk problem the first time. Befuddling. At least it hasn't happened again, yet.

Since my previous post, I have belatedly read the documentation for "Modifying Registration Dynamically" and have a better understanding of what you were trying to do with the "Not a Reference"s (ie, using them to unregister events) . My modified interpretation of why the vi hangs follows: Assuming the event registration structure is interpretted top-down like a property node is, in one eventcase (the 1st one encountered) you are unregistering and then registering the value-change event (net result=the event is registered). In the second eventcase (which causes the vi to hang) you are registering the event and then unregistering it (net result=the event is unregistered). If this interpretation is correct, I'm not sure if you can call the behavior a bug or expected-but-unwanted.