I have a win32 application, there is an button on the main window.
When i click the mouse left button, i receive the WM_LBUTTONDOWN message, when i release the mouse left button, i receive the WM_LBUTTONUP message, that is normal.
However, if in the processing of message WM_LBUTTONDOWN, (while i am holding the mouse left button), the program show a modal dialog window, the button will never receive the WM_LBUTTONUP.
This becomes an issue because in the WM_LBUTTONDOWN the program did something that needs to be clear up in the WM_LBUTTONUP. Now because of the modal dialog, there is no chance to clear up anymore.
Is there a better way to handle this? I tried SetCapture, seems still can not receive the WM_LBUTTONUP.
This is quite reasonable. When you show the modal dialog it starts its own modal message loop. And so it will receive the WM_LBUTTONUP message.
The fundamental problem that you have is that you are showing the modal dialog in response to WM_LBUTTONDOWN, when in fact you should show it in response to WM_LBUTTONUP. Try pressing buttons in other applications and note that the action occurs only when the button goes up. You should do likewise and follow the platform standards.
Related
I just want to ask what command in Ruby allows you to check if an application made in Ruby or running application is about to be closed? For example, I have an executable file that i ran and I clicked the close button on the window. I want to make a pop up of a dialog that says "you are about to close". Once you pressed the OK button, the window finally closes.
How can you do this in Ruby?
I don't know how things work in Ruby, but in general, on Windows, when a window receives a request to close, its window procedure receives a WM_CLOSE message. This is the place to display prompts to the user. If the app then wants to block the window from closing (because the user wants to reject it, etc), the app can simply skip destroying the window, and not pass the message on to the default message handler (DefWindowProc()).
In the case where the user clicks on the window's close button, or chooses the "Close" option from the window's pop-up system menu, or presses ALT-F4 while the window is in focus, the window receives a WM_SYSCOMMAND(SC_CLOSE) message, and if the message is passed on to the default message handler, the window then receives the WM_CLOSE message.
Take that information and translate it to Ruby as needed.
I am a beginner with WINAPI and have been trying to understand the Windows messaging system.
While I have learnt that the GetMessage function in WinMain receives all messages sent to a program, I am unable to grasp as to how the API sends a message to a control (say a pushbutton) that it has been clicked by a user? I have gone through tons of pages and am not able to find the exact sequence of messages, starting from the application thread's message queue upto the pushbutton control.
I hope the question is not too "stupid" to merit an answer. Believe me, I have gone through tons of webpages, including MSDN and nowhere am I able to find a straightforward answer. I would really appreciate someone pointing me in the right direction.
When a mouse event occurs Windows searches all the windows on the desktop to find the window that's currently under the cursor. If multiple overlapping windows are under the cursor it picks the topmost window. Child windows are normally on top of their parent window, so this search prefers child windows over their parent window. Windows then posts a mouse event message to the message queue of the window it found.
The program that created the window should have some sort of message loop running in the thread that created the window. This loop normally calls GetMessage to pull messages out of the queue one by one. These messages are passed in turn to DispatchMessage which looks at the message find out which window it should be sent to. It then passes the message to the window by calling its window procedure.
So when you click on a push button control the mouse events are dispatched to the windows procedure for the control. The parent window of the control isn't notified, at least not directly. The button will generate a number of messages as result, some sent to itself, some to its parent. Notably it will send a WM_COMMAND message to let its parent know its been clicked.
The specific sequence of messages that happen when clicking on push button in a top level dialog box is something like:
WM_LBUTTONDOWN: Posted by Windows to the push button when the mouse is clicked over it.
BM_SETSTATE: Sent by the push button to tell itself to draw itself in the pushed state. This give subclassed controls an opportunity to do their own drawing.
WM_CTLCOLORBTN: Sent by the push button to its parent to find out what brush it should be drawn with, which it then ignores. This message does however allow the parent to change the text of the message before its drawn.
WM_LBUTTONUP: Posted by Windows to the push button when the mouse button is released.
BM_SETSTATE: Sent by the push button to tell itself to draw itself in the unpushed state.
WM_CTLCOLORBTN: Sent and ignored as previously
WM_CAPTURECHANGED: Sent by Windows to the push button telling it that it's no longer capturing the mouse. The push button captured the mouse when it received the mouse button down message so it would be notified of the button being released even if the pointer was no longer over the push button.
WM_COMMAND: Sent to the parent to notify it that the push button has been clicked.
Indentation indicates where messages have been sent in response to a message. Posted messages go through the message queue before being dispatched to the window procedure that handles them. Sent messages are sent directly to the windows procedure that process them without going through the queue.
What could prevent a dialog from being displayed modally in foreground in some circumstances?
A process (KeePass.exe) owns a hidden window. A global shortcut (CTRL+A) displays a dialog in foreground. This is done using the DoModal method. And it works.
However, in some circumstances which I do not know, the follwing happens: The window appears in the taskbar and only after clicking on it, it is shown. I created a plugin for KeePass which overwrites the WndProc and waits for a certain WM_COPYDATA message. If this message arrives, the dialog is shown using DoModal. However, in this case it is only displayed in the taskbar and not shown in foreground.
The WM_COPYDATA message is sent from a different process, but this should not matter right? What can be a reason for that?
I am struggling for so long on this, it's so weird that's even difficult to explain the problem.
I tried issuing SetForegroundWindow(hKeePassWindow) before showing the dialog but no change.
I have a dijit dialog that pops up on clicking of a button. This dialog has a button which stands for submitting and one to hide the dialog On click of ok it sends a REST call and gets a response.
On error, an alert box is generated.
But what is happening here in IE 8 is that I need to explicitly again call a showdialog method to retain the dialog on screen.
What is expected behaviour is: when error occurs an alert box pops up and on click of ok the dialog in background retains. But this is not occuring normally. So I need to everytime check response and make an explicit call to show that dialog. If I do not call an explicit showdialog, the dialog simply visually seems nowhere(Gone!).
This is not a requirement if I use other browsers like chrome and FF which retain the dialog unless user himself cancels and hides them.
This explicit calling may not have been a problem unless it caused the blink effect. That is it has some delay and then shows( a sec or two after ok click on alert).
Further adding to the woe is that when this error scenario occurs and if user after clicking ok and then getting the dialog again after a blink follows and clicks cancel on dialog....poof! the behind screen that originally triggered that dialog still remains blurred! Hanging the browser!
Thanks & yes need a help, stuck on this!
My task is to implement a file upload form in a popup sub-menu panel. I am using XmlHttpRequest, so it's important to keep that popup opened until I receive an event status that file loading completed/failed. Onmouseover and onmouseout events are used to show/hide the popup.
On "hide" the popup panel is detached from the DOM, and cannot be used anymore as a listener for XHR events.
When I click form's "Browse" button, a system dialog window is opened above the browser. In IE, Chrome and Firefox in Windows the system dialog disables events handling by page. Which means if you move a mouse cursor out of the dialog window on one of the page element, the page won't do anything like reacting on mouseOver/mouseOut events. Unfortunately, in case with Chrome/Firefox on Mac (Safari is OK) the page elements do react on mouse over/out. And my popup menu becomes closed (due to mouseOut event handler for the popup) -> XHR response is not managed properly.
Assuming having an upload form in a popup is a must, what are the possible ways of keeping that panel/form visible while system Upload File dialog window is up? Probably a Mac specific solution.
Sample code can be seen here http://jsfiddle.net/xqvXG/
Solved this by freezing popup panel and covering the whole page with transparent div ('glass').
In case if user chooses file(s) and upload starts, I remove the glass and unfreeze the popup using the XHR function readyStateChangeHandler (or may do that in handler of load event).
If user clicks Cancel in system dialog window or closes it with "X" button - no events passed to the page and 'glass' remains on screen. Then any click on the 'glass' causes its removal and unfreezing (or simple hiding) the popup menu.
'Glass' is required to make a single one-click point (panel) for unfreezing the popup in case if Cancel/Close were pressed.
I wouldn't say this is a perfect solution (sometimes required extra action), but very close to what I was looking for.