Win API WS_EX_NOACTIVATE Window Style Problem

[tst]

Thanks for the reply. It's always good to have someone who knows the details of what happens inside the code.

---

intvsteve wrote:

Given the original example VI, I was able to activate both the VI and the .NET form ...

---

I'm not in front of LV at the moment, so I can't check this myself, but I assume that when you say "activate" you mean that the window does grab the focus. That's normal behavior for LV and not what we care about, so I would like to ignore that for now.

What interests me more at the moment is that I did manage to do what we want, albeit sporadically. When I managed to replicate this with my old test VI (which calls Keybd_Event to simulate a key press) it did work as I wanted it - clicking the button in my VI caused the correct letter to appear in the Notepad window. Unfortunately, at the time I didn't think about trying to type in a LabVIEW window. Since you say this allowed you to activate the window, I assume this would actually fail (the keyboard VI would get focus), but it's possible it could work if it was a separate process.

I don't suppose you have any guess as to how I managed to get it to work as we want, right? I'm assuming I'm hitting some corner case in the "non-trivial" window activation code.

[intvsteve]

In peeking at the messages sent to the form, that window does not appear to receive key focus, though it does get activation messages. I can activate the form directly via the 'grouper' button in my taskbar without activating an intermediate LV window. (By activate, I mean 'make the title bar turn blue, and it's the top window in the LV Z-plane' 😉

On the other hand, the LabVIEW VI window does receive key focus events - the Window Manager is imposing this behavior in addition to activation (using SetFocus). Although internally we do have some special kinds of windows for which we do not 'force' key focus, VI windows are not such creatures.

As an aside, using the OS APIs to directly manipulate LV windows is a brittle path to follow, though I have seem some pretty impressive feats accomplished that way. (Often much to my surprise! 🙂 For the benefit of the brave ones out there who attempt this sort of thing, here are some problems that arise in the general case when using the Windows APIs :

• FindWindow() is unreliable - you can have multiple windows with the same title bar text and window class - which one will you find? It's even more muddled if you have >1 LV running, but that is not necessary.
• Depending on VI window settings (modality, title bar, et. al.) the underlying OS window structure may be destroyed and recreated between 'edit' and 'run' time.
• Changing window settings at run-time may also cause a window destroy/create, rendering the HWND discovered via FindWindow invalid. This is similar to the previous case.

It's unfortunate that LabVIEW can't meet your specific needs for this part of your project. You can request this feature for a future release (there are likely others who have similar needs).