Loading TDMS Viewer into Subpanel

[Blokk]

I put together an example what I think about. This just works for me, i can load and deload the subVI arbitrary times without freezing the main VI:

edit: and do not click on the "Quit" button inside the subVI, remove or hide it...

[jeffl3001]

Thanks Blokk!  You confirmed my thoughts.  The end application will not require the user to end the file viewer process from inside it.  All control will be done from the main program.  I still think this is odd behavior though, and it's not consistent with other code I've written where the sub-vi can terminate itself while inside a subpanel.

In any case a good discussion and some learning too.  Thanks all!  🙂

[Blokk]

I was happy to help. I have some idea why this behavior, but I also hope that someone will jump in the discussion with more experience I have, and clarify the things up...

[drjdpowell]

---

@jeffl3001 wrote:

However, if I click "quit" in the file viewer and then, say, click the one of the tabs, both the file viewer and the main VI freeze.  There's nothing in the code that I can tell should be causing this.  

---

I haven’t looked at the code, but I would suspect there is an event case to handle tabs changes inside the Viewer VI that is set to lock the front panel until it is handled.  Though the Viewer is not currently running, it is still reserved for running, and is holding its lock (LabVIEW doesn’t know you aren’t intending to call it again).

[jeffl3001]

There is an event structure in the file viewer, yes, and I suspect you are correct in that the events are queued causing a lock when the VI is stopped.  That brings me to two questions.  First question is, why does the event handler lock extend to the main VI?  Second question, how would the code need to be modified to remove the file viewer from the subpanel when the VI stops thus preventing possible user interaction with an aborted VI?

With the open vi reference option set to 0x80 there is no way to wait for some sort of quit flag.  I suppose you could use option 0x100 and use the wait on asynchronous VI function but that seems like a workaround and not a solution.

While on the topic, I wonder if it would be possible to pass the main vi's reference to the file viewer on calling it and then use the reference to call the subpanel's invoke nodes.

Anyway, food for thought.

[drjdpowell]

I’m not sure of the details of the lock, but the purpose of it is to allow the application to modify it’s front panels without the race condition of the User clicking something before the changes are made, thus it would make sense for it to apply to all front panels.

Note that you could pass a reference to the subpanel, and have the VI remove itself before shutting down.