Triggering events, and sending information, from a subvi's user interface to the main VI.

[Artst]

The goal is to have a button on the main VI that opens the front panel of a subvi. The subvi's front panel has a user interface that can trigger events in the main VI, and alter data on the main VI's user interface. The screen shot below is an attempt at accomplishing this:

The trouble areas are enclosed in the diagram disable structures. I expected the code in the top most one to trigger an event in the main VI, and the code in the lower diagram disable structure to update a numeric display in the main VI's user interface. What happens instead is both this subvi, and the calling main vi, hangs, or freezes, when the subvi's cursors are moved, and either one, or both, of these diagram disable structures are enabled.

What went wrong here? What is the proper way to do this?

My LabVIEW version is 2020.

[Bob_Schor]

I can't "execute" a picture, nor can I "edit" it, nor can I "see it clearly".  Since you are using LabVIEW 2020 (which I can open), please post your VI (and promise never to only post "pictures of code").

Bob Schor

[altenbach]

As has been mentioned, we cannot debug truncated pictures. How is the subVI called and how is the caller organized. For example if the caller stalls waiting for the subVI to return, it cannot fire an event unless it is done right.

You need to attach a simplified version of both the callerVI and the subVI and explain exactly how you operate it and what you expect to happen at each step.

Maybe you also want to explain the reason for your "tail-wagging-the-dog" architecture. Maybe there is a better way.

[Artst]

I created a minimized VI, and subVI, to illustrate the problem. However I solved the freeze up problem in that minimized VI. But there is still one problem remaining I do not understand.

There are two VIs, a main VI, and a sub VI. Because in the the minimized VI is created from has a full interface, and has no room for anything else, there is a task for which an interface must appear only when needed. The sub VI's Front Panel is that interface.

These two VI's are in the attached zip file. It is desired that when a value is entered into the t1, and t2, fields, the cursor positions in the sub VI's front panel be synched with them. The desire is for this to also work in reverse, namely when the sub VI's cursors are moved, their position values are updated in the main VI's numeric t1, and t2, fields. But it works only one way. The cursors in the sub VI update the numeric t1, and t2, fields in the man VI. But the t1, and t2, fields in the main VI are locked, and cannot be altered. It is as if the sub VI was modal because the main VI's entire front panel they are in is frozen for as long as the sub VI's front panel is open. But this sub VI's modal checkbox not checked in its properties is. So what is freezing up the main VI's front panel?

[wiebe@CARYA]

[EDIT: this somehow crossed your previous post]

I suspect the SubVI is triggered in an event in the main.

The execution won't leave the event as long as the VI is running.

Start the VI dynamically (with the run method or with a call and forget\collect).

Another option is to run the sub VI in parallel of the main event loop. When it's needed, show it's panel. When it's done, hide it. You can do this with events send to the sub VI (that is always running) or by reference that you somehow need to get.

[wiebe@CARYA · Accepted solution]

Your VI is still blocking execution of the event structure.

Since the event structure stacks events and (potentially) could filter them, the front panel is locked until the event structure 'runs' again.

I'd really try to think of something less difficult.

I'd let the sub VI run in parallel, and maybe use a queue (created in main) to return references (no need for a user event) to the main. Then the main can register for an array of events, and when there is an event, filter out the source and copy to the other.

The sub VI can even be completely 'dumb'. It wouldn't even need a loop. It can simply have controls and indicators, and when you run it it returns references (VI and controls). I call this a 'facade' VI. It doesn't do anything, but functions as a front panel that con be used as a popup VI or in a sub panel.

Of course, I'd put the facade in a class, and the references in it's private data. The methods (open FP, close FP, etc.) live nicely in the class (or in it's parent). But that's just execution of the idea (making life even easier once you get the hang of it).

I'd never use two event structures in one VI, even though it's not officially disallowed anymore. 

[wiebe@CARYA]

And entirely different approach  is to put the main graph in an 'object', and let the sub VI handle it.

Anyway, I'd try to put all the graph stuff in 'something' (a class, library, a directory of subVIs) and try to arrange things so it never bothers me again. Ideally, including (unit) tests. As much as possible, because with user interaction it's hard to separate things completely. You might end up with an event here and there. This is tighter coupling than desired, but you have to find a sweet spot where more refinement just isn't worth the effort..

[Artst]

The problem is solved. The working files are attached. The problem was I had an Event Frame inside another Event Frame. The inner Event Frame was inside the sub VI.

I replaced the outer Event Frame with two Queues.

It now works as intended. It is not elegant code. But it works. I am not ready to integrate this new demo v2 into the program I need this for.