`IfWinActive`/`IfWinNotActive` don't seem to work?

[knobhead]

Hi,

I just came across AHK_X11 – thanks for your fantastic project, I love it as I'm an avid AHKv1/v2 user on my Windows machine at work. :+1:

However, I encounter a problem with with the IfWin[Not]Active not working. My hotkey always works in all windows, not in the one I'd like to limit it to.

• [x] I followed the example given in the FAQ section „How can a hotkey be made exclusive to certain program(s)?”

Here's my code:

_Click to unfold_

``` WheelUp:: IfWinNotActive, ahk_class libreoffice-writer { WinGetPos, lo_X, lo_Y, lo_W, lo_H, A WinGetTitle, Title, A WinGetClass, cls, A TrayTip, metatools, Title="%Title%" [class=%cls%] is at x=%lo_X% y=%lo_Y% Send {WheelUp} return } Send {F6}+^{Tab}+{F6} return ``` :negative_squared_cross_mark: I also tried the other way round, having the `IfWinActive` condition before the hotkey assignment. :negative_squared_cross_mark: I also tried using the window title instead `ahk_class`

Here's my environment:

• [x] Arch Linux, current updates
• [x] AHK_X11 v1.0.2 binary from here
• [x] xfce4, Accessibility enabled
• [x] ACCESSIBILITY_ENABLED=1 in /etc/environment
• [x] ./ahk_x11 --windowspy correctly recognizes title and class of the window in question:

(it shows this even before I activated the accessibility features)

Here's the output of AHK_X11:

_Click to unfold_

``` (process:7725): Gtk-WARNING **: 23:04:39.512: Locale not supported by C library. Using the fallback 'C' locale. Gtk-Message: 23:04:39.565: Failed to load module "xapp-gtk3-module" Gtk-Message: 23:04:39.565: Failed to load module "xapp-gtk3-module" Interactive AHK_X11 console (REPL). Type any command. Multi-line text not supported. Press {CTRL}+C to exit. ahk_x11> ** (AppRun.wrapped:7725): WARNING **: 23:05:04.773: atk-bridge: get_device_events_reply: unknown signature ^C ``` (xapp is installed)

I'd be grateful for any hints and ideas. Let me know if you need more information for debugging or if I can be of any assistance.

regards

[knobhead]

Hm.

I ended up achieving what I aimed for, but had to use a workaround.

This script is used to be able to switch between LibreOffice's Notebookbar Tabs by mouse wheel scrolling while hovering the notebookbar. When the mouse cursor is over the document area, mouse wheel scrolling should scroll the document.

#MaxThreadsPerHotkey 10
SetKeyDelay 0
CoordMode, Mouse, Relative

$WheelDown::
    MouseGetPos, m_X, m_Y
    WinGetClass, klasse, A
    IfInString, klasse, libreoffice
    {
        ; TrayTip, Info, class = %klasse%
        If m_Y < 120 
            {
                Send {F6}^{Tab}+{F6}
                return
            }
    }
    Send {WheelDown}
return

$WheelUp::
    MouseGetPos, m_X, m_Y
    WinGetClass, klasse, A
    IfInString, klasse, libreoffice
    {
        ; TrayTip, Info, class = %klasse%
        If m_Y < 120 
            {
                Send {F6}+^{Tab}+{F6}
                return
            }
    }
    Send {WheelUp}
return

IfWinActive was not able to match Title/Class of the Last Found Window, likely because of that being empty, because I could not access it with an A like I did in WinGetClass.

I'll leave this here for the moment.

[phil294]

Hi @knobhead, thanks for the kind words and the detailed report! Indeed the command(s) seems to be broken, but only if you use ahk_class, and only if the window's "class name" differs from its "class".

I think I have fixed this now, so please stand by for the next upcoming release, then this should all work.

Some more notes just to clear things up (you might know these already):

• Perhaps using the ~ prefix for your hotkey might be better? Then you won't have to do the Send {WheelUp} anymore. Depends if you want to prevent the functionality in the ribbon area. But generally, hotkeys that send themselves are often problematic (e.g. #26). Seems to work in your case though

• having the IfWinActive condition before the hotkey assignment

  that wouldn't work as you'd need the #IfWinActive directive for this with the # prefix, but that's not yet supported by ahk_x11

• the accessibility settings stuff is only necessary for window contents / controls / text reading - for general window properties like position or title it will always work

[knobhead]

Hi @phil294, thanks for the fixes, tipps and your work, I'm looking forward to the upcoming and future releases. :+1: I'm trying to migrate some of my AHK_L scripts to AHK_X11 and re-organize my scripts platform-specific, sharing a common script of simple hotstrings and hotkeys that would work on both platforms (AHK_X11 and AHKv2).

One question on the side: I know you don't aim for feature parity, that's totally fine. But I was wondering if I you'd like me to post whatever issues I encounter on my migration experiments, as combined issue or individual issues, or if that would be unneccessary pressure and just clog the issue tracker?

[phil294]

@knobhead it doesn't matter if you make one combined issue or several small ones. It'll add no pressure, don't worry, please do create as many as you can! Bug reports and all sorts of feedback is very valuable. Feature requests too, but rarely seen since we're implementing a fixed spec here.