Page 1 of 1

Some keys cannot be used as keyboard shortcut → Workaround

Posted: 11 Mar 2015 17:47
by binocular222
Normally, you cannot assign a single "Tab" or "Enter" or "Left/Right Arrow" as keyboard shortcut.
Autohotkey can eliminate that problem. For example: with the below script, pressing "Tab" will load "Pane.xys" if (1) XYplorer window is active AND (2) focus is on List

Code: Select all

#SingleInstance force
#NoEnv
;#notrayicon   ;uncomment this line if you don't want to see tray icon

Settitlematchmode, 2

SenderHWND := A_ScriptHwnd + 0  ;Return this script's hidden hwdn id.  +0 to convert from Hex to Dec
MessagetoXYplorer := "::CopyData " SenderHWND ", get(""FocusedControl""), 2"    ;resolved to sth like this:   ::CopyData 7409230, get("FocusedControl"),2

#Ifwinactive XYplorer ahk_class ThunderRT6FormDC
Tab::

Global Datareceived
OnMessage(0x4a, "Function_Receive_WM_COPYDATA")  ; 0x4a is WM_COPYDATA. This onhold and wait for the WM_Copydata from XYplorer then execute Function_Receive_WM_COPYDATA(wParam, lParam) below
FunctionMessagetoXYplorer(MessagetoXYplorer)
if(Datareceived = "L")     ;get("FocusedControl")  return "L" when focus is on List
	FunctionMessagetoXYplorer("::load Pane")
Return

FunctionMessagetoXYplorer(MessagetoXYplorer)          ;Send message to XYplorer
{
	SetTitleMatchMode, 2
	HWND := WinExist("XYplorer ahk_class ThunderRT6FormDC")
	Size := StrLen(MessagetoXYplorer)
		If !(A_IsUnicode)
		{
			VarSetCapacity(Data, Size * 2, 0)
			StrPut(MessagetoXYplorer, &Data, Size, "UTF-16")
		}
		Else
			Data := MessagetoXYplorer

	VarSetCapacity(COPYDATA, A_PtrSize * 3, 0)
	NumPut(4194305, COPYDATA, 0, "Ptr")
	NumPut(Size * 2, COPYDATA, A_PtrSize, "UInt")
	NumPut(&Data, COPYDATA, A_PtrSize * 2, "Ptr")
	SendMessage, 0x4a, 0, &COPYDATA, , ahk_id %HWND%
}

Function_Receive_WM_COPYDATA(wParam, lParam)
{
	StringAddress := NumGet(lParam + 2*A_PtrSize) ;lParam+8 is the address of CopyDataStruct's lpData member.
	CopyOfData := StrGet(StringAddress)    ;May also specify CP0 (default) or UTF-8 or UTF-16:   StrGet(StringAddress, NumGet(lParam+A_PtrSize), "UTF-16")
	cbData := NumGet(lParam+A_PtrSize)/2  ;cbData = String length
	StringLeft, Datareceived, CopyOfData, cbData
}
Usage: Save as .ahk, open with Autohotkey.exe which should be donwloaded from here: http://ahkscript.org/download/

P.S: Another way would be: Use AHK to remap "Tab" to "Ctrl+Shift+Alt+X" then use XY to assign "Ctrl+Shift+Alt+X" to do something:

Code: Select all

;#notrayicon   ;Uncomment his line if you don't want tray icon
Settitlematchmode, 2
#Ifwinactive XYplorer ahk_class ThunderRT6FormDC
Tab::Sendinput ^+!x

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 11 Mar 2015 18:13
by klownboy
Very nice binocular222. Honestly, I don't think I've ever used "tab" for example to cycle between the panes and AB. So this could free up some keys for use as needed.
Thanks,
Ken

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 11 Mar 2015 18:34
by binocular222
My usage is:
Left = go up 1 folder level
Right = open <curitem>
Ctrl Left/Right = Next/prev Tab (similar to Firefox)
Tab = toggle dual pane and focus on newly activated pane (I have List only, no Tree/Catalog/AB so using Tab that way is not misleading)

That eliminate the need for Tree altogether (I disabled tree)

Notice that for Left/Right, the trigger should be:
~Left::
~Right::
(Notice the tilde sign)

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 12 Mar 2015 13:43
by klownboy
Thanks for the further info binocular222. Which of the two methods on your original post do you tend to use most often? I don't suppose either one, when you are already using AHK, is going to be much more taxing on the system than the other. Though the second method is obviously simpler.

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 12 Mar 2015 14:47
by Stef123
Any chance to (ab)use this for mouse shortcuts?
To be consistent with other program I'd like to streamline my XY mouse-clicks with what I am used to, namely trigger certain commands when Alt or Ctrl clicking the mouse - at certain spots, that's the catch. Ctrl clicking an empty spot in list view should not override Ctrl-clicking over list items - which affects selections obviously, and that should remain in effect as it is. Ctrl-clicking the right mouse in list view should not override the same kind of click on CTBs, or I wouldn't be able to edit them anymore, etc. etc.

It would open up a new level of very efficient handling that has not (yet) been exploited by XY, left and right mouse-clicks with modifier keys held down. Is this possible with AHK? How would I target the empty areas in list view? How do I tell AHK what kind of object the mouse hovers over?

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 12 Mar 2015 16:40
by binocular222
@klownboy: I use both
@stef123: see http://www.xyplorer.com/xyfc/viewtopic. ... 24#p113307 You can check if Itemundermouse = blank

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 12 Mar 2015 16:50
by Stef123
Thanks for the link. Gives me a queasy gut feeling, with xy-coordinates and font scaling etc. - I work portable on different screen resolutions, getting this to work threatens to be very time-consuming. May rather give it a shot over in the wishes section and hope for a built-in feature.

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 12 Mar 2015 17:16
by binocular222
I amended the link, actually it's the 4th post from top. Not depend on font scaling at all

Re: Some keys cannot be used as keyboard shortcut → Workarou

Posted: 13 Mar 2015 07:49
by Stef123
Thanks, bino
Yes, I had read the whole thread, and also your messenger contribution, takes time to digest it all. My uneasy feeling concerns the x-y-positions/ coordinates. Maybe I don't fully grasp it, but some postings seem to indicate potential problems when switching layouts, recognizing tree view.

Instead of positional coordinates, I had hoped for targeting to work like

Code: Select all

IfWinActive, XY-breadcrumb-triangle
IfWinActive, XY-catalog-empty-spot
IfWinActive, XY-tree-entry
IfWinActive, XY-tab-header
All these elements share/ overlap the very same xy-coordinates position when I switch my layouts. Not to mention my various environments, multi-monitor, different Win-scaling factors. With my limited knowledge it reads like this might take considerable time to work it out. And yet it is too alluring to not try it out, hands-on, one of these days.