In almost any Windows application, I notice that holding the mouse button down in a non-client area causes the painting to stop. Why is this required?
For example, I have a Managed Direct 3D application which displays a spinning cube. If I place the pointer over the title bar and hold the mouse button down, the cube ceases to spin even though I have not coded any such condition into my loop.
Why is painting halted? What are the benefits? Most importantly, how can I work around this?
When you click on the title bar, there's a brief pause while the window manager tries to determine whether or not you're clicking or beginning a drag (moving the window). If you're still holding down the button, then it's a drag: the window manager sets up its own message loop and pumps messages until you release the mouse. Your window should still be able to process messages, because they'll still be dispatched, but if your animation depends on a custom message loop then you'll be stuck 'till the modal drag loop ends.
Work around it by triggering your animation in response to messages: a timer seems like a good choice to me.
Related
Click the minimized window on the taskbar to restore it.
At this time, the slide animation is played and restored.
Can i detect when the animation ends?
This message is generated the moment it is clicked.
(WM_ACTIVATE, SC_RESTORE)
Is there no message at the time when it is completely restored to the screen?
I'm trying to implement system-wide drag operation with middle mouse button. It should override middle mouse drag behavior in other programs. Currently, I am handling global mouse events with system-wide hooks.
Problem is - many programs still receive and handle same events like I did not intercept them.
Here's what I tried:
not call the next hook for mouse down event: I never receive mouse up, so I don't know where and when to stop dragging
not call the next hook for mouse move: cursor slows down tremendously
not call the next hook for mouse up: most windows in the system stop reacting to mouse events completely after my drag is finished
always call the next hook in the chain: if the control under mouse has scroll in it, most of the time it will be scrolling while my drag is in progress. Also UWP apps continue receiving mouse events during my drag, so if a link in MS Edge happens to be under cursor when it started, and mouse does not leave Edge boundary, Edge receives click event, and new tab is opened
What I need is: when user holds middle mouse and starts dragging, my drag handler should be called, and no other handlers, like file drag, scroll, etc should happen.
I ended up with somewhat hacky solution:
do not call the next hook for mouse down for middle button
record where it was pressed
when handling mouse up, if user did not drag - replay the whole mouse up + mouse down using SendInput from a separate thread (to avoid deadlock due to reentrancy)
I've been trying with windowDidMove and windowWillMove (NSWindowDelegate) but I think I need something between these two...
Is there any other way to detect when I move my window in cocoa?
I mean - I want to trigger a function if I drag a window to the bottom of the screen, but I want this function to be run even if I didn't yet release the window?
The middle ground you are seeking is handling the mouse events yourself and implementing the window dragging. If you do this you determine how dragging works; so you can constrain the window to an area of the screen, trigger events when the window reaches a screen edge, etc.
You'll need to do some reading, you could start with Apple's Handling Mouse Events.
If you have problems once you've done the reading, written some code, etc. ask a new question, showing your code, and explain the problem you've hit. Somebody will probably help you out.
HTH
Looking at the web desktop sample for Ext-JS I see that when a window is minimized or restored, that there is an animation where a transparent rectangle shrinks down to the task bar or grows up to the window location.
When I look at the same demo for Ext-GWT there is no animation: the window just vanishes and reappears.
Is there a way to turn this animation on for Ext-GWT, and what is the code to do it.
I think you can do it. The catch is that you have to
catch the minimize event
replace your rendered window with a proxy
simultaneously move and resize your proxy
replace your final proxy with the button on the dock bar
I'd consider following the extjs implementation as a guide.
The fact that it isn't represented as a demo suggests that it takes quite a bit of work to put it together.
Usually, when a user holds the mouse pressed over a button, moves the mouse away from the window, and then releases it, the button can tell that the mouse has been released even though the release has actually occured outside the window.
When I inspect mouse clicks in my window, how can I imitate the same behavior?
When a mouse button being pushed down over the window I get the WM_XBUTTONDOWN message, but Windows don't treat it as if anything is logically being "clicked", so after the mouse leaves the window, no further messages will arrive at the window, which results in a "lost" WM_XBUTTONUP message.
When you receive the button down, you capture the mouse. That means that all the mouse events until releasing the capture will be reported to the window that captured the mouse.
See the documentation here. You also have a link to an example from that page.
Use the DragDetect() function.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dragdetect?redirectedfrom=MSDN