MouseStillDown?
-
In my background application, I want to "borrow" the cursor for a few microseconds and do some clicking and dragging (in an external application's textbox) in preparation for copying to the clipboard (that part works great), but it is uncool to steal the cursor from the user while he (for example) is in the process of moving or resizing a window as the result IS A MESS and generates some nasty language :-D . So i need to know if the User is currently using the mouse for ANYTHING in ANY other application just before i begin the fun stuff. I'd like some code that functionally looks like: ... while (MouseDown) Thread.Sleep(100); regardless of what application is active. Thanks very much for your time and help!
I don't see why you'd need the mouse to do that; find a better way.
-
I don't see why you'd need the mouse to do that; find a better way.
I'm open to suggestions ... however, the SendInput that worked fine on a 32-bit XP machine no longer worked when recompiled on a 64-bit Vista machine. Dunnno why, but i suspect SendInput might be fubar on x64 machines. SendMessage and mouseEvents weren't great solutions either ... hence the fun stuff. btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
-
I'm open to suggestions ... however, the SendInput that worked fine on a 32-bit XP machine no longer worked when recompiled on a 64-bit Vista machine. Dunnno why, but i suspect SendInput might be fubar on x64 machines. SendMessage and mouseEvents weren't great solutions either ... hence the fun stuff. btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
I bet you are using a wrong struct, where a pointer is held in an int or so. CORRECTION: I know you do, and I told you before. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
I'm open to suggestions ... however, the SendInput that worked fine on a 32-bit XP machine no longer worked when recompiled on a 64-bit Vista machine. Dunnno why, but i suspect SendInput might be fubar on x64 machines. SendMessage and mouseEvents weren't great solutions either ... hence the fun stuff. btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
IceWater42 wrote:
your answer seems arrogant and condescending
Good, I had hoped that had come across. :-D What you were describing just sounds kludgey to me. Like using the clipboard to do a screen capture.
-
I'm open to suggestions ... however, the SendInput that worked fine on a 32-bit XP machine no longer worked when recompiled on a 64-bit Vista machine. Dunnno why, but i suspect SendInput might be fubar on x64 machines. SendMessage and mouseEvents weren't great solutions either ... hence the fun stuff. btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
IceWater42 wrote:
btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
Well, since Windows is a shared system, your app has to work and play nice with others. Since your solution is grabbing the mouse away from the user rather violently, and completely unreliably, I'd say it's your solution that's arrogant and condescending, to the user. There is no way for you to know that your've about to grab the mouse away from the user in the middle of a double-click, or some other operation. The user is liable to think there is a problem with the mouse. You don't see other application doing this at all, do you?? Maybe there's a reason for that...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
I bet you are using a wrong struct, where a pointer is held in an int or so. CORRECTION: I know you do, and I told you before. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
yes you did ... thank you. I'll try the 8b pointers if we can find the original program from whence that code came ... he chucked it. If not i'll write a simple pgrom to verify that the 8b pointers solves the problem. Thanks again.
-
IceWater42 wrote:
your answer seems arrogant and condescending
Good, I had hoped that had come across. :-D What you were describing just sounds kludgey to me. Like using the clipboard to do a screen capture.
LOL ... kludgy? ... no KIDDING! It does to me too. I would LOVE to have an alternative solution. What i don't think i need is your admitted arrogance. Please feel free to NOT help me in the future. Sorry to have wasted your time.
-
IceWater42 wrote:
btw ... your answer seems arrogant and condescending. I didn't realize that it was important to get your approval of my method before asking for help on how to do it ... shame shame.
Well, since Windows is a shared system, your app has to work and play nice with others. Since your solution is grabbing the mouse away from the user rather violently, and completely unreliably, I'd say it's your solution that's arrogant and condescending, to the user. There is no way for you to know that your've about to grab the mouse away from the user in the middle of a double-click, or some other operation. The user is liable to think there is a problem with the mouse. You don't see other application doing this at all, do you?? Maybe there's a reason for that...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008My solution is arrogant and condescending? ... rofl I would LOVE to have a conventional solution if i had one. And i would love to explore ideas of the bright people here. But tell me how "I don't see why you'd need the mouse to do that; find a better way." helps in ANY way. How is it worth the electrons wasted to say it? I know it is a terrible approach but i was hoping the more knowledgable people here would offer a bit more than ridicule. Why would anyone EVER want to come here for help if THAT is the quality of the help they are going to get? The jerk owes me (and everyone else he talks that way to) an apology. Unbelievable.
-
My solution is arrogant and condescending? ... rofl I would LOVE to have a conventional solution if i had one. And i would love to explore ideas of the bright people here. But tell me how "I don't see why you'd need the mouse to do that; find a better way." helps in ANY way. How is it worth the electrons wasted to say it? I know it is a terrible approach but i was hoping the more knowledgable people here would offer a bit more than ridicule. Why would anyone EVER want to come here for help if THAT is the quality of the help they are going to get? The jerk owes me (and everyone else he talks that way to) an apology. Unbelievable.
Your use of the mouse and the clipboard is, obviously, not advised at all, since you're overwriting values on the clipboard that the user may need after your operation. From your description, you're only option is to get the window handle to the TextBox and send a WM_GETTEXT message to it, retrieve the pointer that may be returned, and copy the string it points to to your own memory location. No mouse, no copying to clipboard, and no pissing off the user. Google for "C# WM_GETTEXT[^]" for examples.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
Your use of the mouse and the clipboard is, obviously, not advised at all, since you're overwriting values on the clipboard that the user may need after your operation. From your description, you're only option is to get the window handle to the TextBox and send a WM_GETTEXT message to it, retrieve the pointer that may be returned, and copy the string it points to to your own memory location. No mouse, no copying to clipboard, and no pissing off the user. Google for "C# WM_GETTEXT[^]" for examples.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008I'm told the 32-bit XP program used: ... int nRet = SendMessage(hWndC.ToInt32(), WM_GETTEXT, cap, buffer); but the original programmer does not recall why that did not work on the 64-bit Vista machine. Thanks Dave, I'll give WM_GETTEXT another try.
-
I'm told the 32-bit XP program used: ... int nRet = SendMessage(hWndC.ToInt32(), WM_GETTEXT, cap, buffer); but the original programmer does not recall why that did not work on the 64-bit Vista machine. Thanks Dave, I'll give WM_GETTEXT another try.
IceWater42 wrote:
int nRet = SendMessage(hWndC.ToInt32(), WM_GETTEXT, cap, buffer);
It fails on 64-bit machines because window handles in 64-bit Windows are 64 bits wide. Look at what you passed in the first parameter. A signed, 32-bit integer, instead of a 64-bit wide IntPtr. Change that so hWndC returns an IntPtr and it should work.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008