Is this possible?

[Stagg54]

Here is what I need to accomplish:

The powers that be want all front panels in a particular application to have this feature they call "auto-snap". Basically all visible front panels should "snap" back into place if the user tries to moves them around (by clicking on the title bar and dragging them). The user should be able to hit the F2 key to unlock the window and move it where ever they want. Pressing F2 again should lock it again and snap it back into its original position.

My original design was to create a "brat vi" (I got that term from Norm Kirchner - he calls it that because it manipulates its parent). Basically you dropped it into each vi that had a visible front panel. All you had to pass it was a notifier to tell it when to exit. It ran in parallel and automatically pulled out the callers ref and registered for the key down event and took care of everything. Very cool and it worked very well. Only downside is that you had to drop it into every vi with a frontpanel. A bit of a pain for anything you may want to reuse for another project.

Now here is my problem. Now they want to pull in this reusable library that I have. I don't want to drop this brat vi into my reusable library. Most of the timeI don't want this feature and I don't want to pollute my library with something that is only going to be used for this one special case. Now this reusable library has one main entry point/UI vi. Now I can modify my brat vi to accept a reference and run it in parallel with the main UI of my reuse library. All works well until my reuse library calls up a subvi that shows its front panel.

What I would like to do is launch a vi in parallel with everything that would automatically detect when a new vi is opened and becomes the active front panel and then to act upon that. That would be nice because then instead of dropping it into every UI vi, I can just drop it once and run it in parallel with my main vi.

I guess my question is:

How do I get a reference to the vi that is active (ie. that the user is currently interacting - ignoring subpanels for the moment -although my reuse library uses those heavily so maybe that will cause some problems as well.)

I found the Application.Active VI property which I thought would do want I wanted. (Its a scripting node, but is supposedly works in the run-time which is what I need.) Unfortunately it does not appear to be returning what I am looking for. I'm nost sure what its returning. Even though Scripting is now supported (I'm using LV2009 by the way) there is not any documentation on what the term Active VI means. I does not appear to mean what I thought it did.

Anyway, is what I'm trying to do possible? Does anyone see a better way to solve my problem? Did I do a good enough job explaining it?

thanks,

[Daklu]

Did I do a good enough job explaining it?

Yep.

How do I get a reference to the vi that is active (ie. that the user is currently interacting - ignoring subpanels for the moment -although my reuse library uses those heavily so maybe that will cause some problems as well.)

I don't think LV keeps track of the active window--that's the OS's job. You might have to make windows api calls to get that information. There's a small visual basic example here that get the title of the window currently active. Perhaps you could parse the window name to get the vi name, and get the reference from that?

[Stagg54]

I don't think LV keeps track of the active window--that's the OS's job. You might have to make windows api calls to get that information. There's a small visual basic example here that get the title of the window currently active. Perhaps you could parse the window name to get the vi name, and get the reference from that?

That assumes that they are the same, which they are not.

I could search through all VIs in memory, but that could be a bear (the app has 1000's of vis). Also then I how do I figure out which one is active? I could try the FP.Is Frontmost property but according to its help entry it ignores floating windows.

Anyone have any other thoughts?

On a side note: does anyone know what the Application.Active VI property is returning? I haven't been able to decipher it.

[Mads]

Your window manager could monitor key events, and regularly check the FP.Open status of all VIs in memory.

The default state of the window manager would be to poll the positions of the open front panels (and only those), keep a log of their correct position and move the windows back if the position has changed but has now settled* (and they are still open). (Ideally there would be a window move event for this that you could set an event structure to respond to, but there is not...).

If the user hits F2 the state is changed to an ignore mode until F2 is pressed again - in which case the monitoring state will automatically correct the positions back to their original values again...

On start and every 1-5 seconds from then on the window manager will run through the list of VIs in memory and update the list of VIs it should monitor. I did a quick test now with 750 VIs in memory and checking their FP.OPen property only took about 40 ms on my machine so it should be doable (the CPU load was not bad either).

It is not required that you know which window is currently active.

* You could reset the position immediately when a change was detected but that would probably look extra messy so I would rather wait another cycle to ensure that the window has settled, before resetting it...

[Stagg54]

Your window manager could monitor key events, and regularly check the FP.Open status of all VIs in memory.

The default state of the window manager would be to poll the positions of the open front panels (and only those), keep a log of their correct position and move the windows back if the position has changed but has now settled* (and they are still open). (Ideally there would be a window move event for this that you could set an event structure to respond to, but there is not...).

If the user hits F2 the state is changed to an ignore mode until F2 is pressed again - in which case the monitoring state will automatically correct the positions back to their original values again...

On start and every 1-5 seconds from then on the window manager will run through the list of VIs in memory and update the list of VIs it should monitor. I did a quick test now with 750 VIs in memory and checking their FP.OPen property only took about 40 ms on my machine so it should be doable (the CPU load was not bad either).

It is not required that you know which window is currently active.

* You could reset the position immediately when a change was detected but that would probably look extra messy so I would rather wait another cycle to ensure that the window has settled, before resetting it...

That sounds like agreat idea! Thanks for the suggestion.