Leaderboard

By reading the manual and trying it out. At least until you can come up with a more specific question.

If you have that many instances of this behavior it would be worth your time to create an Xcontrol.

The stock controls don't have the capability you're looking for. Other options: trap the value change event, and if you see the "rollaround", change the value back. Hide the up/down arrows and place your own buttons on there to increment/decrement the value I am, of course, assuming you're using an event structure.

Yup. This is where I was talking about type checking which has to be done in the child.

Just to clarify for others that stumble across this discussion. You can open references to VIs built inside an EXE by path but this is only possible from VIs running as part of that EXE and the path will be different than during development. That path difference makes this error prone and a bad idea, but it is possible. In general the VI path is the EXE path with the VI filename added as another path segment at the end. However this has problems with class/library files that have the same filename. How LabVIEW resolves these conflicts also depends on the Advanced build setting for "Use LabVIEW 8.x file layout". If this option is on, then LabVIEW will put the files in directories next to the EXE. If the option is off, then LabVIEW creates virtual directory structure under the EXE. I won't try to fully explain this, but I will say that is repeatable between builds so you can figure out where the VI is being put and reference it from there. Most of the time there is a better approach but this is an option if you can't find another answer.

The easiest and safest way is to use a static VI reference - you drop it from the app control palette and then drag your VI into it. You can then use the name or path property from that. It will work correctly both in LV and the EXE and will also force the VI into the build. P.S. In the image the reference is connected to the type input because I often configure it to be strictly typed and then you can use it with the ACBR node.

You mean any ASCII instrument communication should use termination. I deal with many serial binary protocols where the message length is a number of bytes in the header. In theory. I agree with never using the bytes at serial port. However, the serial read can no longer be aborted. Not by making the Visa Ref go invalid and not even with the abort button on the LabVIEW bar! Unless you want your application to hang for, several seconds when the user exits (or you just want to stop the VI at all when debugging). The only practical way is to use your own read VI using the bytes at serial port in a loop with a very short timeout on the Serial Open (since you can only set a timeout on the open unlike other comms vis that are on the read). Then you can implement your own timeout without the VI hanging whilst VISA fiddles with it's gonads. This "feature" of the serial read has annoyed me enormously over the years.

Well, I've tracked this down to an issue being brought on to using classes within a LabVIEW library. The two kinds of libraries (.lvlib and .lvclass) just plain do not work together. My little project's classes became plain uneditable, they were contained in an lvlib. In a fit of frustration, I dragged the entire lvlib hierarchy out of the library scope, and magically everything just works as intended. This is a shame, for lvlibs offered a lot of control and namespacing which really helps with code reuse. Please to any at NI who are reading this thread, fix this. Well, it's a good thing I got this working. I'm literally down to the last hours, about to be gone for two weeks and this code has to work by end of day. Meanwhile, I just lost two hours trying to add a simple primitive to one of my classes. Since there's no way I'm going to drop my use of .lvclass objects, I'm done with lvlibs for now.