Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#1243 closed Feature Request (Rejected)

Request @FuncName

Reported by: Jayowee Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: @funcname func Cc:


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:

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

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

Attachments (0)

Change History (5)

comment:1 Changed 14 years ago by Valik

  • Resolution set to Rejected
  • Status changed from new to closed
  • Version deleted

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.

comment:2 follow-up: Changed 14 years ago by 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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 14 years ago by 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

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

Func TestIt()

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

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

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

comment:4 in reply to: ↑ 3 Changed 14 years ago by 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...

comment:5 Changed 14 years ago by 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.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.