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

If you view the radix of a numeric on a control or indicator you can change the formatting by clicking the radix and selecting a new one (hex/oct/bin/decimal/etc). This comes in really handy sometimes while debugging since you can change the radix on the fly without having to stop everything and start over.

Speaking of which, a 'p' is used for SI notation... anybody know what 'p' is for?

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.