04-14-2011 10:07 AM
Over-lapping graphics have historically been an issue since the entire image stack from back to from must be resolved to render any updates.
Re: setting the panel "Z-order" that is a very good question, that I can not answer without resorting to a kluge at best.
If over-lap is required then using a picture control to render the background screens could work. In this case I am thinking that the FP images of the those secreen deeper in the pile are rendered in a picture control to make it look like they are here but actually are not. Eamples of ggeting teh screen images to pull of thes approach can be harvested from my example that was linked earlier in this thread.
If you come up with something you like, please post a small demo so the rest of us can learn from your investigations.
Ben
04-14-2011 10:39 AM
Along the same lines is it possible to create a manager application that will contain floating, moveable and resizeable child windows? I looked at your example Ben and it seems to either give a fixed subpanel view or a floating, detached (from the parent/manager) window. I am looking to create an aplication that can have a variable number of active windows/subpanels that the user can move, resize, minimize, open and close at will. The parent windows would primarily act as the central point for control and be used to contain all the children windows. The children windows are effectively indendent in terms of function. The primary reason to bind them within the parent window is for ease of management for the user. If they minimize or exit the parent window all the children will be minimized/closed as well.
The application I am working on is a general purpose communication tool that will have a single receive window (data read from the connected device) and multiple transmit windows (data to be sent to the connected device). Only one transmit window will be active at a time which simplifies things somewhat. That is, there will only be a single transmit window and the other transmit windows are a convience for the user. They can have various and different data in individual transmit windows but can easily switch (mouse click to activate) between them. It is fairly straightforward to do this if I allow all of the windows to be freeing floating and disconnected. However it makes it more difficult for the user to track which windows belong to which connection. Our users will be working with several connections/devices at one time. This is why I would like to have a parent window constrain all the windows it spawns.
04-14-2011 10:54 AM
Hi Mark,
I could not determine if that reply was a Q or an A.
Tracking the life of the top-level is implemented in that example code as well. In theory it could be wrapped-up in an XControl to handle the re-sizng automatically but I never found the motivation to due so.
Take care,
Ben
04-14-2011 11:24 AM
Ben, it was more a question than an answer. What I am looking for is something along the lines of the way older versions of Excel or Word worked. You opened it up and each new document you opended was bound withing the context of the parent window. However, within those bounds it acted like a completely independent entity. I didn't see these constraints in your example. When the window was a subpanel it was fixed both in location and size. When undocked it was floating outside of the parent window.
I supposed I could do some complicated code to track th ewindow position and restrict it from moving outside the parent window but I think this would look rather odd.
04-14-2011 11:40 AM
With that I can not help. I nver did like that behaviour and would maximize it ASAP so I never bothered to code up what I did not like.
If it was a project on my desk, I'd implement it using sub-panels I could move around to handle the Top window wiht the rest being just images of what they would look like if they actually where there. If the use clicks on the Picture the coordinates would be translated into whichever widget was there then defer FP updates, get images update pictuer put what was in the sub-panel in the picture and put the previous simiumated FP into the sub-panel.
Bonus points if you implement click-through functionality.
Ben
04-14-2011 12:51 PM
In my case this of the windows being essentially one string indicator and multiple string controls. Since the view is dynamic a picture doesn't really help in this case.
In the end I may end up with simple floating, independent windows. I would give the user the ability to minimize/show all the windows from the single master window. In addition, the master window would provide the "exit all" functionality. I'm replacing an application (written in C) with that currently functions like this. They are accustomed to the windows being contained in a single frame.
Thanks for the input though.
04-15-2011 11:58 AM - edited 04-15-2011 12:02 PM
If you want to show more than one subvi at a time, forget the subpanels. Look at my attached examples (saved in 8,5). The example is very crude but should get you started. You click on a show button and it will open and run the subvi. You have complete control over the subvi, clicking buttons inside the front panel, moving the window, etc.
However, it is unfinished. I'll leave this part up to you. First, you don't want to open and run the subvi again if it is already opened and running. So you have to check the execution state (run or idle) and front panel state (open or closed) before you decide to open and run the subvi. Another unfinished feature is that you don't want to abort the vi if it is not running. This will give you an error. You don't want to close the front panel if it is not open. Add these checks and balances.
What you could do is create another subvi for that has all this code for checking and opening a subvi. Call this subvi and pass it the reference to the subvi you want to open. Do the same for aborting and closing. This way you only write the checks and balances code once. You can use it to open as many subvi's as you want. You must however initially open a reference to each subvi you might want to use at the beginning of your code, then close these references at the end.
Look at VI Properties - Window Appearance - Custom settings to see how to set the vi display properties. You can change these as you like. You can use property nodes to set the subvi window positions to be inside your main if you want it to look like that. however, if you move the main, the subvi's position would not change unless you add code to do so. If you want this feature, you may have to revert back to subpanels.
I hope this gets you what you want.