Simple binding works but adds unwanted effect otherwise impossible to achieve

[A Keymaker]

I am using Mp3tag. In its main window is a list of files. A user can select one of them by left clicking them - or hold down the CTRL key and select and deselect with left clicks multiple files. And also if SHIFT is pressed down, then the user is able to select an area [thus multiple files] with left click [or with arrows]

So I wanted to be able to that without keyboard, just using mouse - and for that to utilize the middle button, which is totally unused in Mp3tag

And so, this works

Code: Select all

#If WinActive("ahk_exe C:\Program Files\Mp3tag\Mp3tag.exe")
MButton::Send {Control down}{LButton down}{LButton up}{Control up}

in that I can use middle button to select many files one-by-one and also remove them one-by-one. And if some files are selected, then a left click just cancels that selection and highlights just one file [the one under the pointer of course]. So that is OK but not A-OK. Because if I middle click on a file [for selection] and then once again middle click that same file [for deselection because I made a mistake] then a field of that file with data [like _FILENAME] turns into edit mode, where I can re-write stuff. And that is natively impossible to do and I do not want it happening. I tried upgrading the code to

Code: Select all

MButton::
Send {Control down}{LButton down}
Sleep 300
Send {LButton up}{Control up}
return

and changing the Sleep value; but that only slightly alleviates this issue as that unwanted edit mode can still happen, as Mp3ag still registers middle click as left click without CTRL thus leading to a situation that is not suppose to happen [editing one file while also others are selected]. I tried also some KeyWait variations in place of Sleep and shuffling the order of key / button inputs - but failed as they were making Mp3tag or the whole system user un-friendly / glitchy or just plain unusable

So my first question is: how eliminate that switching to edit mode?

Second question is: How to also add that second way of selecting of many files [i.e. with SHIFT being held down] but still using the same middle button [that has to works with CTRL]

Also I have noticed that when running my code, when I use SHIFT to select some files then I can still add to that selection files one-by-one using the middle button - but I am no longer able to de-select them one-by-one in the same way [which I can do normally when the script is not running]

[mikeyww]

Code: Select all

#IfWinActive ahk_exe Mp3tag.exe
MButton::^LButton
#IfWinActive

[A Keymaker]

The above code that not work always- i.e. it still allows sometimes to occur of that normally impossible selection & editing at the same time

Plus it hardly works at all, because even if I add to it

Code: Select all

Sleep 1111

and even middle click very slowly, it still will most of the times cancel whole selection when trying to add another file to those already selected. The same cancellations happen with variations

Code: Select all

MButton::Send ^{LButton down}{LButton up}

and

Code: Select all

MButton::Send ^{LButton down}{Control up}{LButton up}
KeyWait MButton
return

and re-mixes of them [although I very likely missed some combinations]

[mikeyww]

Try the "Up" variety-- just this script by itself, with no other code.

Code: Select all

#IfWinActive ahk_exe Mp3tag.exe
MButton Up::
Send ^{LButton}
SoundBeep, 1900
Return
#IfWinActive

[A Keymaker]

Try the "Up" variety-- just this script by itself, with no other code.
[...]

Now the selecting process in Mp3tag works A-OK. But...


If I click either with left button somewhere outside main window of Mp3tag [as it also has other areas] without loosing prior to this selection of files [by left clicking on the list of files in Mp3tag], or click middle button anywhere outside of Mp3tag - then glitches start to manifests. There are some variants of them and they are similar so there is no point in listing them precisely; but apparently CTRL [or maybe LButton?] is being held down. And thus my clicks do not work anywhere or do not work after going back and forth between clicks in programs and Taskbar - to the point where I am not even able close the AHK file

And so then to unblock inputs or reset the script to the default state [without actually clicking Reload The Script or executing the AHK file once again after gaining back control] I have to press on keyboard ALT + CTRL + DELETE and choose Task Manager. And then am I finally able to take input control of the system and also go back to Mp3tag and execute selection [thus also able to evoke such blockade once again]. And no- pressing just of CTRL itself does not work

Or alternatively to semi-unblock I can try to quickly double [triple?] click middle button somewhere [else than Mp3tag?] thus be able to roam across operating system until I go back to Mp3tag and middle click - because then the blockade comes back. And in that semi-block state is when I stop hearing Beep sound when middle clicking outside Mp3tag


So I figured I needed to add some break / reset command below Send ^{LButton}. And so I have tried adding Send {Blind}{LCtrl Up} to this code and Send {Ctrl} above and below Beep and below second #IfWinActive but it did not help. I also replaced #IfWinActive ahk_exe Mp3tag.exe] with #If WinActive("ahk_exe C:\Program Files\Mp3tag\Mp3tag.exe") but it also did not help

[mikeyww]

It sounds like you might have a basic mouseover problem, corrected as follows.

Code: Select all

winTitle = ahk_exe Mp3tag.exe

#If WinExist(winTitle) && mouseOver(winTitle, "SysListView321")
MButton Up::
Send ^{LButton}
SoundBeep, 1900
Return
#If

mouseOver(winTitle, ctl) {
 MouseGetPos,,, hWnd, overCtl
 Return WinExist(winTitle " ahk_id" hWnd) && overCtl = ctl
}

[A Keymaker]

It sounds like you might have a basic mouseover problem, corrected as follows
[...]

Now this seem to be working - but there are two problems with it


1] After initials positive tests I started just using it. And during that normal workflow usage i experienced a semi-blockade. But I was able to remove it by [if I recall correctly] simply de-selecting files in Mp3tag with a left click. I tried various settings / scenarios but was unable to repeat this blockade ON purpose - but then again it happened after performing some tasks in Mp3tag. And once again I was unable to repeat it on purpose, despite this time being more sure what steps I just took

Despite this, it is a major improvement. And maybe with time I will start to notice a patter and become able to report the exact cause of this glitch minor. Those must be some sophisticated [i.e. rare] conditions for it to occur


2] I personally have to use it as a stand alone AHK file. Let me explain

Having almost zero experience with AuotHotkey and very limited with programming, before I started getting into using it on a daily basis I explained my modus operandi viewtopic.php?f=76&t=104774&p=465290 - and as a result started to collect various pieces together into one bulk AKH with various Windows and other programs adjustments. And until now ever growing collection was more or less OK, but now I need:

A] the above code;

B] this completed code

Code: Select all

#If WinExist("ahk_class MagUIClass")

<^>!l::
    GetKeyState, state, CapsLock, T
    if (state = "D")
        Send {Text}Ł
    else
         Send {Text}ł
return

from viewtopic.php?f=76&t=104768&p=465270#p466566;

C] this not finished yet code

Code: Select all

~XButton2::
    Send {RShift down}{Right down}
    Sleep, 222
    while GetKeyState("XButton2")
    {
        Send {RShift down}{Right down}
        Sleep, 222
    }
    Send {RShift up}{Right up}

from viewtopic.php?f=76&t=104771;

D] possible future codes for the same pieces of software of for some new / other programs;

all in that one group file - and have them working at the same time. And I was told here viewtopic.php?f=76&t=105069&p=467771#p467571 that it is possible to retain my modus operandi of having one bulk AHK file. But code A does not work when put in the same AHK file with code B and / or C [while B and C do work with each other]

So is it really possible in my case? - i.e. to have A, B and C and all future Ds in one place?

[mikeyww]

Generally speaking, yes. You need to manage your directives properly.

If more than one variant is eligible to fire, only the one closest to the top of the script will fire. The exception to this is the global variant (the one with no #IfWin criteria): It always has the lowest precedence; therefore, it will fire only if no other variant is eligible (this exception does not apply to hotstrings). The #IfWin directives are positional: they affect all hotkeys and hotstrings physically beneath them in the script. They are also mutually exclusive; that is, only the most recent one will be in effect.

[A Keymaker]

But about modus operandi like mine [i.e. explaining this in simper words to a small time code tweaker like me]:

Is it then impossible for something like dozens of programs to be affected correctly [i.e. as intended by a user of] AutoHotkey at the same time - because at some point some functions / directives will overlap and / or be mutually exclusive and nothing will be possible to avert that? [Thus I myself already have to choose what is more important to me from the aforementioned 3 scripts and also plan accordingly my future choices. lowering down my hopes for correcting every annoyance and errors of used programs?]

And If yes- then maybe I could use at the same time also some other software like AutoHotkey, that could take over some of the programs, whos adjustments would not collide with AHK scripts?

[mikeyww]

No, it is not impossible for something like dozens of programs to be affected correctly. Please ask if questions remain.

[A Keymaker]

So how can I make it possible then?

The lame way would be to just use multiple AHK files, right? Because there will be no conflicts / overlaps, unless I create such within a given file destined for just one program? But that would be against my plan to control all adjustments from within one central file

So more advanced way would be to use Library feature of AutoHotkey? But then again I still would have various codes for separate programs distributed across their corresponding AHK files - and thus using Library would be pretty much pointless. [And for now I do not have a need to use other possible advantages that come with using Library]

[mikeyww]

I don't think you have provided any specific example of what you need to achieve, but one can typically use If or #If to distinguish the needed conditions within a script.

[A Keymaker]

I don't think you have provided any specific example of what you need to achieve,

Because I still do not now what is possible with AutoHotkey

Or should my answer to that be: I did with the above ABC[D] examples?

but one can typically use If or #If to distinguish the needed conditions within a script.

And I still do not now what is possible

I mean: there is no point in using one bulk AHK file that is suppose to hold all of the operating system adjustments and lack of shortcuts in various programs and as years go by encounter again and again scripts / programs that cancels each other out - thus force a user to make additional AHK files that will hold conflicting scripts

So I should ditch that one-AHK-file approach? Or alternatively use it but only to evoke [and close if needed] other AHK files, with every AHK being designated for one program only?

[mikeyww]

I have a ton of hotkeys that are used in a single script. Using #IfWinActive enables you to specify which hotkeys correspond to specific programs. Easy to manage; avoids software conflicts. I have a few dozen different #IfWinActive sections. I also have a few extra scripts that I run which are more like GUI programs or applications.

Using one script or multiple scripts is not a way to cancel or override what other scripts do. Using one script does enable you to streamline your management and spot problems quickly, regardless of how many different programs you run.

[A Keymaker]

[...]
I still do not now what is possible with AutoHotkey
[...]

I should had wrote

I still do not understand what is possible with AutoHotkey

to be more precise

I have a ton of hotkeys that are used in a single script. Using #IfWinActive enables you to specify which hotkeys correspond to specific programs. Easy to manage; avoids software conflicts
[...]
Using one script or multiple scripts is not a way to cancel or override what other scripts do. Using one script does enable you to streamline your management and spot problems quickly, regardless of how many different programs you run.

But now I do understand - that my vision for using AutoHotkey in the long run was right, i.e. it will be possible to make my one big AHK file to work as I imagined it

And so - I have this bulk AHK:

Code: Select all

; INTRO - A:

#NoEnv

#SingleInstance Force

SendMode Input

SetWorkingDir %A_ScriptDir%

; INTRO - B:

If !A_IsAdmin && !(DllCall("GetCommandLine", "str") ~= " /restart(?!\S)") {
Try Run *RunAs "%A_AhkPath%" /restart "%A_ScriptFullPath%"
ExitApp
}

; PROGRAM #1:


#If WinExist("ahk_class MagUIClass")

<^>!l::
    GetKeyState, state, CapsLock, T
    if (state = "D")
        Send {Text}Ł
    else
         Send {Text}ł
return

; PROGRAM #2:

#If WinActive("ahk_exe C:\Program Files (x86)\K-Lite Codec Pack\MPC-HC64\mpc-hc64.exe")

~XButton2::
    Send {Ctrl Down}{Right Down}
    while GetKeyState("XButton2")
    {
        Send {Ctrl Down}{Right Down}
    }
    Send {Ctrl Up}{Right Up}
return

~XButton1::
    Send {Ctrl Down}{Left Down}
    while GetKeyState("XButton1")
    {
        Send {Left Down} ; NOTE THE LACK OF >>{Ctrl Down}<< WHICH IS PRESENT IN THE FORWARD VERSION
    }
    Send {Ctrl up}{Left Up}
return

; PROGRAM #3:


winTitle = ahk_exe Mp3tag.exe

#If WinActive(winTitle) && mouseOver(winTitle, "SysListView321")

MButton Up::
    Send ^{LButton}
    SoundBeep, 1900
    Return
#If

mouseOver(winTitle, ctl) {
    MouseGetPos,,, hWnd, overCtl
Return WinExist(winTitle " ahk_id" hWnd) && overCtl = ctl
}

; PROGRAM #4:

#If WinActive("ahk_exe C:\Program Files (x86)\Sony\Sound Forge 7.0\forge70.exe")

XButton2::
    Send {LAlt}
    Sleep, 55
    Send, pfg{Tab 12}{Down 12}{Enter}
    Sleep 99
return

XButton1::
    Send {LAlt}
    Sleep, 55
    Send, pfg{Tab 12}{Up 12}{Enter}
    Sleep 99
return

#If MouseIsOver("Sony Sound Forge")
MButton::Send q

MouseIsOver(WinTitle) {
    MouseGetPos,,, Win
return WinExist(WinTitle . " ahk_id " . Win)
}

; PROGRAM #5:

#If WinActive("ahk_exe C:\Program Files (x86)\Winamp\winamp.exe")

MButton::
    Send, {c down}
    KeyWait, MButton, T0.5
    if ErrorLevel
        Send, {c up}{v down}
    KeyWait, MButton
    Send, {c up}{v up}
return

~XButton2::
    Send {Right}
    Sleep, 666
    while GetKeyState("XButton2")
    {
        Send {Right}
        Sleep, 111
    }
return

~XButton1::
    Send {Left}
    Sleep, 666
    while GetKeyState("XButton1")
    {
        Send {Left}
        Sleep, 111
    }
return

And every script in it works more or less the way I want these programs to be affected - except for #3 which is Mp3tag. That script however works when I put in a separate AHK file and run it even at the same time as the main file

What is the problem with it then?

[mikeyww]

Unlabeled code following Return is unreachable. Easily fixed: you can hard-code your WinTitle directly in your #If directive.

[A Keymaker]

But how exactly?

I tried using

Code: Select all

#If WinActive(Mp3tag.exe) && mouseOver(Mp3tag.exe, "SysListView321")

MButton Up::
    Send ^{LButton}
    SoundBeep, 1900
    Return
#If

mouseOver(winTitle, ctl) {
    MouseGetPos,,, hWnd, overCtl
Return WinExist(Mp3tag.exe) && overCtl = ctl
}

and also a variant with

Code: Select all

Return WinExist(winTitle "Mp3tag.exe" hWnd) && overCtl = ctl

[boiler]

This line is wrong because you have not enclosed strings in quotation marks in your parameters:

Code: Select all

#If WinActive(Mp3tag.exe) && mouseOver(Mp3tag.exe, "SysListView321")

And as I believe I mentioned to you in another thread, don't change the function. You call it with different parameters. So besides the incorrect syntax in the Return line below, you shouldn't change it at all, especially since you don't understand what it's doing. Treat it as a black box and don't touch the insides.

Code: Select all

mouseOver(winTitle, ctl) {
    MouseGetPos,,, hWnd, overCtl
Return WinExist(Mp3tag.exe) && overCtl = ctl
}

Similarly, don't change the function to this either:

Code: Select all

Return WinExist(winTitle "Mp3tag.exe" hWnd) && overCtl = ctl

The function works fine as it is if you pass it the right info. You just have to call it correctly.

[mikeyww]

Good points. One possible example is below.

Code: Select all

#If WinActive("ahk_exe Mp3tag.exe") && mouseOver("ahk_exe Mp3tag.exe", "SysListView321")

Explained: WinTitle

[A Keymaker]

Good points

Yes. Now it seems to be quite obvious. Maybe I shouldn't had been trying to understand this in a middle of the night

One possible example is below.
[...]

To sum up - this works:

Code: Select all

#If WinActive("ahk_exe Mp3tag.exe") && mouseOver("ahk_exe Mp3tag.exe", "SysListView321")

MButton Up::
    Send ^{LButton}
    SoundBeep, 1900
    Return
#If

mouseOver(winTitle, ctl) {
    MouseGetPos,,, hWnd, overCtl
Return WinExist(Mp3tag.exe) && overCtl = ctl
}

but with three glitches. And they are:

A]
Rarely when I middle click a file in Mp3tag it gets played in Winamp - as if I have quickly double clicked it with left button

B]
Quite often this code turns itself into a mode in which I hear something like a vastly truncated Beep sound followed immediately by a second beep - as if I was extremely quickly pressing two times Middle Mouse Button. This however might have something to do with the feature of Filter of Mp3tag which I usually use in conjunction with selecting files because that feature got recently vastly upgraded during the upgrade of Mp3tag to its 64-bit version - and that Filter was full of bugs and still has some glitches. That Filter feature allows for writing down filtering expressions which can narrow down files seen by a user - and this AHK glitch seems to go away when I change the Mp3tag's filtering expression thus change the seen files [during which process some things must get reloaded in Mp3tag, right?]

[And yes, I know: I can simply delete the line concerning the Beep - but it is precisely its valuable presence that alarms me if sometimes something goes wrong with this script]

C]
Very rarely when my view is zoomed in with the usage of Microsoft Screen Magnifier [which is also a part of the AHK file hosting this Mp3tag script], when I middle click a file in Mp3tag the focus gets moved to the center of the [overall] screen - even if the file clicked was a top or bottom most one. So it is strange as all those sub-scripts of mine in that bulk AHK file do not [?] have instruction concerning movement of focus and are always limited to specified windows / programs, right?


[Mod edit: Changed file type of code box from .css to default .ahk so that syntax highlighting and links are working. Please use the correct style code box.]

[User explanation: Sorry, my mistake. I am constantly going back and forth between AHK and CSS; and also between various forums. And so I got them mixed up]