I currently develop an application providing the possibility to drag&drop items from one ListBox to an other. This is working perfectly while using a mouse.
However, when trying to do the same with a touch screen (producing genuine touch events) this will not work.
In my logs I see that the TouchDown and Move is actually detected. But the call to System.Windows.DragDrop.DoDragDrop() does not block as it is the case during mouse usage. It immediately returns, so the drag gesture ends right after it started.
I assume that DragDrop.DoDragDrop() is geared for mouse usage only and depends on a MouseButtonDown during the complete process of dragging?!
So, is there an equivalent for using drag&drop with touch events?
Thanks for any hints
OK, sorry.
This is one of these questions which you are able to answer yourself... after some time.
And it even was not related to drag&drop itself.
Just this much:
Drag&Drop was working fine with touch. However, WPF swallowed an exception which occurred while determining a visual for dragging within an adorner. This logic had to be adjusted for touch events...
Related
My Mouse has started to double click on single clicks, and I know this is a somewhat common issue. I am wanting to handle all mouse click events to fix this issue in software. I know "LowLevelMouseProc" has some decent control, but through many Google searches, I just can't seem to find what I need. There are two main functions I need is.
My application to be the first in the "CallNextHookEx" chain (The Main issue).
To be able to deny or force button state changes for on mouse press, and on mouse release.
and I do know about the "Left Mouse Button Fix" program, but it does not handle drags after a phantom click(after Mouse Release it does not allow for Mouse Press)
I would imagine that to filter everything the mouse puts through would take a colossal amount of time to fix a problem that will only get worse.
I know that this isn't a programmer's fix to the problem, but I had a similar trouble. I took an afternoon and fixed my mouse using some instructions I found on the web. I couldn't find the ones I used, but these are great. I would suggest that you have plenty of light and a magnifying glass.
Door number 3 is just buy a new mouse...
Using methods that work in code might be fine but not knowing exactly what is going behind the scene is not such a good feeling. Fees like a gap or incomplete job.
I happened to find ReleaseMouseCapture() and have used in a method (OnMouseUp event) since seemed necessary but I noticed using or not using this method doesn't affect the visual part of my application at least
Can you give me some idea when we should be using it?
Thanks.
MSDN says:
When an object captures the mouse, all mouse related events are treated as if the object with mouse capture perform the event, even if the mouse pointer is over another object.
Depending on exactly what you're doing it may or may not makes sense. We would need some more information. But what it boils down to is, the object that captures it will listen and receive for all events from the mouse. This way you can better organize your mouse logic. For example, Dragging an object around a screen would be perfect for this since the object itself would be getting all the mouse events.
But, if you're only using ReleaseCaptureMouse so not sure why you're using it. Are you using CaptureMouse anywhere?
I use it whenever I write code to capture the mouse, and need to release the mouse capture when I'm finished.
A typical example would be dragging/dropping controls. When I begin a drag operation, I sometimes wish to have the application or a control capture the mouse so any movements made with the mouse are sent to the specific application or control, regardless of the mouse's actual position. When the user releases the mouse button, I need to release the mouse capture so the application/control stops receiving mouse events that its not interested in.
You only need to call ReleaseMouseCapture if you have called CaptureMouse, so in your case it doesn't sound like you need it.
Capturing the mouse means that the control receives mouse messages even when the mouse moves outside of the control's bounds. It is used for things like drag & drop where the drop will occur outside of the control.
We have a C# .NET 3.5 UI client application that runs in a multiple monitor desktop environment (typically 4 screens) on Windows 7. Every so often, after running several of these applications, the screen stops redrawing.
Controls continue to be reactive to clicks or keypress and values can be updated programmatically, but the entire form is not redrawn to reflect any changes. For example buttons that are enabled/disabled based on state may be remain grayed out, but be reactive to clicks or vice versa. Buttons do not animate when clicked.
Workaround: minimizing and restoring the window appears to clear the problem. After this, the application begins to draw correctly.
The must frustrating aspect of this problem is that programmatically, everything appears to be running normally. No exceptions are caught in our logs. Nothing was visible in the system event logs. We have not found a way to detect this condition is happening yet.
Other miscellaneous aspects: logging uses log4net, server communication layer uses ZMQ
Update:
Calling form Invalidate() and Update() does not fix the problem.
When dragging the window between screens, it shows different values on each screen.
Minimize/restore still resolves the issue.
I can't be sure of anything without seeing the app and the code, but my best guess is someone calls .SuspendLayout() before a complicated update, and an exception (probably swallowed) prevents the code from ever reaching the corresponding .ResumeLayout(). To test this, try adding a button that calls .ResumeLayout() for the form.
It seems the solution is there:
1) http://blogs.msdn.com/b/alejacma/archive/2009/08/11/controls-won-t-get-resized-once-the-nesting-hierarchy-of-windows-exceeds-a-certain-depth-x64.aspx
2) http://support.microsoft.com/kb/2664641/en-us
I am implementing a program in C# which can "Play" multiple instance of a game at the same time. The actions of the spawned instance is based on my actions. For example, when i click at position X, Y of the main instance, there will be mouse click at the same position in all other spawned instance.
I can do the mouse click, mouse down, mouse up by hooking the mouse event, and simulate the same mouse click on position based on the position of the each game window. However, this approach does not help if it comes to mouse dragging. And it has some setback in performance when i have to loop all my game instances to do a virtual mouse click.
I have found out that it is possible to create multiple mouse using the MultiPoint SDK from Microsoft. However, I could not find any documentation about if it is possible to simulate the multiple mouse click events (other than mine) in C#? If it is then how can i do it?
Thanks
Unless you are manipulating a program you didn't write, I think you might be using the wrong API for the job.
If you need to script multiple actions on multiple windows, you are probably better off running them sequentially. It will be easier to code and debug and you won't have to do anything special. Just script each action sequentially and then execute them.
I'm working on a docking project, in which I need my form to dock itself into a window that doesn't belong to my application. I have no problem detecting the location of the window, however I haven't got a clue on how to intercept the event of movement of the window. Does anyone know how can I intercept the event of movement of a window?
Maybe this post will give you some clues.
An alternative way (but not very nice) would be to have a timer that fires every 500 milisecs and checks each time for window position and compare with the previous one. Then if different adjust your window accordingly.
Listening for window messages requires injecting code in the process whose window you want to dock to. You cannot inject C# code, you can't reliably get the CLR initialized in that process. You'll only have a fighting chance if you use native code. Google EasyHook. Black belt Win32 API skills are required to bring this to a good end.