Request @FuncName

[Jayowee]

A simple request for a @Funcname. It might be usefull for debugging (e.g. showing the current Function name in a MsgBox), or for use in functions like GUICtrlSetOnEvent or HotKeySet.

Example of personal use:

HotKeySet(@HotKeyPressed)
Send(@HotKeyPressed, 0)
HotKeySet(@HotKeyPressed, $_functionName)

For allowing a hotkey to be captured by an outside/external program.
Otherwise, AutoIT always "steals" your hotkeys.

[Valik]

No, the macro causes way too much performance degradation. Also, terrible example. You're requesting the feature to write bad code. Not exactly the best way to get it considered.

[Jayowee]

Youre right, the example wasn't clear.
It's a part of a function I have created called "HotKeyAllowed", wich basically checks if my primary window is active, which would mean that the sent hotkey was intended for my program and not for NotePad or something...

But apart from my "personal scripting issues", the debugging usage was still an idea, right?
And I'll admit that performance issues are more your area of judgment.

[Valik]

Replying to Jayowee:

And I'll admit that performance issues are more your area of judgment.

It's not judgment, it's fact. It's been in the language before and performance suffered as a result. I can think of ways to improve performance but I can't justify any performance hit at all for something that is fundamentally useless. You know at compile time what function a particular piece of code is in. If you can type "ConsoleWrite(@FuncName & @CRLF)" you can just as easily type "ConsoleWrite("MyFunction" & @CRLF)". In theory it would work right and without typing if it's used as the default argument to an optional parameter for a function:

; This would print: TestIt: Foo
TestIt()

Func DebugPrint($sMsg, $sFuncName = @FuncName)
    ConsoleWrite($sFuncName & ": " & $sMsg & @CRLF)
EndFunc

Func TestIt()
    DebugPrint("Foo")
EndFunc

However, I still assert that since you know at compile time which function will be called you can still type this with only slightly more effort:

; This prints: TestIt: Foo
TestIt()

Func DebugPrint($sMsg, $sFuncName)
    ConsoleWrite($sFuncName & ": " & $sMsg & @CRLF)
EndFunc

Func TestIt()
    DebugPrint("Foo", "TestIt")
EndFunc

[jchd]

I'm also contemplating a @Function feature but with a different rationale.

First, I see this as a debugging aid and deep error catching feature best used for complex scripts (applications). The "macro" wouldn't be updated until needed to avoid performance impact. When invoked, it is irrelevant if it needs an awful long time to process, just because it's an exceptional branch.

Then, I'd see it a returning an array populated with function names call stack (without arguments of course). I agree with Valik in that with only one call level, there is little point in adding anything and that his example is all what's needed.

Sketched situation where I see this put at good use is an example I'm working on. Because the SQLite UDF is too low-level to handle error conditions itself and because it would be very clumsy to have the application level check after every SQLite call for every possible error combination, then some form of "middleware" is needed. There it really needs to know who was calling to display informative message so that the user can take action accordingly if something turns out bad.

The same feature would also solve the question that sometimes arises in non-trivial applications: "How on Earth did I manage to get _that_ function called"?

With a @Function[] possibility (or an equivalent: the stack info may as well be returned by an AutoIt function), we can handle both situations more gracefully than the current (slow and cumbersome):

Global $_Stack[1] = ['main']
...
Func DoSomething(...)
  _ArrayAdd($_Stack, 'DoSomething')
  ; do lower-level stuff, with trace of who requested it...
  _ArrayPop($_Stack)
EndFunc

[Valik]

jchd, there's already a way built into SciTE for realtime function tracing (not quite the same as a call stack but meh). I don't know what the hotkey is but look for an option called "Insert Trace Lines" or something. It... inserts a trace line at the start of every function in the current file. These lines can be easily removed with the accompanying "Remove Trace Lines" menu entry. I'm not sure what their exact names are in SciTE4AutoIt but I'm 99% sure they are there as I wrote them and gave them to Jos.

As for your idea, its flawed. We don't preserve state information about the current - or previous - function calls. That's the whole "performance impact" bit I mention. In order to store any of that information we have to incur a performance penalty. Sure, we could do something simple like generate UID's for the UDFs and only store the UID and then perform an on-demand lookup to retrieve the string name. That still imposes a minor performance penalty for every single function call regardless if it uses @FuncName or not. That's just poor design; the most common code path should be the fastest branch if at all possible.