Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Possible ControlClick improve


  • Please log in to reply
21 replies to this topic
DoNoBaN
  • Members
  • 7 posts
  • Last active: Sep 16 2013 07:51 PM
  • Joined: 02 Sep 2013

Hello, I lost a lot of time trying to do a simple ControlClick on a 3d party window that ignores it. I thought that was a lost battle until a friend get it working on autoit. It was nice but I don't want to rewrite my script to autoit, I like AHK, his syntax and also I can't understand why autoit could do and ahk not.

 

Well, testing the same things that I've tested a lot of times I found the solution, If I send the ControlClick when cursor was over the button, IT WORKS. The @[email protected]€@ button is enable to detect the cursor over it, it changes his color and it seems that ignores LBUTTON messages if cursor isn't over it.

 

Inspired on this thread: http://www.autohotke...n-the-pos-mode/

 

I do this:

 

ControlClick2(X, Y, WinTitle="", WinText="", ExcludeTitle="", ExcludeText="")  
{  
  hwnd:=ControlFromPoint(X, Y, WinTitle, WinText, cX, cY  
                             , ExcludeTitle, ExcludeText)  
  PostMessage, 0x200, 0, cX&0xFFFF | cY<<16,, ahk_id %hwnd% ; WM_MOUSEMOVE
  PostMessage, 0x201, 0, cX&0xFFFF | cY<<16,, ahk_id %hwnd% ; WM_LBUTTONDOWN  
  PostMessage, 0x202, 0, cX&0xFFFF | cY<<16,, ahk_id %hwnd% ; WM_LBUTTONUP  
}

 

It works perfeclty! ¿Maybe is doing autoit this as default? It clicks without moving my cursor.

 

it's a happy day for me (a lot of time without success....). I hope it could help to do AHK better. Regards.

 

PD: I've also tried with WM_MOUSEHOVER 0x2A1 but doesn't work with my window. Maybe it works in another windows...



guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011
a guy in the Support forum recently had this same problem just a few days ago

his game wouldn't respond to ControlClick nor Posting the WM_LBUTTONDOWN

he found out that he needed to send WM_MOUSEMOVE first and then the game would register the WM_LBUTTONDOWN

http://www.autohotke...to-game-window/

UPDATE:
As I suspected, the culprit was MOUSEMOVE.  I commented out everything except the MOUSEMOVE and the CLICK posts and it seems to work regardless of focus, mouse position or line-of-sight.  One small thing now is that if the mouse is moving in the window when I activate the script, it uses the current mouse position.  This might be because, similarly to the window processing RBUTTONDOWN before the MOUSEMOVE, the mouse position is being updated mid-script and that's where the click is being sent.  I could probably BlockInput but that seems sloppy, however, it might be the only way since I don't really have control over how the window processes the messages or when it pulls certain data like mouse position.


unfortunately i don't know the implications of always sending that MOUSEMOVE message prior to LBUTTONDOWN. would it somehow change existing functionality of ControlClick? will it actually cause the mouse to move? or will the window just 'think' the mouse has moved? plus will other windows respond the same way as Ripture's do ?

VxE
  • Moderators
  • 3622 posts
  • Last active: Dec 24 2015 02:21 AM
  • Joined: 07 Oct 2006

Not all programs respond the same way to ControlClick. It is good that you found a solution to a program that doesn't play nice. Perhaps you would be kind enough to supply the name of the program that requires your workaround so future visitors can find your hint through a keyword search.



guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011
i disagree with moving this to Support. why would you do this?

the guy isn't asking for help, he's already found a solution. he is making a suggestion for changing the way that ControlClick works. he had it in the correct forum to start with

DoNoBaN
  • Members
  • 7 posts
  • Last active: Sep 16 2013 07:51 PM
  • Joined: 02 Sep 2013

a guy in the Support forum recently had this same problem just a few days ago

his game wouldn't respond to ControlClick nor Posting the WM_LBUTTONDOWN

he found out that he needed to send WM_MOUSEMOVE first and then the game would register the WM_LBUTTONDOWN

http://www.autohotke...to-game-window/

unfortunately i don't know the implications of always sending that MOUSEMOVE message prior to LBUTTONDOWN. would it somehow change existing functionality of ControlClick? will it actually cause the mouse to move? or will the window just 'think' the mouse has moved? plus will other windows respond the same way as Ripture's do ?

 

Wops, I searched and researched a lot of days and I didn't find that thread. Mouse doesn't move, I would use just Click instead.

 

Sadly I've tried with another app that I was having problems but it ignores ControlClick/PostMessage if it isn't active (autoit WORKS :@ ) . I will try with a ton of WM_messages like that guy do.

 

 

Not all programs respond the same way to ControlClick. It is good that you found a solution to a program that doesn't play nice. Perhaps you would be kind enough to supply the name of the program that requires your workaround so future visitors can find your hint through a keyword search.

 

The app was a poker site Bet Online, just doing betpot stuff nothing illegal :) 

 

Maybe an interest solution could be let ControlClick current behaviour as default and some option like "Bruteforce" that sends some additional messages.



VxE
  • Moderators
  • 3622 posts
  • Last active: Dec 24 2015 02:21 AM
  • Joined: 07 Oct 2006
@guest3456. I should have explained. It's true that DoNoBaN is making a suggestion for a change to AHK, but please consider the following:
 
- DoNoBaN discovered that program X does not respond to ControlClick as expected without first sending a WM_MOUSEMOVE message.
 
- He suggests changing the inner workings of ControlClick to add functionality to make it work better with program X.
 
- He does not mention the fact that such a change, if implemented, might break other scripts.
 
I believe that 'Suggestions' threads should at least try to benefit the AHK community as a whole, not just users of Program X. Furthermore, the suggested change has the potential to break existing scripts, so it would almost certainly not get implemented.
 
 
Since the move, DoNoBaN has stated that his workaround is for an online poker client, so perhaps this thread actually belongs in Support->Gaming.
 
@DoNoBaN: I'm not sure how often it comes up in Support->Gaming, but some game clients ignore the coordinates parameter of WM_LBUTTON messages and simply use the cursor coordinates (especially if they have their own cursor) for the click event.

guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

I believe that 'Suggestions' threads should at least try to benefit the AHK community as a whole, not just users of Program X. Furthermore, the suggested change has the potential to break existing scripts, so it would almost certainly not get implemented.


i provided another link to show that its not just program X which has the problem, but also another program Y and potentially Z,A,B,C. if you search the forum, there are MANY complaints of ControlClick failing going back for YEARS. this has been an ongoing problem, not just an isolated incident for one particular program. i know this because i've been at the effect of this problem for a while.

do you know for sure whether sending WM_MOUSEMOVE will break other scripts? or are you just assuming that? it doesn't seem farfetched that if we are trying to programmatically reproduce a click, that we would also send a MOUSEMOVE message along with a click message. if sending a MOUSEMOVE message does not actually move the physical mouse, then what could go wrong? i certainly don't know. if you do, then please enlighten us. if you dont know, then it seems a bit pre-emptive to take the initiative to move the thread

i would prefer to let Lexikos review the information and decide. moving the thread to Support, then Lexikos might not even see it. now you as a moderator have made a decision instead of the developer. i dont mean to offend, because you are a good contributor and i've learned a lot from your scripts

VxE
  • Moderators
  • 3622 posts
  • Last active: Dec 24 2015 02:21 AM
  • Joined: 07 Oct 2006

You have framed the suggestion more clearly; I've moved the thread back to Suggestions.

 

So, the suggestion of this thread is to modify ControlClick (or add an alternative command) to issue WM_MOUSEMOVE prior to issuing the button messages.

 

 

You cite problems with ControlClick going back years, yet you don't cite the developers' responses to those complaints. If ControlClick really is the problem, why hasn't it been fixed so far? Are you sure ControlClick is even the problem? How did you reach that decision?

 

 

Also, Lexikos does check the support section.



DoNoBaN
  • Members
  • 7 posts
  • Last active: Sep 16 2013 07:51 PM
  • Joined: 02 Sep 2013

I've analyzed same ControlClick from AutoIT and AHK with Winspector. It seems that AutoIT sends a lot of more stuff, see how many SendMessages between LBUTTONDOWN and UP....

 

AHK -> http://postimg.org/image/cxo7gl9q3/

 

 

AutoIT -> http://postimg.org/image/80amvh7qz/

 

I will try to do a equivalent function with Send/Post Message.



guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

You have framed the suggestion more clearly; I've moved the thread back to Suggestions.

thanks, i appreciate it

So, the suggestion of this thread is to modify ControlClick (or add an alternative command) to issue WM_MOUSEMOVE prior to issuing the button messages.

right, we have at least two examples in two separate apps: the OP, as well as the thread i linked to, which show that sending WM_MOUSEMOVE prior to WM_LBUTTONDOWN does in fact work where without the MOUSEMOVE it doesn't.
 

You cite problems with ControlClick going back years, yet you don't cite the developers' responses to those complaints. If ControlClick really is the problem, why hasn't it been fixed so far? Are you sure ControlClick is even the problem? How did you reach that decision?

i wasnt the OP reporting the problem so naturally i didn't do full amount of research because i wasn't the one reporting the problem. i just remember investigating a similar problem for myself a while back and also finding other people saying that ControlClick is unreliable and works on some windows and not others. ControlClick is obviously the problem because the problem occurs when trying to send a click. the same command works in some applications and not others. i guess the problem hasn't been fixed so far because the problem hasn't been known. just like most problems. happy.png

i just did a search and found an old thread where Lexikos did in fact respond
http://www.autohotke...ng-postmessage/

he says:

The point of posting WM_MOUSEMOVE to a window would not be to actually move the mouse, but to make the window think that the mouse has moved.
...
Right, you do not need WM_MOUSEMOVE. In fact, ControlClick does not use it at all as each WM_xBUTTONDOWN/UP message contains the co-ordinates of the "click". Most applications use those co-ordinates, not the co-ordinates of a previous WM_MOUSEMOVE.


however we've now had two reports that sending MOUSEMOVE does in fact alter how some program respond. and maybe AutoIT's ControlClick command does use MOUSEMOVE (i have no way to check their source), so if they do use it, then there is precedent that perhaps it is beneficial to include. VxE, you yourself suggest that some games ignore the coordinate that is passed with the LBUTTONDOWN message.

none of that is conclusive but i think its a fair question to consider

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
ControlClick "Sends a mouse button or mouse wheel event to a control." Consider this: ControlClick is sending the mouse event, exactly as described, but the program is not responding to it in the way that you intend. Clearly, neither ControlClick nor the target program can sense your intention.

AutoHotkey has numerous methods to automate things, because no single method can work with everything. This is because programs, like the programmers that write them, are extremely varied.

I have no idea whether adding WM_MOUSEMOVE would benefit any program other than those mentioned in this thread, or how common those programs are. What I do know is that any change in behaviour has the potential to break scripts.
 

ControlClick is obviously the problem because the problem occurs when trying to send a click.

I get these sorts of senseless statements at work: The power button is obviously the problem because the problem occurs when trying to turn on the PC.

the same command works in some applications and not others.

Have you considered that there are two sides to this coin? I could say "The command works in most applications, therefore the command is not at fault. The minority of programs that don't work must be the real problem." In reality, ControlClick isn't the same as actually clicking the mouse button, and simply cannot give the same results in every case.
 

It seems that AutoIT sends a lot of more stuff,

It is very likely that AutoIt merely sends an extra mouse-move message, and the rest of the messages are what the program does in response to that message (or as a result of that message having been sent).

DoNoBaN
  • Members
  • 7 posts
  • Last active: Sep 16 2013 07:51 PM
  • Joined: 02 Sep 2013

It is very likely that AutoIt merely sends an extra mouse-move message, and the rest of the messages are what the program does in response to that message (or as a result of that message having been sent).

 

I'm not sure. Winspector didn't catch any WM_MOUSEMOVE maybe SETFOCUS or CAPTURECHANGED are the key. I would like to do a function that tries to emulate it but I'm very bussy this days. I will post my conclusions when I could do it.



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Maybe not a mouse-move message then; my point is that most of the extra messages are very likely to be generated by the program itself, rather than AutoIt. So for instance, attempting to replicate it by posting each and every one of those messages is not a good idea.

guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

I get these sorts of senseless statements at work: The power button is obviously the problem because the problem occurs when trying to turn on the PC.
Have you considered that there are two sides to this coin? I could say "The command works in most applications, therefore the command is not at fault. The minority of programs that don't work must be the real problem." In reality, ControlClick isn't the same as actually clicking the mouse button, and simply cannot give the same results in every case.


please understand my statements were made in a certain context.

when i made those statements, it was in response to VxE. i read him as implying that ControlClick was not the cause of the failed click, but rather other commands or other code in the user's script. maybe that was my mistake

of course there are two sides of the coin. in reality, yes of course you are right: ControlClick doesn't have a problem. these applications have the problem for not responding to LBUTTONDOWN messages in the 'normal' fashion, causing the need for such workarounds in the first place.

however, AHK has commands that do more than simply wrap one winapi in order to accomodate other applications. i think i remember reading somewhere that WinActivate has like 4 different methods of attempting to focus a window, instead of merely only wrapping SetForegroundWindow. surely you could say a similar thing there, that if an application doesn't respond to SetForegroundWindow then its that app's problem. but then why include 4 different options to workaround those other app's problems? to try to make the command as versatile as possible, no? ControlClick itself has the NA parameter to workaround 3rd party app problems too

thats actually another idea. what do you think about adding WM_MOUSEMOVE only when the user uses the NA parameter which is designed to "improve reliability"? or what about adding a new option for the command, maybe something like MM and throwing another note under the Reliability heading of the help file?

DoNoBaN
  • Members
  • 7 posts
  • Last active: Sep 16 2013 07:51 PM
  • Joined: 02 Sep 2013

I've examined with Winspector an AHK ControlClick with NA option. It's more similar to AutoIt messages but not the same. Could anybody explain the differecen between normal click and NA option for I can difference AHK messages from Windows/app auto-generated?

 

I've tried to find it at the source code but I have no idea about where to search.