Question About Multi-Window UI Behavior

[mje]

Quick question about behavior of multi-window UIs in a LabVIEW application. If I'm going about my business in another application, then click one of the windows in my application, all of the windows belonging to my application come to the top of the z-stack. Is this behavior part of the OS or part of the LabVIEW RTE? Do we have control over this behavior?

This is a Windows app by the way, in case it's OS related and not RTE.

[hooovahh]

If I had to guess I would say this is a behavior of the operating system. I say that because I cannot seem to find a instance, where a single application, that has more than one window, will behave differently than the one we experience with LabVIEW where all other windows are brought up. (I did a quick test with Microsoft Word and IE)

Well there are windows DLL calls that allow you to manipulate window Z-order. So one could certainly modify the order of all your applications' windows manually. I don't think I've ever had a case, where my application would have multiple windows, in the same application instance, and want to the operator to see one, without bringing the others in front of all other applications. I guess I just don't know your use situation well enough.

[asbo]

LabVIEW VIs are MDI children of a hidden window which lets them all be grouped together correctly by Windows. As far as I know, there is no way to disassociate them from each other or the parent window while staying inside the same image (executable). Built executables are also subject to this.

That is to say, this is a Windows constraint which is enforced because LabVIEW uses a MDI environment.

[mje]

Excellent responses thank you. I never considered MDI, but the behavior is definitely consistent with that UI model.

I was asking because this MDI behavior runs counter to another application that my users will often have running side by side. My application will bring all its windows to the front as soon as you use any of them, whereas the other does not enforce this behavior. The inconsistency is annoying. I personally have no preference between either model, I just don't like how each application behaves differently.

[crelf]

So the LabVEIW development environment is based on MDI, without the benefits of it being an MDI?

[asbo]

Excellent responses thank you. I never considered MDI, but the behavior is definitely consistent with that UI model.

I was asking because this MDI behavior runs counter to another application that my users will often have running side by side. My application will bring all its windows to the front as soon as you use any of them, whereas the other does not enforce this behavior. The inconsistency is annoying. I personally have no preference between either model, I just don't like how each application behaves differently.

What's your other program? It sounds like it's probably MDI-esque, but implements a custom windowing scheme so as to avoid the behavior you're having problems with.

So the LabVEIW development environment is based on MDI, without the benefits of it being an MDI?

Well, if you go by the Windows implementation of the MDI, it's doing everything as it should. If you consider a more purist definition (several related but independent windows), I would agree that LabVIEW is doing it wrong. Based on how often I have VIs open, I wish NI had found a way to go the latter route. I would even argue that giving focus to the block diagram or front panel should not affect the z-order of the counterpart window.

[mje]

What's your other program? It sounds like it's probably MDI-esque, but implements a custom windowing scheme so as to avoid the behavior you're having problems with.

It's an instrument control and data analysis program for a mass spectrometer. There are different windows for viewing data in the time domain opposed to the mass domain for example, and other windows for instrument control, sample queue management, etc. All the windows interact in various ways, and depending on context they can force each other to the top of the z-stack, but simply activating them never does.

I would even argue that giving focus to the block diagram or front panel should not affect the z-order of the counterpart window.

Amen to that!

[asbo]

It's an instrument control and data analysis program for a mass spectrometer. There are different windows for viewing data in the time domain opposed to the mass domain for example, and other windows for instrument control, sample queue management, etc. All the windows interact in various ways, and depending on context they can force each other to the top of the z-stack, but simply activating them never does.

Makes sense - I've written multi-screen applications (in Visual Basic) which behave exactly that way. I think the MDI environment is really intended for grouping several windows which are immediately and always relevant to each other, ala Visual Studio (there's an option to make all the windows floating instead of lock into the parent, but the specific name escapes me). Thinking about it, it practically makes the whole shebang a bunch of SDIs which still benefit from taskbar grouping.