Unusual behavior when placing DQMH module into a subpanel

[Thoric]

I've been working on a project using DQMH and recently added a subpanel feature that allows an operator to swap out different user interface segments. The selected UI component is also a DQMH module. I've found that when a DQMH module is launched then programmatically inserted into a subpanel control, it dutifully obliges, showing the module FP inside the subapanel real estate area, then precisely three seconds later the parent (calling) VI crashes. This crash is immediate, without warning and without error code, causing the whole application to vanish. It only happens for built applications too, making it a bit of a problem to diagnose.

I eventually determined that the "Initialise" case of a DQMH module, which sets the FP properties (Hidden, Standard) and Centralised etc., must be interfering with the subpanel status. By removing the FP manipulation it seems to like being subpanel'ed fine. It doesn't quite make sense because the subpanel insert method is being called after the Initialise case, so it shouldn't matter. But it does.

Comments gratefully received if anyone else has seen this too or knows if I've made a blatant mistake here?

[FabiolaDelaCueva]

Richard, 

The code is probably calling the Hide Panel request at some point. If the DQMH Main VI panel happens to be in a subpanel in another VI, then the FP.Open call with the 'Hidden' state will actually hide the VI that owns the subpanel that contains the Main VI! 

You might want to change the code to make sure the DQMH module is no longer inside the subpanel when you tell the module to hide or modify how the DQMH module handles the request to hide its panel.

Regards,

Fab

[Thoric]

Hi Fabiola,

Thank you for the reply - I did not know that a subpanel'ed VI when attempting to close its front panel would also close the parent VI. This is a useful clue.

I'm not aware of any requests to ask the module to hide its panel. Is this something built into the DQMH template somewhere that I'm possibly inadvertently calling? Maybe on an error?

The parent 'calling' VI doesn't send any messages to the subpanel'ed DQMH module beacuse the DQMH module runs entirely autonomously, so if the DQMH module is trying to hide its front panel then it is choosing to do itself.

Looking into the template I see there is a Hide VI Panel function within the "Exit" case but I can't foresee why the Exit case would be called.

The "Hide VI Panel" function is also called in the Event Case "Panel Close?" which is tied to the user closure of the panel - which I'm also not doing as the front panel is within a subpanel control and cannot be closed by the user.

It's the whole "after three seconds" thing which bothers me. I can't understand what's taking precisely three seconds that then causes the code to react with a panel closure.

I'll keep digging because I'm more and more convinced it's something I've done...

[Thoric]

Fabiola,

It's probably worth me mentioning that I prevented the issue by disabling this bit of the module template:

I should have seen it sooner and thought to disable it. I assume this bit of code, specifically where it tries to set the State to Hidden, is responsible.

So a question remains as to why it takes three seconds for this case to execute and cause the subpanel control owner to vanish. This case is "Initialize", which runs pretty much immediately, right? In the calling VI this DQMH module is launched, and I modified the launcher to return the VI reference to the caller. Then I take the VI reference and use it to force the module into the subpanel. So that happens pretty quickly, as you'd expect. Can't see why three seconds delay occurs before this case runs. I'll keep digging - must be something I'm doing wrong...

[Thoric]

A little update on that timing concern: the module was waiting the default DQMH timeout period of 5 seconds for caller synchronisation of broadcast messaging. My sub-module is totally autonomous and does not require any broadcast messages to be registered, so my caller was simply launching it and moving on. This left the sub-module waiting, eventually erroring out. Ironically, for me, the error is sent out through the broadcasted Error message, which has no registered listeners because the sub-module is meant to be autonomous, hence it was not seen.

This delay is also tied into the FP behaviour - because it's chained to the output of the Sync Caller Events VI.

[joerg.hampel]

Richard, how about not registering for the broadcast events (as you don't need those in your caller)? You still need to put the "Synchronize Module Events.vi" after the "Start Module.vi" to let the submodule know that it now _could_ send broadcasts.

One could argue that the documentation inside the VIs suggests that the caller "has to" register for the broadcast events when in fact it doesn't. Fab, please chime in if I'm wrong here.

[drjdpowell]

Just a suggestion, but instead of the current "Start Mod" and "Sync", it might be more intuitive to have a "Prepare Module" (which creates the User Events, for which you can register) followed by "Start Module".  "Prepare Module" could be optional, needed only when you want to register.  

[Thoric]

Hi Joerg,

Yes, that's precisely how I worked around this - I called the Start and Sync VIs without actually registering for the broadcast events.

However I feel this is a little bit of a cheat because we're effectively telling the module that we have registered for its events, and it then acts under that impression by sending error information out on the Error Reported broadcast. I'd rather it knew that nothing had registered and behave like it does when not externally launched. Is there not a more suitable approach to launching a DQMH module as autonomous? A mode for which it behaves much like when it hasn't been externally called - by presenting error codes in a dialogue (for example).

[joerg.hampel]

Richard, I see what you're getting at.

You probably already know that the DQMH modules do behave differently when called externally (i.e. launched via the "Start Module.vi") as opposed to being executed directly (i.e. running the main.vi). The Module Admin object has a boolean property named "External Launch" which for example makes the error case behave differently:

There's no built-in way to achieve what you suggest that I know of, though. The first thing that comes to my mind is to let the module in question register for its own broadcasts in a helper loop, and handle these events in whatever manner you see fit. 

I'm curious to hear others' ideas...

[FabiolaDelaCueva]

Richard,

The idea is that even if your module is autonomous, you would be using the API tester to launch it and test it until you are done with development. In this approach, the API tester is used as a debugging tool to look at all the errors the module might broadcast. 

You could override this behavior by editing the Start Module.vi for your module with an additional input to indicate that although you are launching it externally, you don't care about the module broadcasts or you will register for them at a later time (i.e. by later launching the API tester in the case you want to use it as a sniffer.)

This input would tell the Start Module.vi to send the object as not launched externally, and if this input is selected then there is no need to wait for event synchronization. Something like this, for the "autonomous mode" where the External Launch would have false and the Wiat for Event Sync? would be false too.

and in the "Caller registered for events" mode, the external launch would be true and wait for Events Sync? would be true as well.

Or you could create a child of Delacor_lib_QMH_Module Admin.lvclass and make modifications on how you would like your DQMH modules to behave.

Either way, if this is something you would like for all of your DQMH modules to have in the future, you can create a DQMH Module template with these changes and all your future DQMH modules created with your template will have your modified Start Module.vi

If this is something you would like for us to add to DQMH, feel free to add it to the feature requests and point to this post for discussion. 

Regards,

Fab