KeyFocus and FP.IsFrontMost aren't working

[TurboPhil]

I'm having troubles get key focus on a control in a subvi that I am showing dynamically. I'd like to be able to leave the VI running in the background, registered for events on its caller. In this example, I have the subvi registering for events when the user preses "Enter"/"Return" on its parent. Then, I am programmatically showing the subvi's front panel, and attempting to set key focus for a string control on the FP:

Everything is working properly, except I can't for the life of me get this subvi to move to the front and give keyfocus to the "String" control. Originally, I just had the FP.Open method followed by the value/keyfocus property nodes, thinking that would be sufficient. Later, I found a KB suggesting that I might need to add the FP.IsFrontmost property. But it still doesn't seem to work.

The probe #11 as showin in this capture always returns FALSE, despite showing no upstream error when I set the FP.IsFrontmost property immediately beforehand.

I've tried introducing waits and moving the operations to separate dynamic user event cases; still no joy.

Am I missing something dumb here, or is there some apocryphal magic incantation that needs to happen to get LV to accept my frontmost/keyfocus assertions?

[TurboPhil]

Shortly after posting, I found the problem:

I needed to change the WindowBehavior of the subvi from "Floating" to "Default", and then it started working correctly. I guess "Floating" behavior doesn't play nice with those properties/methods, although I can't come up with a good explanation as to why.

[tst]

---

@TurboPhil wrote:
I guess "Floating" behavior doesn't play nice with those properties/methods, although I can't come up with a good explanation as to why.

---

I never looked for an official explanation, but my understanding of floating or modeless windows is that by definition they're not part of the "proper" window stack and they don't maintain focus, because they are there to provide single click functions. That would certainly seem to be a reasonable explanation for such behavior.

[dbrown78]

I'm running into a similar issue.  we have a system setup with a string field that is populated by an Ethernet barcode reading camera.  the problem is, whenever the operator opens another (non-LabVIEW) window on the PC (chrome, excel... whatever), this property does not work and we end up with many transactions back to back with no feedback from this system because the window wasn't front-most and so it didn't get the scan.   I did change the window behavior to default, and it seems to work whenever I have other LabVIEW windows open...  but only for that and not other applications.  Any ideas of things i can try? 

[billko]

It seems to me that the ability to have several transactions back to back with no feedback from the system is poor design.  What happens if the operator simply wasn't paying attention?  Shouldn't the next transaction execution be based on the completion of the current one?  Seems like the application shouldn't continue until something was scanned into the box.

IMO, that should be your fix, not trying to make the box available for scanning...

[dbrown78]

I don't disagree.  The nature of the application doesn't work that way, however. We have 2 different systems.  the one LabVIEW is running on feeds transactional data to the second system.  Due to IT rules and setups, we currently do not have the means to receive feedback from the 2nd system that a new transaction should have been initiated.  I do need to figure out how to keep this window active.  They shouldn't be running anything else on the LabVIEW station, but I've been advised, operators may be opening email and leaving it open while feeding the system, so we are losing scans. 

[billko]

---

@dbrown78 wrote:

I don't disagree.  The nature of the application doesn't work that way, however. We have 2 different systems.  the one LabVIEW is running on feeds transactional data to the second system.  Due to IT rules and setups, we currently do not have the means to receive feedback from the 2nd system that a new transaction should have been initiated.  I do need to figure out how to keep this window active.  They shouldn't be running anything else on the LabVIEW station, but I've been advised, operators may be opening email and leaving it open while feeding the system, so we are losing scans. 

---

Those pesky requirements.  😉  Thank you for being gracious with your answer.

I'm thinking that the best solution really is to make that computer only for running the scanning program.

My reasoning:

No matter how you handle it, someone's going to get mad.  If you did succeed in bring the box to the foreground, for example, someone's going to be annoyed that some of their email typing went into the box instead and caused a bad scan.

[dbrown78]

I still don't disagree.  The constraints IT has placed on us force us to do it in this manner.  The station running LabVIEW is a company machine and it connects to our network.  the other one is a vendor's machine and IT won't allow it on our network. They've allowed us to configure a second NIC to generate a 1 way communications bridge, but this all they will allow us to do.  We are working on another solution to get around that, but for now and possibly quite some time, we are stuck with it.  (If they'd let the other machine on the network, and I could reach our servers from it, this wouldn't be an issue...)

As far as operators checking email.  they aren't supposed to be doing that on this machine anyway.  so, they'll get over it, lol.  

So, back to my question, is there is a way to force a LabVIEW window to be in front of all others, despite application?

[billko]

Not so sure you can put the focus on a child window.  Would it be possible to put the box in the main window?  I know I'm skirting the question pretty good, but it's all I have.  Sorry.