LabVIEW
Simultaneous execution of xcontrols
@altenbach wrote:
@Joel wrote:
Example program:
OK, I am finally at a computer with a LabVIEW version new enough to open your project...
You are blatantly using an xcontrol for a task that simple NEEDS to be handled in your regular code (easily!).
Xcontrols are front panel elements that interact with the user, do some quick transforms, update the contents, and return immediately. (for example I use it to update my tensor display so all geometric transforms are globally consistent, independently of which of the 9 elements are changed. As an example see figure 5 in my recent article).
When NXG came out, NI decided not to migrate xcontrols to the new system, so they almost became obsolete. they are just too clumsy to use and do right, it is trivial to substitute "real" code to emulate the functionality at runtime.
(Note that Xcontrols are reserved in edit mode and even update when used in edit mode. In your case, you can trigger the counting even if the caller is not running or even broken!! (try it!). This of course can lead to silly aberrations such as this. This also means you cannot edit the Xcontrol while any callers have the front panel open, even in edit mode. What a pain debugging them!).
Actually you can:
And then when you're done editing the XControl:
I've also created a custom pop-up menu to help out (see attachment):
@paul_a_cardinale wrote:
actually you can
Tap head, rub belly. 😄
I still stand by my all other comments. It is just not right to do extended timed tasks using an xcontrol.
Running timing-intensive stuff in the background is a great use case for QControls, as they're basically just a wrapper around an asynchronous subVI. They give you a lot of help with obfuscating things and are very helpful for just regular manipulation of standard controls, but they let you hide a lot of common use stuff that would otherwise take up space on your block diagram.
They fix the issue of XControls running in Edit time (which can be hard to predict exactly how they behave) and give you much more explicit control over the steps happening inside it. They're also WAY less glitchy and let you use OOP very easily. If you want edit-time performance they certainly can't do that, but that's not something I need super frequently.
Using them is as simple as calling a constructor that returns a reference wire of an object. Using the data in the control is done by creating methods that act on that object to return data (or whatever). You do need to understand OOP to be able to manipulate it, which is a drawback if you're not interested in OOP (though I'd recommend learning it). It's a little more confusing on the "usage" side than an XControl, but waaaay easier to design and debug, IMHO.
You can certainly write your own functions to spin up an asynchronous process and communicate with it but QControls take care of a lot of the boilerplate stuff. (Other great options for async processes include the Actor Framework, JD Powell's messenger library, or the DQMH, though those are more "whole program" level things rather than a simple control).
