Popup that doesn't steal focus

[BramJ]

For a tool to edit Teststand Property Loader files I have a tree structure with all the propertuwa, in the screen to add a property I have a string control with autocomplete, it dynamicly generates the keyword list based on what propertys are available in that specific container. Now the problem: I want to display a list of available of available properties in a popup screen. I made a subVI to show the dialog but when opened it steals the focus from the main screen, so I am unable to continue typing in the string control.

So, what I want is a popup to show available properties but that doesn't steal key focus, but it does have to remain on top. A bit like the Labview Context Help window, it adapts its contents based on what I do on the screen, remains on top, but doesn't have (key)focus. Best would be like the popup window in Teststand, there the key focus remains in the input box, but the up/down arrow allows you to select an option in the popup menu

Does anyone have any tips to help me along a bit?

[Francois Normandin]

Perhaps you can use the call chain to get the caller's reference and give it the focus back once your dialog is loaded. You'd most probably see a flicker in the screen though...

Otherwise, there are probably some OS commands that you can call... but it's just a guess.

[mje]

How are you presenting the front panel of this pop-up VI? If you explicitly open it via an invoke node, you can specify that the VI should not receive focus:

All you need to do is configure the VI to not show its front panel when called, then some place in your code, make a call to FP.Open to show it. Just be careful, once you start doing this, you also need to manage when to close or hide the FP.

[Aristos Queue]

You also need to configure the VI Properties >> Appearance page to be a floating window if you want the "don't take key focus when interacted with" behavior that the LV palettes have.

[crelf]

For a tool to edit Teststand Property Loader files I have a tree structure...

I'd be interested in seeing that - do you have any more information?

[BramJ]

I have treid opening the FP with the invoke node, but still my input field loses focus, I have tried with both activate true and false and the diffirent 'state' options...

and @ Crelf:

it first reads the textfiles, filters unwanted stuff, finds the start and end headers and puts it all in a 3D array (a page for every section), then it add it all to the tree with as display text the acual property and as tag name the entire path to that property: container1.container2.property and it adds the value to the 2nd column. This way all tags remain unique and its easy to turn it into a property loader file again by just writing all the tagnames to a file (and offcourse the headers needed voor teststand), thats the basics but offcourse it has some stuff to make the editing of the tree easier, also a option to save all modifications to a file and apply them on other file(s).

it has several specific things for our products so I can't really show it here without 'undressing' it first

[Ravi Beniwal]

You also need to configure the VI Properties >> Appearance page to be a floating window if you want the "don't take key focus when interacted with" behavior that the LV palettes have.

How do you determine that it is time for this floating window to close because the user clicked on the host or any other window, just like the LV palettes? For a floating window, we can't check for "is foremost" to see if some user action made this window NOT Foremost.

[Aristos Queue]

How do you determine that it is time for this floating window to close because the user clicked on the host or any other window, just like the LV palettes? 

The only way I know of is to have every window you open monitor for when it is the active window and signal the floating window to hide. The operating system will take care of hiding that window when you click on a non-LV window.

[Ravi Beniwal]

Is that how LabVIEW closes the palettes?

 

It is not practical to put the burden on every VI that has an open window for announcing the "active window" state to any random floating window. We could get a list of all VIs with open FPs and let the floating window register for a mouse down event or periodically cycle through the open windows to see if any of them changed their active state. But it will take a while to get all VIs in memory, open references to each one of them and see if their FP is open. We will have to do this every time the floating is opened.

 

Is their a trick to quickly get a list of all VIs with open FPs or will that have to be a feature suggestion?

[Darin]

How do you determine that it is time for this floating window to close because the user clicked on the host or any other window, just like the LV palettes? For a floating window, we can't check for "is foremost" to see if some user action made this window NOT Foremost.

 

I think AQ takes the opposite approach that I would take.  Instead of putting the burden on every VI with an open window to signal the floater, I would put the burden on the floater to track the active window.  This is relatively easy with the VI Activation event and the new-to-LV13 VI Deactivation event.  Depending on how you launch the floater VI (static/dynamic) you may have to pass it the "parent" name.

[Ravi Beniwal]

Hi Darin,

 

Can you please post an example of using the VI Activation event? I can't seem to find it. Is it one of those hidden features that one may be just lucky enough to stumble upon?

[Mellroth]

Hi Darin,

 

Can you please post an example of using the VI Activation event? I can't seem to find it. Is it one of those hidden features that one may be just lucky enough to stumble upon?

 

Enable VI scripting features, and then look in the Application features of the"Edit Events" dialog.

The event will be fired whenever a new BD or FP is activated.

 

/J

[Bjarne Joergensen]

Hi

 

Could it something like this you are looking for?

 

regards Bjarne

[Bjarne Joergensen]

I found it in this thread.

http://lavag.org/topic/12751-how-do-you-make-your-application-window-frontmost/

 

/Bjarne

[hooovahh]

As time goes on this "Windows API" becomes less useful and more dated in the development style, but I still find uses for it.

 

http://zone.ni.com/devzone/cda/epd/p/id/4935

 

It has a subVI making a window front most given a HWND.  Now getting the HWND of a VI is a simple property node away, no longer do you need to rely on the window title.

 

http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

[ShaunR]

As time goes on this "Windows API" becomes less useful and more dated

That's disappointing. I've nearly finished my MDI API

[hooovahh]

That's disappointing. I've nearly finished my MDI API

I said "dated in development style".  Controls/indicators with white labels, not transparent, labels on top of the controls not to the side, classic controls including error, VIs not inlined that can be.  The tools themselves are quite useful and in my opinion should have effort to update the API to have other functions as well.