This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(67.2, 85%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EY%3C/text%3E%3C/svg%3E)
Hi,
The application and anything else freezes, if i click the close button by my own MOUSEEVENTF_LEFTDOWN/UP.
I'm blocking WM_LBUTTONDOWN/ UP by a mouse hook to forward my own injected input. I can click everything (buttons, listview items) except the close button.
If it freezes and i open the task manager, the window closes immediately and the WM_CLOSE gets executed, the same in Debug and Release mode.
I avoid injected input in the hook:
if (MSLLHOOKSTRUCT* pMouseStruct = (MSLLHOOKSTRUCT*)lParam; nCode >= 0 && (pMouseStruct->flags & LLMHF_INJECTED) == 0)
It seems, as if the close button doesn't accept injected input.
What could be the solution here?
Regards
Ok,
Tested it with WM_LBUTTONDOWN/ UP from a keyboard key and that works. It doesn't work only with injected input from the mouse. I have no problems with any other application on my pc, Win Forms included.
Don't know, if that is a bug?
Note that WM_LBUTTONDOWN/UP is used for mouse messages and keyboard messages are such as WM_KEYDOWN/up.
Really don't know what to do:
https://github.com/microsoft/microsoft-ui-xaml/issues/7858
Should i change to Electron. As i saw, the memory was pretty low in WinUI, in Electron it's not.
I could safely ignore that:
The docunment shows: The mouse_event function synthesizes mouse motion and button clicks.
It is recommended to use SendInput instead
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput
WM_LBUTTONDOWN/UP is viable, but be aware that you must get a window to create and deliver messages.
Hi Tong,
have you read my Github entry?
I hope it's understandable. My problem is that everything behaves as expected, if i use SendInput for the remapping of the mouse. The only thing that doesn't work, is that wherever i remap the MOUSEEVENTF_RIGHTDOWN/ UP on my mouse, the close button within WinUI 3 doesn't react respectively it freezes the window. When i send MOUSEEVENTF_RIGHTDOWN/ UP from a remapped keyboard key by SendInput it works, strangely.
I'm going to try updating WinUI 3 but i don't think that this will work. I will spend the day to read a bit about WinUI 2, UWP etc., I guess (maybe i have to post a new question but i need an alternative to WinUI3 for developing an app that stays in the tray icon menu in C++).
PS: I'm pretty shure it must be something with the WinUI 3 implementation that it doesn't work only with SendInput from withing the same application. I tested it from an other application which based on the same technique and it works when i press the close button in my application by the remapping of the other application.
I looked at the github entry.
Try it, replace postmessage() with PostQuitMessage(), replace WM_ClOSE with WM_DESTROY.
Hey Tong,
I did a bit of quick testing and it works for the close button.
If i use SendInput and additionally PostMessage in front of it:
PostMessage (HandleUnderTheCursor, WM_LBUTTONDOWN/UP, 0, MAKELPARAM(point.x, point.y))
For the moment, i can't say, if my PostMessage is correct (parameters) but it works on the close button. Of course it's not usable for any other usage.
So i have to detect, if the cursor is on the close button and fire the workaround. Not really sure how to do it?
If you can't judge if the parameter in Postmessage() is correct, it is recommended to add a judgment statement to the code and use getlastError() to get the return value, so that it is easier to know what went wrong
I checked the relevant information and judged that what is happening is: Your message loop is NOT being run.
For example, WinProc determined that the user was trying to shut or move the window interactively and entered a shutting/moving modal function.
This function is in a message processing loop watching for mouse messages so that It can intercept them to provide the interactive sizing experience, and will only exit when the sizing operation completes.
I suggest you put some code out, or implement a minimal example, as your operations include hook injection, message queues, etc. There is no way to tell what went wrong and froze the window.
Hey Tong,
Thanks for your feedback. Made me thinking so I went through everything again, tested and found this here.
I assume it's the same issue and before I can test it I have to fix my faster laptop (reinstall stable 1.1) because I've stupidly installed WinUI 3, 1.1.5.
https://github.com/microsoft/WindowsAppSDK/discussions/2968
:)
Checked the link to github, it seems that the problem has been solved, glad you have solved this problem. Fortunately, the main problem is not in the APIs part, otherwise it is a waste of time to modify the code at scale.
Not really solved. In the link he stated that you have to use a non-gui thread for sending the input but it's not working for me.
I've tried std::thread/ detached but whatever i try, the result is the same. The "left button up" doesn't appear in rawinput. It freezes on my windows 10 laptop. If i open the taskmanager, the freezing gets interrupted and the "left button up" appears plus the WM_Close gets executed. Hm, weird.
If that would work, it would appear cleaner to me.
Send some code, or implement a minimal example. It is difficult to tell where the problem lies based on statements alone.
Hey Tong,
I was about to edit the code to post it but only had a few minutes here and there. I've now found a solution, 1-2 others would be possible, but after 3 days I'll let it be and look at it later.
Thank you very much.
static volatile bool isCursorOverCloseButton;
switch (uMsg)
{
case WM_SETCURSOR:
{
if (LOWORD(lParam) == HTCLOSE)
{
isCursorOverCloseButton = true;
}
else
{
isCursorOverCloseButton = false;
}
}break;
case WM_PARENTNOTIFY:
{
// Detects the logical, not physical WM_LBUTTONDOWN.
if (isCursorOverCloseButton == true && LOWORD(wParam) == WM_LBUTTONDOWN)
{
ShowWindow(hWnd, SW_HIDE);// Hide window
}
}break;
case WM_SYSCOMMAND:
{
// WM_SYSCOMMAND, if it's in the own title bar.
// Send NCHITTEST to detect the close button, if LBUTTONDOWN.
if (PostMessage(hWnd, WM_NCHITTEST, 0, lParam) == false)
{
// TODO:
printf_s("Error: %x \n", GetLastError());
}
}break;