Event Structure for inactive window

[Jay14159265]

---

@billko wrote:

---

...

---

It's desired because if a pop-up shows up in front of the app that has focus, the first click on a button on the pop-up will set the focus, not click the button.

---

Do you mean a popup from the app that is the original active window or a popup from some other app? 

[Jay14159265]

---

@zou wrote:

Inactive window does not get mouse click message is the Windows default behavior.

LabVIEW buttons are not Windows objects.

Why animation works?  An NI mistake.  Should not overwrite Windows default behavior.

---

I have been clicking around on apps all day today to see what they do in this case. I have found that *most apps* will act on a button click even though the window is not the active window. I agree with *most apps* that an app should honor a button click no matter the window state, especially if the button is animated.

[altenbach]

According to this old discussion , there was once an ini setting (dropThroughClicks=True) to control that. Not sure if it still exists.

[Jay14159265]

---

@altenbach wrote:

According to this old discussion , there was once an ini setting (dropThroughClicks=True) to control that. Not sure if it still exists.

---

That is exactly what I am looking for but I do not see the option in LV2021. 

[mcduff]

The ini modification would be best, but the low level window command did work in Win11, 2024Q3

[Jay14159265]

---

@mcduff wrote:

The ini modification would be best, but the low level window command did work in Win11, 2024Q3

---

Do you know if there is a similar .net call? 

[mcduff]

---

@Jay14159265 wrote:

---

@mcduff wrote:

The ini modification would be best, but the low level window command did work in Win11, 2024Q3

---

Do you know if there is a similar .net call? 

---

I'm sure there is, but good luck finding it. According to AI

  using System.Runtime.InteropServices;

    public static class WindowHelper
    {
        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool SetForegroundWindow(IntPtr hWnd);

        // ... other methods
    }

Is that the mscorlib?

[Andrey_Dmitriev]

---

@mcduff wrote:

The ini modification would be best, but the low level window command did work in Win11, 2024Q3

---

There are lot of conditions needs to be met to get this running and related to the thread...

Use SetWindowPos instead https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowpos

[mcduff]

---

@Andrey_Dmitriev wrote:

---

@mcduff wrote:

The ini modification would be best, but the low level window command did work in Win11, 2024Q3

---

There are lot of conditions needs to be met to get this running and related to the thread...

Use SetWindowPos instead https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowpos

---

Moving the window to the foremost would set its position on top in Z order. What other conditions, considerations are needed? A quick test showed that the call to the DLL worked. Am I corrupting the memory?

[Andrey_Dmitriev]

---

@mcduff wrote:

---

. What other conditions, considerations are needed? A quick test showed that the call to the DLL worked. Am I corrupting the memory?

---

I mean these:

The system restricts which processes can set the foreground window. A process can set the foreground window by calling SetForegroundWindow only if:

• All of the following conditions are true:
  • The calling process belongs to a desktop application, not a UWP app or a Windows Store app designed for Windows 8 or 8.1.
  • The foreground process has not disabled calls to SetForegroundWindow by a previous call to the LockSetForegroundWindow function.
  • The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
  • No menus are active.
• Additionally, at least one of the following conditions is true:
  • The calling process is the foreground process.
  • The calling process was started by the foreground process.
  • There is currently no foreground window, and thus no foreground process.
  • The calling process received the last input event.
  • Either the foreground process or the calling process is being debugged.

For me (LV2025 Q3 x64 v.25.3.2f2 on Win11 LTSC 24H2 v.26100.4946) SetForegroundWindow doesn't work, the FP window was not brought to the foreground, and the return value is zero (and yesterday evening I was too lazy to check it why exactly).