Need ideas on operation of modal windows

[CoastalMaineBird]

1... Showed client my main VI.

2... He was pleased, but wants a background to cover the Windows desktop (sort of idiot-proofing).

3... My main window looks bad when scaled to 1920x1440, even worse if the window moves to 1920x1440 and the controls stay in the upper left.

4... So, I made a parent VI containing nothing but client logos, set to enlarge to full screen, which does nothing but call my main window (1000x700 or so), which is set to auto-center. All looks OK.

5... But when you click on the background, the background VI comes to front, obscuring the main one. Not a good thing.

6... So I made the main window modal. This works. Clicking on background has no effect.

7... Now I want the main window to spa
wn other windows, showing other views of the data as it comes in. I made this child window not-modal as is my custom. I can handle the data communication between the separate VIs, just fine.

8... BUT, the window comes up BEHIND the main window and can't be interacted with.

9... If I set the child to be modal, it comes up IN FRONT of the main, and the main cannot be interacted with.

10.. I want both the main and the child to be modal with respect to the background VI, but not modal with respect to each other. In other words, I want to be able to bring either main or child to the front, move them around, change their controls, etc. without having the possibility of the background VI covering them all up.


I thought about putting my main panel's stuff into a cluster, centering that cluster myself on the background logos, and going from there. But a cluster cannot hold both controls and indicators.

Any ideas?

[viScience]

You need a vi called 'make window always on top.vi' from the lvwutil.llb
collection found at ni.com

Mike Sachs
Intelligent Systems

"CoastalMaineBird" wrote in message
news:506500000008000000184F0000-1023576873000@exchange.ni.com...
> 1... Showed client my main VI.
>
> 2... He was pleased, but wants a background to cover the Windows
> desktop (sort of idiot-proofing).
>
> 3... My main window looks bad when scaled to 1920x1440, even worse if
> the window moves to 1920x1440 and the controls stay in the upper left.
>
> 4... So, I made a parent VI containing nothing but client logos, set
> to enlarge to full screen, which does nothing but call my main window
> (1000x700 or so), which is set to auto-center. All looks OK.
>
> 5... But when you click on t
he background, the background VI comes to
> front, obscuring the main one. Not a good thing.
>
> 6... So I made the main window modal. This works. Clicking on
> background has no effect.
>
> 7... Now I want the main window to spawn other windows, showing other
> views of the data as it comes in. I made this child window not-modal
> as is my custom. I can handle the data communication between the
> separate VIs, just fine.
>
> 8... BUT, the window comes up BEHIND the main window and can't be
> interacted with.
>
> 9... If I set the child to be modal, it comes up IN FRONT of the main,
> and the main cannot be interacted with.
>
> 10.. I want both the main and the child to be modal with respect to
> the background VI, but not modal with respect to each other. In other
> words, I want to be able to bring either main or child to the front,
> move them around, change their controls, etc. without having the
> possibility of the background VI covering them all up.
>
>
> I thought about pu
tting my main panel's stuff into a cluster,
> centering that cluster myself on the background logos, and going from
> there. But a cluster cannot hold both controls and indicators.
>
> Any ideas?

[Mache]

Hi

One way is to use the Property : "FrontPanel is Front Most" for all three or as many Vi's you have. Basically say you refer to your Vi's as Background, Main and Sub.

The Background Vi Calls the Main Vi. There is a While Loop in the Background Vi. The Main Vi Call is Outside this While Loop. The While Loop Polls whether the "Panel is FrontMost Property" of Background Vi. If it is True it makes the "FrontMost Property" of Main and Sub Vi also true.

So If somebody Clicked on Background Vi, it will force the other two Vi's Front Panel to come to Front. This ensures Basic Functionality.

There is One Hitch However. The Windows will Flicker when Anyone Clicks on the Background Panel. Also if the While Loop has delay in it you will see pronounced Flicker. If the
re is no Delay, you will swamping your Processor. I have tried with Event Structure. You will Still See a Flicker.

If this Helps, And you need to see the Vi's Let me Know and I can Post them. This is One Way. I remember reading on this forum about setting Windows Explorer.exe shell with Your Own Exe Program to Hide Everything on the desktop and also the Start Task Bar. You can try that too. I am not sure in that case how do you revert to the Explorer shell if you wanted too.

Good Luck.

Mache

[CoastalMaineBird]

I understand the part about flicker. The background VI will come to the front and THEN AND ONLY THEN will I get a chance to react. I thought of some similar thing, but that's basically recovering from the event after the fact - I want a way to prevent it.
If the VI EVENTS included a WINDOW IS ABOUT TO COME TO FRONT event that I could discard, that would be ideal...

I tried putting an event loop in the background VI and discarding the mouse-down event, but that didn't work. The system does the window re-ordering, and THEN the event structure gets a chance.

What I want is a KEEP-WINDOW-ALWAYS-ON-BOTTOM call.

[CoastalMaineBird]

There's another hitch in your solution:

Suppose I have a background, a main and TWO (or more) child VIs?

The background VI would put the children back in front in what order? It doesn't know what order they were in to begin with, so it could only put them back in some predetermined order.

[Greg_McKaskle2]

....

> Suppose I have a background, a main and TWO (or more) child VIs?
>
> The background VI would put the children back in front in what order?
> It doesn't know what order they were in to begin with, so it could
> only put them back in some predetermined order.
>

You should definitely try Michael's solution. The Always On Top VIs set
the windows attribute to make the windows float, like LabVIEW's help
window. It allows you to click on the window below, but the On Top
windows always float above other windows. If two subVI windows are set
to float, then they can be moved back and forth on top of each other,
but they always float on top of the nonfloaters.

Greg McKaskle

[CoastalMaineBird]

OK, I tried it. In my MAIN , and all the CHILD VIs, I turned OFF the modal setting and used GET THIS VI's PATH --> OPEN VI REFERENCE -> GET FRONT PANEL TITLE -> CLOSE VI REFERENCE -> MAKE WINDOW ALWAYS ON TOP.

The fundamental operation is as I want it - the background VI stays in back and I can diddle the Z-order of the main and child VIs.

HOWEVER, it has the following drawbacks:

1... When you click on the background, the main window title bar loses its highlight (minor - I can live with it)

2... When I click the QUIT button, the ARE YOU SURE YOU WANT TO QUIT dialog that I have comes up BEHIND the main window. (minor - I could write a VI with the always-on-top trick, make it modal, and be done).

3... The FILE dialog
comes up BEHIND the window it's called from. I'm not in the mood to rewrite a whole file-selection dialog.

Other ideas?

[Greg_McKaskle2]

> Other ideas?
>

Yep, three more.

Using the windows SDK, instead of making the windows float, you can also
change their parenting. Making them belong to the background window.
It sounds simple, and a number of good LV programmers have made it work,
but it is actually pretty darn complicated since when LV goes from edit
to run mode and you have it change window styles, the panel window may
be destroyed and replaced. But, as I said, using the windows SDK to
reparent is doable, and it would work better than the floating.

OR

Going back to the cluster idea that came up earlier. Use a tab control
instead, presumably with only one tab in use and with the tabs hidden.
This allows controls and indicators and doesn't cha
nge how the diagram
interacts with the controls. You should be able to drag controls to a
tab and your diagram still works fine. This eliminates most of the
windows and places things directly on top of the graphic in the main BG
window.

OR

If the current solution is acceptable, but less than ideal, you might
just wait for another rev of LV. There are features in the works that
will make it much easier to do the parented window. The downside is
that you can't have it completed until we do.

Greg McKaskle

[CoastalMaineBird]

#1 ACK! That sure SOUNDS like an ugly hack. I don't think I want to do it that badly. I thought about spawning them from the backgrouund VI (under orders from the main), but I don't thknk that changes anything.

#2 I fooled around with this, bu it doesn't actually address the root problem. If the child windows are modal, you can't interact with the main, and if they are not modal, a click on the main puts them behind the main (inaccessible)

#3 my client won't wait for that.

[sash]

CoastalMaineBird wrote in message news:<5065000000050000009F840000-1023576873000@exchange.ni.com>...
> #1 ACK! That sure SOUNDS like an ugly hack. I don't think I want to
> do it that badly. I thought about spawning them from the backgrouund
> VI (under orders from the main), but I don't thknk that changes
> anything.
>
> #2 I fooled around with this, bu it doesn't actually address the root
> problem. If the child windows are modal, you can't interact with the
> main, and if they are not modal, a click on the main puts them behind
> the main (inaccessible)
>
> #3 my client won't wait for that.

Hi CoastalMainBird,
I seem to remember reading on this newsgroup somewhere a method of
modifying the OS
(don't panic yet) so that the only piece of software
that runs is the appication executable.
Try searching for this 27th of June topic was How can I disable the
access to windows 2000(O.S.) from LabView?
It should be appropriate to other OS's, and this sounds like the sort
of thing your client is really after - i.e. to stop the user playing
games / surfing the web whilst your important program is running.
Hope this helps

Sash