Win API WS_EX_NOACTIVATE Window Style Problem

[alpha1]

Hi Steve,

I passed on a message to a senior LabVIEW expert regarding this issue and I've been asked to find out if running the VI as a background process would suffice, this is what he suggested. I was also given these two links:

Can we run LabVIEW as a background process 
http://forums.ni.com/ni/board/message?board.id=270&message.id=2414&requireLogin=False

Windows API Function Utilities (32-bit) for LabVIEW
http://sine.ni.com/devzone/cda/epd/p/id/4935

I hope they are of some help.

[SteveBale]

Hi alpha,

Thanks for that.

Unfortunately a background service will not work in this instance. I require the User Interface just one that doesn't activate itself when clicked.

That windows API .llb is a usefull addition to my pallette but doesn't appear to have the solution to this problem 😞

Please let me know what your senior LabVIEW expert says, if there is no known solution I may well have to go ahead and use a language I know this works with.

Thanks,

Steve

[alpha1]

Hi Steve,

I understand what you're saying. This is the response I heard back:

Since LabVIEW is one instance in Windows, instead of having multiple handles on each VI, he cannot use the user32.dll like he does with other programs. What he might be able to do is use LabVIEW to pull a handle for the front panel - but it looks like he is already doing this and it's not working.

It appears unlikely that there is a workaround, but I shall definitely update you if I hear anything further.

[zou]

Don't change the window ext style, call EnableWindow instead.

It also disable the keyboard input.

I used it on a project last year for a background "window".

[SteveBale]

Hi alpha, I understand what your colleague is saying, does he/she know this is also the case for a built (.exe) labview application? Thanks.

Zou, according to:

http://msdn.microsoft.com/en-us/library/ms646291(VS.85).aspx

The EnableWindow function enables or disables mouse and keyboard input to the specified window or control. When input is disabled, the window does not receive input such as mouse clicks and key presses. When input is enabled, the window receives all input.

This is not the desired effect in this application, for I still wish my window to accept user input (mouse/keyboard/iodevices) just not to become the active window when this input occurs. This is why I wish to use the WS_NOACTIVATE style.

Thanks,

Steve

[alpha1]

Hi Steve,

A colleague of mine spoke with the LV Expert again and passed on some further clarification on the previous post:

Because LV as an executable has multiple windows, when he gets the handle in the method he is using (user32) it is the handle for LabVIEW and is not specific enough to point to that particular window. Other applications, not just LabVIEW,  have a similar architectures (exe's with multiple windows). Because of this the experts said it is probably possible to do, but it is more of a question about how to pull a handle from a Window inside an exe. Making this more of a Windows question and that you should look in Windows forums or LAVA (since LV specifically does exhibit this structure), someone has probably done this and posted on a forum.

So if he wants to set his Style the way he has been he can search the forums (LAVA, Microsoft, etc.) for more information on how to pull a window handle from inside an exe within Windows OS. Else, we can try to help him do something different with the desired affect within LabVIEW.

Unfortunately, I'm sorry to say that I'm not sure if there is a quick workaround for this.

[tst]

---

alpha1 wrote:

when he gets the handle in the method he is using (user32) it is the handle for LabVIEW and is not specific enough to point to that particular window.

---

The function called in that example was FindWindow which DOES return the handle for a specific window (it asks for the window name and if you give it the names of other windows in the LV process you will get a different handle for each of them).

[tst]

I played with this a bit more now.

First, I should point out that the original example has a problem in that the handle is treated as U16, when it should actually be a 32 bit value. That said, this doesn't seem to make a difference, so I guess that mean that LabVIEW passes the all 32 bits to the DLL.

Second, I did manage to get this to work sporadically. I'm not sure how I managed this, but it seems to have something to do with the .NET form. If I changed focus to it, some of the time the VI would start acting correctly (and I also managed this with my VI, which simulates the key press, so it shows that this can be done in LV). I don't know what caused it to work, though, and I haven't been able to reliably repeat this.

[intvsteve · Accepted solution]

Given the original example VI, I was able to activate both the VI and the .NET form by clicking away from LV, then clicking directly in *some other* LV window, then the form (or the modified VI).

Now, as to why it doesn't work as intended... The answer is simple. The LV window management code uses SetActiveWindow and SetForegroundWindow in a few places. These functions can supercede the style setting - i.e. cause the window to be active even when that style is set. (This is documented behavior.) The window activation code in the LV window manager is ... nontrivial ... and the behavior you're seeing is certainly the result of the LV window manager imposing its will upon what it considers to be the proper behavior of the windows in the LV process.

[SteveBale]

Hi all thanks for your replies.

firstly,

tst: I too have managed to make this work sporadically but there seems to be no general pattern.

I read your last post and began doing some serious digging around the processes and there appears to be 3 "windows" assosciated to a labview built exe. one the main window, another called "closed" (i believe this to be the remains of the block diagram) and a third mysterious window I couldn't work out but presumed to be the parent aka window manager. On my way home just now I began thinking if this parent was where the hooks to the windows system messages live and thought that it must either be ignoring the style changes messages (but if thats the case why wouldnt it ignore them all) or that it was overriding them by reactivating the window itself.

Which leads nicely into intvsteves comment

steve, thanks for clarification your answer shows me i'm not completely mad. However, I do believe the .net form in the first demo can only be activated if clicked on directly after the LabVIEW window, you will not be able to activate it moving directly from e.g. a notepad window.

Conclusion.

For now it looks like setting this window style on a LabVIEW window is not possible, so I will use C# for my GUI and hook it into it from LV where required.

Thanks again,

Steve

Message Edited by SteveBale on 02-04-2010 12:56 PM