vk_browser_back / forward support

Features wanted...
Post Reply
GeoffW
Posts: 6
Joined: 02 Aug 2019 09:50

vk_browser_back / forward support

Post by GeoffW » 02 Aug 2019 10:04

I've been re-evaluating XYplorer again (I've evaluated it a few times over the last ... 15 years. Oh my, doesn't time fly when you're having fun).

Anyway, I'm liking it much more this time (64bit integration is not perfect but good enough I think), but there's one minor hiccup:

The back and forward button on my mouse and keyboard do not work with XYplorer. They work with Windows 10 File Explorer, with Firefox, Chrome and pretty much everything else (including the competitor to XYplorer that I currently use). As I understand it these keys are configured to issue VK_BROWSER_BACK and VK_BROWSER_FORWARD (see here: https://docs.microsoft.com/en-us/window ... -key-codes ).

I see in this forum that others have used AutoHotKey or manufacturer configuration facilities to force their mouse to issue Alt+Left or Alt+Right, but I'd rather not do that since I cannot predict which applications I have that might do something unexpected. The VK_BROWSER_* codes are there for a reason, and XYplorer doesn't seem to do anything else with them so it might as well do what is expected ... yes?

highend
Posts: 8209
Joined: 06 Feb 2011 00:33

Re: vk_browser_back / forward support

Post by highend » 02 Aug 2019 10:12

I see in this forum that others have used AutoHotKey ... to force their mouse to issue Alt+Left or Alt+Right, but I'd rather not do that since I cannot predict which applications I have that might do something unexpected
You can limit that behavior to XYplorer (when using AHK) if you want...
One of my scripts helped you out? Please donate via Paypal or highend (at) web (dot) de

aminomancer
Posts: 22
Joined: 26 May 2019 06:29

Re: vk_browser_back / forward support

Post by aminomancer » 02 Aug 2019 13:01

Code: Select all

#NoTrayIcon
#Persistent
#SingleInstance Force

#IfWinActive, ahk_exe XYplorer.exe
XButton1::
    Send !{Left}
return
#IfWinActive, ahk_exe XYplorer.exe
XButton2::
    Send !{Right}
return
If that doesn't work try swapping XButton1 with Browser_Back, and Xbutton2 with Browser_Forward. If neither of them works, then it's possible your mouse doesn't use standard the standard HID codes. If it requires a special driver then it's possible it implements back/forward functions through some weird proprietary method, but you'd think that wouldn't work in windows explorer. If you have a logitech mouse you can use "logitech gaming software" to very easily remap those buttons too, by the way. I think their newest stuff requires a new program that's meant to replace LGS, but can't remember what it's called. A lot of other gaming mouse manufacturers have little utilities like that.

But if you just use a normal, run of the mill mouse, your best bet is autohotkey. I have a logitech mouse but I still use autohotkey over logitech's utility to remap my mouse keys for more complex functions, since it provides way more control and detailed scripting. In this case the thing you're trying to do is really simple so lots of other utilities would work besides autohotkey. But autohotkey is probably the only one that's gonna let you make the remap exclusive to a process or window class.

Since you only want it to take effect in xyplorer, autohotkey is the way to go. That's exactly what it's intended for. My main script has dozens of rules just like that, with application or window-specific hotkeys and scripts. It's like 600 lines long and there's been zero performance hit as far as I can tell.

Plus, autohotkey is a very "clean," portable, lightweight method of remapping inputs. It doesn't really change anything, and it has no effect unless you're running the script. Just put the script in your startup folder and pretty soon you'll forget it even exists.

EDIT: btw when you download autohotkey make sure you click "download current version," not v2 alpha. I'm pretty sure #IfWinActive is deprecated in v2 so if you do install v2 you'll have to look it up and find out what the new syntax for that logic is.

aminomancer
Posts: 22
Joined: 26 May 2019 06:29

Re: vk_browser_back / forward support

Post by aminomancer » 02 Aug 2019 13:27

You can do a lot of cool stuff with #IfWin in general. For xyplorer I use this:

Code: Select all

#IfWinActive
#IfWinNotExist, ahk_exe XYplorer.exe
#e::
Run "C:\Program Files (x86)\XYplorer\XYplorer.exe"
return

#IfWinExist
#IfWinActive, ahk_exe XYplorer.exe
#e::
send ^t
return
    
#IfWinExist, ahk_exe XYplorer.exe
#IfWinNotActive, ahk_exe XYplorer.exe
#e::
WinActivate, ahk_exe XYplorer.exe
return
So if xyplorer is not running at all, windows key + E will start it up normally. If it's running and focused, win+E will create a new tab. If it's running but not focused, it will simply focus it. Simple but kinda cool and not something you could do with normal remapping software.

I also use it to get around some of the restrictions in xyplorer. I used to use an imac so I got kinda used to the "quick look" feature where you press spacebar to preview a file. But xyplorer won't let you map shortcuts including space at all. It's pretty complicated to get autohotkey to recognize whether you have an input box focused or not, so remapping just "Space" would cause problems when I'm trying to type a path or change a filename. So I just set it to shift+space for now, and in xyplorer's keyboard shortcut settings I have file preview mapped to ` (tilde). That's just because I also have a habit of actually pressing the tilde key to open it as well. It would be better to replace the `` with something with modifiers or some obscure key, like ctrl+F24. That's an input you can't even send with a normal keyboard, so you won't get any surprise activations.

Code: Select all

#IfWinActive, ahk_exe XYplorer.exe
+Space::
    Send {``}
return
Anyway, it's definitely possible to create a hotkey that is disabled while you have an input box focused. I have a script like that for firefox which works well, just haven't worked it out for xyplorer yet.

This one's a little hard to describe but give it a try sometime if you install AHK. This script basically lets you fully control the alt+tab menu with just a mouse.

Code: Select all

MButton::Send {Alt down}{Tab}
#IfWinActive Task Switching ahk_class MultitaskingViewFrame
*WheelDown::
    Send {Blind}{Tab}
return
#IfWinActive Task Switching ahk_class MultitaskingViewFrame
*WheelUp::
    Send {Blind}+{Tab}
return
#IfWinActive Task Switching ahk_class MultitaskingViewFrame
    LButton::Send {LButton}{Alt up}
return
The way I prefer to use it is a little complicated because I use a logitech mouse, but the short version is if you have extra mouse buttons you can just remap one of them to MButton and then you still have the native "scrollwheel click" function, like "open links in new tab."

GeoffW
Posts: 6
Joined: 02 Aug 2019 09:50

Re: vk_browser_back / forward support

Post by GeoffW » 02 Aug 2019 17:07

aminomancer and highend, thank you very much for your suggestions ... curiously, since sending my opening post I have been reading about some of these extra features of AutoHotKey (in the past I'd only ever used the basics). I really appreciate your examples aminomancer.

That said, I hope the developers pay attention to the opening post anyway. As far as I can tell, VK_BROWSER_BACK and VK_BROWSER_FORWARD are not being processed by xyplorer at all, so there seems no reason why they should not be implemented and become compatible with File Explorer and many other apps.

nas8e9
Posts: 2029
Joined: 21 Jun 2008 14:50

Re: vk_browser_back / forward support

Post by nas8e9 » 02 Aug 2019 18:05

GeoffW wrote:
02 Aug 2019 17:07
That said, I hope the developers pay attention to the opening post anyway. As far as I can tell, VK_BROWSER_BACK and VK_BROWSER_FORWARD are not being processed by xyplorer at all, so there seems no reason why they should not be implemented and become compatible with File Explorer and many other apps.
Can I ask what mouse you use and with which driver? With a Logitech mouse and associated driver, the back and forward buttons on my mouse work as expected?

GeoffW
Posts: 6
Joined: 02 Aug 2019 09:50

Re: vk_browser_back / forward support

Post by GeoffW » 03 Aug 2019 03:27

nas8e9 wrote:
02 Aug 2019 18:05
Can I ask what mouse you use and with which driver? With a Logitech mouse and associated driver, the back and forward buttons on my mouse work as expected?
I first got used to the back and forward thing working with a Logitech mouse, but that was several years ago now. I've been through quite a number of mice and keyboards since then, and one of the reasons why I phrased the request using key codes is that the problem is faced by both mouse and keyboard situations - and keyboards with browser back/forward keys (in my experience) typically issue the above codes.

But to answer your question, I am currently using a Microsoft "Sculpt" mouse set using AutoHotKey to issue those codes from wheel tilt. (WheelLeft and WheelRight events turned into vk_browser_back and vk_browser_forward.) That was arranged some years ago now, with all browsers and most other programs responding appropriately to the codes (although Vivaldi was responding twice - now solved thanks to the help I have received here).

aminomancer
Posts: 22
Joined: 26 May 2019 06:29

Re: vk_browser_back / forward support

Post by aminomancer » 15 Aug 2019 16:55

Since I posted all that, I actually ended up implementing a script that is sensitive to where the focus is. Turns out xyplorer actually integrates really easily with AHK as far as programs go. It has a ton of 'controls' that AHK is aware of so you can get really specific. Whereas with something like chrome or firefox, AHK is completely unaware of any specific buttons or textboxes in the window, requiring you to use a special library for AHK to be aware of the application's contexts. So because all the controls are exposed to AHK you can use window spy (installed with autohotkey) to get the control names of all the individual interactible components of xyplorer. So far I've just used it for the "quick look" feature but you could do a lot with this. The purpose is really just to define hotkeys that only work when a certain control is (or isn't) focused. In this case, hotkeys that only work when an input box is *not* focused. This could also allow you to set a whole suite of hotkeys without modifier keys. Like you could map the R key to refresh list, and still be able to type "R" into the input boxes, since input boxes have separate controls and AHK can tell which control is selected. So because of that I was able to just map the hotkey to space instead of shift space.

Code: Select all

; xyplorer quick preview
#IfWinActive, ahk_exe XYplorer.exe
$Space::
ControlGetFocus, var, A
StringCaseSense On
if var contains Edit,TextBox
    Send {Space}
if var not contains Edit,_WwG1,EXCEL71,PDFPreview1,SysListView321,MacromediaFlashPlayerActiveX1,TextBox
    Send +^{``}
if var=Edit1
    Send +^{``}
if var contains _WwG1,EXCEL71,PDFPreview1,SysListView321,MacromediaFlashPlayerActiveX1
{
    ControlFocus, ThunderRT6PictureBox2, A
    Send +^{``}
}
return
"ControlGetFocus, var, A" listens for the focused control and defines a variable as the string returned by that listener. Then the rest is just the hotkeys and some workarounds for specific preview handlers, since they don't all work the same way. But basically if you've clicked a textbox or you've started renaming a file in the list or tree, the focused control now becomes something with Edit or TextBox in the name. So we just send the input key as the output key for those controls. Then, the 2nd hotkey is for everything that's not a textbox, so it sends shift+ctrl+` which is mapped in xyplorer to quick preview. It has some exceptions for certain preview handlers, since the hotkey needs to be 1) used on the list to call up the preview window, but also 2) used on the preview window to close the preview window. Some preview handlers hijack the keyboard from xyplorer, so xyplorer's shift+ctrl+` shortcut stops working. So those are handled by the last line, which basically says: if one of those controls is focused, when pressing space, focus the outer window frame (ThunderRT6PictureBox2) and THEN send shift+ctrl+`. You could do this another way, by just not sending a hotkey when those controls are focused and instead sending a command to close the window with control ThunderRT6PictureBox2. I didn't think of that till just now, maybe that's better. But there are only a few preview handlers in existence so it doesn't really matter. The third line, var=Edit1, is so that you can still close text preview windows even if the text is focused.

Most of the complexity there is just for getting around the preview handlers. For any other hotkey it's a lot simpler. If you just wanted to make a one-key shortcut (with no modifier) that still lets you type normally into textboxes, you only need 2 lines. One for var contains edit,textbox and one for var not contains edit,textbox. The real magic is just in the first function, controlgetfocus. You can do a lot with that function in certain programs, like xyplorer, by just messing around with the program with window spy open. Now that I've noticed how many exposed controls there are in xyplorer I'm probably gonna make a whole bunch of one-key shortcuts and similar stuff.

GeoffW
Posts: 6
Joined: 02 Aug 2019 09:50

Re: vk_browser_back / forward support

Post by GeoffW » 15 Aug 2019 17:47

aminomancer, certainly interesting, and demonstrates the power of AHK. A warning though: it is easy to accidentally get yourself into confusing situations where you start of have effects you didn't plan - or, planned originally but in six months time have forgotten about. Not long ago I had some network troubles that I had a really hard time diagnosing - it turned out to be me getting too damn clever with some firewall rules 5 years previously, and I'd forgotten all about them :oops:.

Post Reply