Multiple Plots In Seperate Windows

[AllanS]

Attached I have created a VI that launches as selected waveforms to multiple plots all on seperate windows. The way I have wrote it causes the windows to lose and gain focus as expected. Does anyone know how to stop the focus from constantly changing? Maybe even a smarter way todo this, or example of it? I was thinking maybe having LabVIEW access some windows APIs that would allow me to control focus. If that is even possible.

[CoastalMaineBird]

I don't have time to figure out xeactly what you're doing, but here's some ideas from a previous project I did - maybe they'll fit:

The project had one main window, and six sub-windows.

The main window had a button for each sub-window, to call it up.

Each sub window ran on its own, offering a different view on live data being taken by the main.

Each window operated as expected - it stays in front if you click it - you move them around like any other windows.

You couldn't click the CLOSE box, but each window had its own DONE button which closed it.

Here's how it worked:

1... A "Window Manager" vi was initialized (from the main) to generate six OCCURRENCEs and store them in a shift reg.

2... A "Window Launcher" vi is started. It first calls the WINDOW MANAGER to obtain the OCCURRENCE refnums, then launches six parallel WHILE loops.

3... Each WHILE loop has a WAIT ON OCCURRENCE function. It waits a specific time (500 mSec in my case).

4... If the WAIT ON OCCURRENCE timed out, we simply check the state of a global PROGRAM RUNNING variable, and loop if it's true.

5... If the WAIT ON OCCURRENCE did NOT time out, then it was triggered, and we call our particular sub-window (there's one WHILE loop for each window). The sub-windows are set to show front panel when opened, and close when done.

6... Each sub-window monitors the PROGRAM RUNNING global and stops if that is false.

7... Periodically, the six main buttons are fed to the "window manager"'s CHECK function. This checks each button, and if TRUE, calls "OPEN or MOVE to FRONT" VI with the path to the associated sub-window, and the occurrence for the associated window.

8... The OPEN or MOVE to FRONT vi opens a reference to the associated VI, and checks the FP Open property to see if it's already open. If it's already open, the FP.IsFrontmost property is set TRUE to bring it to the front (one might click on the main button while this window is hidden - this will bring it forward).

9... If the window is NOT already open, the associated occurrence is fired. The Window Launcher vi will then start it up.

The windows do whatever work they need within themselves - it's not like the main is doing the plotting and sending data to the windows. It's more like the main is putting data into a common pot and whichever sub-windows are open (running) go and get it.

Hope that helps.

[SW]

NIBOUND wrote:
> Attached I have created a VI that launches as selected waveforms to
> multiple plots all on seperate windows. The way I have wrote it
> causes the windows to lose and gain focus as expected. Does anyone
> know how to stop the focus from constantly changing? Maybe even a
> smarter way todo this, or example of it? I was thinking maybe having
> LabVIEW access some windows APIs that would allow me to control focus.
> If that is even possible.

For Window API, use G Toolbox:

http://www.geocities.com/gzou999/index.html

[AllanS]

Thanks thats really similar to what I am doing its just that my main form sends data which is causing the flashing. This design is a great idea. Thanks a MILLION for your help and time!

[CoastalMaineBird]

thats really similar to what I am doing its just that my main form sends data which is causing the flashing. 
--- I would suggest putting the data into a separate global function (better than global variable for non-trivial amounts of data), and letting the "slaves" pull it out. At least that's what I did.

This design is a great idea. 
I can't send the code, as it was contract labor.

Thanks a MILLION for your help and time!"
Please send check for one MILLION to:

;->

[AllanS]

I actually got mine working with out using occurances. What benefits would I get by using them? As of right now as can be observed in my code, I just having everything in a while loop. I imagine this is as ineffiecent as possible due to constant polling. Is this what occurances would eliminate. Thanks.

[CoastalMaineBird]

You have a rather hairy state machine going on (I looked at your code again).

The difference I see is that you have ONE button which spawns window #1 or window #2 or window #3, depending on who's up already. But the logic to support that is part of the polling process of every loop. My app had one button for each window (each window was different).

My reason for using occurrences was to eliminate all execution paths between the main and child windows. In other words the main didn't CALL the child directly, so therefore, they became parallel independent processes. This led to the correct behavior as far as windows on top, who has focus, etc.

There are probably other ways to do it - VI server, for one. I did this
project in 6.0 and didn't know about VI Server then.

[CoastalMaineBird]

The way I have wrote it causes the windows to lose and gain focus as expected.  Does anyone know how to stop the focus from constantly changing? 

The focus is changing because the execution is changing (in the same thread). You have the VI with the graph execute, and then quit. This will lose focus.

My occurrence-based scheme had all child windows executing at the same time (different threads). This meant that the window on top had focus - no other window would have it until you clicked on that window (and brought it forward).

Hope that helps.

[AllanS]

I fixed the focus problem by changed the window property to floating. The only problem I have left (I have made several changes since the version you looked at) is that when I change the comboboxes it stalls the graphs. Would occurences fix this?

[CoastalMaineBird]

I fixed the focus problem by changed the window property to floating. 

That's not a good fix - although the focus quits flashing, the windows don't - you can't control the Z-order (who's in front). Overlap the windows and see.

The occurrences simply controlled the launching of the windows, not the distribution of data. Once a window was opened, the occurrence played no part until that window was closed and opened again.

The key factor was that the code in each window was running at the same time as all other windows. Your scheme still has the window display new data and stop. Therefore you're tied to the fact that the parent has execution most of the time.