I have a FPS game and using mouse look. I use Mouse.SetPosition to set the mouse position back to center of the game window at every frame. This works great and the mouse look is working very good. The problem is this takes over mouse position for every windows app. If I alt tab to another app, the mouse constantly tries to goto the center of the game window. This seems like very bad behavior. Any idea how to fix this behavior but still allow my mouse look to still work?
It has to do with User32.dll
I was programing an autoclicker to do my homework (AI) simple
And this website helped me alot...
http://www.codeproject.com/Articles/32556/Auto-Clicker-C
Related
I've created a TCustomControl derived class for a VCL application running on a Windows 8.1 tablet.
I'm using the OnMouseDown / OnMouseUp events even though this is obviously touch based.
What I'd like to do is detect a long press - i.e. touch down and hold for 1 second. So in the OnMouseDown event I record the down timestamp, set a flag to indicate the mouse is down and create an anonymous thread which sleeps for 1 second, and then checks the flag.
In OnMouseUp I set the flag to false.
This works as long as you wiggle your finger on the control. Otherwise if you just touch and hold the mouse down event is not called until you release your finger.
I've look at gestures, but that just looks completely overkill and from what I understand doesn't support long press anyway.
Thanks for any suggestions.
Richard
What you're facing is "normal" yet ridiculously stupid behaviour of Windows with touch input devices. We're facing the same issue for a while now, and are trying to solve it actively for the last couple weeks.
The trick is, that windows handles touch input device as "mouse, that can be fully controlled with single finger". Therefore, it has several states, more than events:
Events are: Touch begin (down), move, up, right click, and if you really want to register for a callback you'll get stationary (not moved since last report but still down).
Meanwhile, there are more states. First, when you press your finger down, it internally detects "Touch down!" event. It than waits a certain amount of time (which might or might not be available to hack-change, depends on drivers etc...), to determine whether what you wanted was a right click (after x time, upon release !before Y time! it will fire right click event) or whether it was a left click down (triggering event TouchBegin - after y time, which is LONGER than x-time, and after the y expires, it will fire left down event (not click!)).
Meanwhile, if the first touch down is interrupted by either move or - !! while waiting for x time to expire!! release of the finger BEFORE x time is ran out, it will automatically trigger left down (on move) or left click (on release). Same goes for any time after the Y time expires as well, or MOVE is triggered.
To put it more simply and understandable, I'll try to give an example:
Let's say that you have touch device, and the timings are as follows:
Point B is beginning, positioned at 0 seconds of our timeline.
Point X is first trigger breakpoint, positioned at 5 seconds of our timeline.
Point Y is second trigger breakpoint, positioned a 10 seconds of our timeline.
You put your finger on touch, and that starts the timeline.
Possible scenarios:
- You release it anytime before point X -> Left click is triggered (Touch down and up events, in order immediately one after another)
- You release it after point X but before point Y -> Right click is triggered (Touch down and up events, with right click flag)
- You reach point Y - Left down is triggered!
- You release it after point Y anytime, no matter if move triggers between release or not (but move is NOT triggered before reaching this point in timeline) -> Left up is triggered.
You trigger (do) move event before reaching point X -> Left down is triggered, followed by as many move events as it detects it, until you release it -> then left up is triggered
You trigger (do) move event after X but before Y -> same as above!
You reach point Y and move it afterwards -> check point no4 above.
Hope this is making any sense to you.
Now to jump to the possible solutions: Custom driver would be one option, but we're not there yet, so we're still trying other options. The most promising for now seems to be use of RAW_INPUT and Touch hooks, looks like we'll have to combine them to get what we want tho.
The bright side is, that windows itself DOES detect when finger touches the device, regardless of the timings and events that it wants to detect, determine and then forward to apps, but they for some reason made it hard to use in such nature. As a proof you could simply check the transparent dot that appears underneath your finger the very first moment you touch the screen.
Meanwhile, Android handles these things way better...
Hope it helps, and I'm happy to come around with the complete solution once we come through and get something good enough for usage.
M.*
If the MouseDown event is not triggered and you want to make your delay counter dependent on it then you are basically screwed. That said, I assume you are open to slight changes of concept. :)
I think it can still be done if you change your button into something like a flip-switch. The user has to "grab" (touch) it, "pull it up" (drag, should trigger StartDrag event) and hold it there for the desired amount of time. Upon release of the switch (MouseDown event), it snaps back down.
To design such a button, you could use a tiny TPanel for the knob and a slightly larger one for allowing limited vertical movement on it. Set BevelInner property to bvLowered and BevelOuter to bvRaised to make it look like a frame and the knob panel its child. Or use a TImage to display the knob in it's up/down positions. In any case, set the knob element's DragKind property to dkDrag or the StartDrag event won't occur. If still no event is fired, please try to detect touch input capabilities and report your findings..
Not sure this qualifies for an answer but maybe it's worth a swing.
it should be simple but I don't find how to do it.
I create a form with a right aligned panel that I color in blue for example.
If I grab my forms left edge and resize it back and forth horizontally quickly, I would like the right panel not to move or flicker. As its position is unchanged, there is no reason why it should not stay completely steady. Does anybody know a simple trick to solve this apparently simple problem?
Thanks
This is just a fact of life with Windows GUI apps. You can see the same effect in a WinForms app and indeed even in mainstream Windows apps. For example, open an Explorer window and do exactly the same operation, resize by grabbing the left hand edge of the window. You will see exactly the same effect. You can see the same effect by resizing from any edge. Word and Excel behave in the same way.
My guess is that Windows repaints in the sizing loop before it sends the resizing message that allows the app to realign its controls.
It not just my curiosity, recently I've received a bugreport concerning one of my AS3 applications. This bug can be reproduced only if the quality in flash player is set to LOW (HIGH/MEDIUM - everything is ok). The bug changes the application behaviour, but it's a mystery for me, why it happens only for LOW quality while quality is said to influence rendering and visual appearance, not the code or behaviour.
Briefly, I have a menu panel (MovieClip) with several items (also MovieClips). Very simple, it appears on a screen after a MouseEvent and a user moves a cursor from one element down to another. When the cursor reaches the edge of the second item, the menu suddenly disappears.
In my code panel hiding is set on mouse click or mouse out.
Personally, I think, that the problem is in Tweener, I have to use that old piece of code. The menu panel is shown when mouse is above a user icon, and concurrently with the help of Tweener I produce some simple effects on this icon.
I have explored adobe and firefox (my app is for web browsers and the bug is reported for firefox) bugtrackers, but so far I have found nothing. Maybe misbehaviour of flash player 11 with Arrays, already fixed... I've run out of ideas.
From the docs:
LOW
Specifies low rendering quality: graphics are not anti-aliased, and bitmaps are not smoothed.
If it only happens when rendering it set to low, then it's probably a timing issue - i.e., the bug has always been there, but because you're wrapping up rendering earlier, you can trigger then bug. Is the bug reporter's computer a slow one? Is there a lot happening at once? Is the menu being removed, set to invisible, or repositioned?
Like #jeremynealbrown said, try and separate out your class to a simple project to make sure there's nothing wrong with your logic there.
Another method, override the removeChild() method, and visible and x and y properties to see which one is setting it, then put traces before all calls that call these to see what's triggering it.
If you think the problem is in Tweener, add a MOUSE_OVER listener to the menu panel that calls something like removeAllTweens(), no matter the state of the menu panel. If the bug doesn't happen anymore, this will show you that it's related to the tween engine.
As a long time user of Delphi 7, I've rolled my own mouse wheel handling in a few controls but lately I've noticed that some recent applications only need the mouse cursor to be placed over a control (e.g. a list box or tree view) for the mouse wheel activity to cause that control to scroll.
This feels nice (as opposed to having to click focus a control before it responds to the wheel).
Now I've moved to Delphi 2010 I'm wondering what is the 'correct' behavior?
And what can I use in Delphi that avoids me having to bodge this with my own solutions now?
Thanks.
I don't know if there's an official 'correct' behavior, but I personally find it most intuitively correct when the mouse wheel goes to the window that the mouse pointer is currently hovering over without having to explicitly give it focus. That's not the default behavior, however, and it seems that about half the applications I normally use do it one way and the other half the other way.
To get mouse wheel messages without having focus, you need to implement a mouse hook.
I have the following situation
I handle when the left mouse button is pressed in my Silverlight app and do some things while the mouse is held down and the mouse moves. When the left button is released, I turn off the flag that's telling it to do the stuff and the mouse movement handler then no longer does the stuff.
The problem is: if the user is in the control area, pushes the left button down and moves out of the control area, then releases the button and reenters, the MouseLeftButtonUp event never fires and the processing continues until the user clicks the mouse.
My temporary fix was to turn the mouse flag off on MouseLeave but that's not really what I'm going for. I'd like to check to see the mouse's left button state in the MouseEnter event, but I don't know of a way to do that.
Does anyone know of a way I can access the mouse button state outside of the press events in Silverlight 3? Thanks,
Update
After thorough research, it doesn't look like this is possible in Silverlight 2 (and probably 3.) I found this link. If anyone knows of a workaround, please let me know.
What you need to do can be accomplished with the UIElement.CaptureMouse method:
http://msdn.microsoft.com/en-us/library/system.windows.uielement.capturemouse%28VS.95%29.aspx
When a UIElement has captured the mouse, it will continue to receive mouse events even if the mouse leaves the Silverlight control.