Want to choose to bypass or passing on the ~LButton Topic is solved

[Hotte]

I`d like to gain full control over the left mouse button inclusive of click&drag.

When I am using:

Code: Select all

LButton::(something)

=> something is being performed, however I eventually need to add a "click" statement to perform an action AND, sadly, click&drag will NOT work anymore with LButton::

When I am using the tilde like:

Code: Select all

~LButton::(something)

=> something is being performed, click&drag will work fine, however LButton will be passed through to the window the user clicked onto

In some cases I need BOTH in one something-function, dependent on the result of an if-Statement:
EITHER perform something AND pass on the LButton through (also click&drag)
OR perform something AND DO NOT pass on the LButton

Does anyone know how this can be achieved ?

[foxhunter]

With #IfWinActive you can assign different LButton for different windows.

[Hotte]

foxhunter, I need to use the same #IfWinActive for the same window but different situations like this:

Code: Select all

~LButton::myfunction()

myfunction()
{  static check
	; ... some checks ...
	if check		
	{	msgbox You pressed the LButton, but that is not allowed at the moment. I eat up your click now.
		exit
	}
	else
		msgbox You pressed the LButton. I will now pass the click to the window you clicked onto  
}

The "if check" branch won´t work: I cannot avoid the LButton click to be passed on to the underlying application.
If I leave the tilde (~) away, the else-branch will not work (apart from coding a "click" statement, which is a pretty bad solution, since click & drag won't work)
How can I make both work within one function ?

[Nextron]

Something like this:

Code: Select all

#If ConditionLButtonPassThrough() ;Must return TRUE in order to pass through LButton and must finish quickly, so no MsgBoxes
~LButton::
#If
LButton::
	MsgBox Do your stuff
Return

ConditionLButtonPassThrough(){
	Return A_Sec&1 ;True on times with odd seconds
}

[Hotte]

This use of #if did not come to my mind.
Now the following:

Code: Select all

#if blockMouseClick()
LButton::Return

#if									; Could be replaced by any  #ifWinActive blablaWinTitle

blockMouseClick()
{	if not clickCheckActive				; This is a global switch variable, which is activated in my code when needed
		return false
	MouseGetPos,x,y,win_id,ctrl
	if (win_id = ...) and (x >...) and ...		; determine window and area, where clicks are not allowed
		return true					
	else
		return false					; all other windows and areas stay unaffected
}

Where clicks are not allowed, true is being returned, which blocks the LButton.
If clicks are allowed, false is being returned and LButton is not being blocked at all.

Very nice, Thanks!

[Hotte]

Mmmhh, sorry to ask again, but I found a new problem:

The example above works fine as long as the user clicks LButton WITHIN the protected window. However, if ANOTHER window is active and the user DIRECTLY CLICKS on LButton FROM OUTSIDE INTO the protected window, the LButton is being passed on to the protected window. I cannot block LButtons in all the other windows to avoid that.

In this case I would need something to clear the passing on of LButton within an ~LButton function.

Any ideas ?

[Nextron]

The cursor coordinates are relative to the active window, so the range is offset when you click with a different window active. I think it would be easiest to correct, to use CoordMode,Mouse,Screen to make MouseGetPos return screen coordinates and then subtract the target window position coordinates you get from WinGetPos,x,y,,,% win_id.

[Hotte]

That was the right idea. I even do not need the coordinates, just the window:

Code: Select all

#if blockMouseClick()
LButton::Return

#if									; Could be replaced by any  #ifWinActive blablaWinTitle

blockMouseClick()
{	CoordMode,Mouse,Screen
	MouseGetPos,,,win_id
	CoordMode,Mouse,Relative
	WinGetTitle,wt,ahk_id %win_id%
    if (wt = "myProtectedWindowTitle")
    	Return true
    else
    	Return false
}

Of course, one could Winset,Disable,,myProtectedWindowTitle
but that is not exactly the same thing. In reality I only block a certain area within the protected window, but that does not matter here.
Thanks a lot!