14 replies to this topic

[entropic]

This has been discussed on the forum before but I think it's worth bringing up again.

You can make a hotkey that calls a function, like this:

!a::MyFunction()

but you can't do this

Hotkey, !a, MyFunction()

instead you have to do something like this

Hotkey, !a, MyLabel

MyLabel:
    MyFunction()
Return

Also, any ideas on how difficult it would be to code?

[engunneer]

+1

Also, it'd be nice if Gui gLables caoud call functions (or make a new fFunction() option)

[VxE]

You can script a 'lookup table' which holds hotkey names along with their associated function. Then, assign all hotkeys to one label, which gets the function name from the lookup table (using A_ThisHotkey) and calls the function dynamically.

A similar setup could work for gui g-labels, though any workaround would be much less elegant than simply specifying a function in the gui control's options (or instead of the hotkey label).

[engunneer]

A good example of that is the MenuHandler example in the Menu docs.

I just AHK could be a little more function centric sometimes.

[entropic]

You can script a 'lookup table' which holds hotkey names along with their associated function. Then, assign all hotkeys to one label, which gets the function name from the lookup table (using A_ThisHotkey) and calls the function dynamically.

A similar setup could work for gui g-labels, though any workaround would be much less elegant than simply specifying a function in the gui control's options (or instead of the hotkey label).

Lol, I use a similar workaround.

I have 10 hotkeys that are registered at runtime with the Hotkey command, they all send different key combinations to a window, and I have a function to send whatever keys I want to the window.

MyHotkey(1-10) is the Hotkeys
KeysToSend(1-10) is the corresponding keys to send

SendSomeKeys:
    Loop, 10	; Loop through the ten possible hotkeys
    {
        TempHotkey := vMyHotkey%A_Index%           ;vMyHotkey(1-10) stores the Hotkey combinations        
        If (TempHotkey = A_ThisHotkey)
        {
            TempKeysToSend := vKeysToSend%A_Index%  ;vKeysToSend(1-10) stores what keys will be sent
            TempKeysToSend = "%TempKeysToSend%"     ;In order for it to work correctly it must be enclosed in quotes
            SendToMyWindow(TempKeysToSend)
            Break                                   ;Break exits the Loop
        }

    }
return

[shajul]

This has been discussed on the forum before but I think it's worth bringing up again.

You can make a hotkey that calls a function, like this:

!a::MyFunction()

but you can't do this

Hotkey, !a, MyFunction()

instead you have to do something like this

Hotkey, !a, MyLabel

MyLabel:
    MyFunction()
Return

Also, any ideas on how difficult it would be to code?

Bump. I am not sure if i have missed any recent discussion on this.

[sumon]

Bump. I am not sure if i have missed any recent discussion on this.

Although the workaround works (obviously), it is not as elegant. I think an improvement on this part would help both novices and pros alike.

[Solar]

Label names can contain brackets. Thus, there's no way to distinguish between label names and function names:

Hotkey, !a, MyFunction()
return

MyFunction():
   MsgBox Oops, I'm a label. Better luck next time.
return

This could happen for v2 but it wouldn't be possible for v1 without breaking backward compatibility.

[tidbit]

Backward compatibility has been broken for many things already.

and well, there could be function detection. if string (label) contains a ( and ), do function stuff instead.
same with menus.

as for GUI's, fFunction() would be nice.

[Solar]

Backward compatibility has been broken for many things already.

Not many things. Just [ ] and ? characters in variable names and syntax validation. Which are both justified and very minor changes. I'm speaking purely from an ANSI perspective as Unicode comes with it's own costs.

and well, there could be function detection. if string (label) contains a ( and ), do function stuff instead.
same with menus.

Well, it would break compatibility for anyone using ( or ) in their label names. In this case, I don't believe it's justified to break compatibility. Unless somehow adding the ability to pass parameters along with the function call, it would have no benefit over the workarounds mentioned above. I don't think a few extra lines are going to kill you.

[fragman]

I don't think those characters should have been allowed in label names at the first place because they have other meanings.

[rbrtryn]

You can script a 'lookup table' which holds hotkey names along with their associated function. Then, assign all hotkeys to one label, which gets the function name from the lookup table (using A_ThisHotkey) and calls the function dynamically.

In AHK_L it would be more efficient to store a function reference using Func().

A similar setup could work for gui g-labels, though any workaround would be much less elegant than simply specifying a function in the gui control's options (or instead of the hotkey label).

How is elegance defined as it relates to coding? There are some programmers in these forums who use a single character or an arcane symbol for variable names and call it elegant. :x Sorry, had to get that off my chest. It just drives me nuts. :lol:

Unless somehow adding the ability to pass parameters along with the function call, it would have no benefit over the workarounds mentioned above.

The advantage of a function lookup table is that passing parameters is easy and efficient.

A short AHK_L example:

#NoEnv
#SingleInstance force
SetBatchLines -1
ListLines Off
SendMode Input
SetWorkingDir %A_ScriptDir%

; Autoexecute
	gosub MakeGui
	Table := []
	Table["Color", 1] := Func("ListColors")          ; Column 1 contains function references
	Table["Color", 2] := ["red", "green", "blue"]    ; Column 2 contains function parameters
	Gui Show
return

MakeGui:
	Gui add, Button
	       , w75 gLookUp    ; All commands gosub the LookUp subroutine
		   , Color
return

LookUp:
	; Use an indirect, varadic function call
	ReturnValue := Table[A_GuiControl, 1].(Table[A_GuiControl, 2]*)
return

GuiClose:
	ExitApp
return

ListColors(Params*) {    
	for k, v in Params
		MsgBox % v
}

[fragman]

It would be best if delegates to object instances where also supported. See the Delegate class from IsNull (?) for reference. Function references point in that direction, but they fail to work on object instances afaik.

[VxE]

You can script a 'lookup table' which holds hotkey names along with their associated function. Then, assign all hotkeys to one label, which gets the function name from the lookup table (using A_ThisHotkey) and calls the function dynamically.

In AHK_L it would be more efficient to store a function reference using Func().

My past self (from back when AHK-L did not support objects) is suitably chastised... :oops:

A similar setup could work for gui g-labels, though any workaround would be much less elegant than simply specifying a function in the gui control's options (or instead of the hotkey label).

How is elegance defined as it relates to coding? There are some programmers in these forums who use a single character or an arcane symbol for variable names and call it elegant. :x Sorry, had to get that off my chest. It just drives me nuts. :lol:

IMHO, code elegance is a combination of readability and a form fitting the expressed goal. For instance, code intended to be fast might unroll loops (increasing overall code size) while code intended to be small might use tiny identifiers and both could be considered 'elegant'. If you'd like to see an example of inelegance, search the forums for my g-function workaround.