37 replies to this topic

[corrupt]

I was hoping that AHK could support pre-processing. Nothing too fancy and likely not very time consuming to implement. Please vote in the poll and feel free to comment.

Would it be practical to add a directive to send code to be processed to a pre-processor before AHK processes the code? Something like the following maybe:

#PP, custom.dll
; other code
; rest of script...
; blah, blah, blah

AutoHotkey could then check for a #PP directive first then call the specified Dll to pre-process the code. The params sent to the dll could then possibly be:

1) the param(s) that were passed to AutoHotkey.exe
2) the contents of the script (alternately, if easier to implement, the .Dll could read the contents of the .ahk file instead)

The .Dll could then pre-process the code and send the modified code back to AutoHotkey to be processed and executed normally.


This functionality is, of course, partially possible already by changing the default .ahk extension to point to a different .exe instead or by using a different extension then passing the modified code to AutoHotkey.exe. This method has a few drawbacks though unfortunately. Mainly issues with paths: reload, default window titles, built-in path related variables, etc... since a temporary script needs to be used instead of modifying the original. This is why I was thinking that a Pre-processor directive might work well instead. This would also be beneficial in cases where the file system is read-only and a temporary file cannot be created.

@Chris - I realize that you have mentioned a couple times now that you are not fond of the idea but I disagree with the reasons that you gave and am following the suggestion that you made about creating a poll.

[Laszlo]

…just thinking. If you had several preprocessors, the source code would have different flavors. I am not sure if it would lead to fragmentation of the AHK community, as some people would not understand the scripts of the others.

If there is just one preprocessor, then you don't need to specify its name.

Why should it be a dll? An exe looks more natural, but even another AHK script would do. With regular expressions very powerful text processing can be done.

What exactly do you expect from a pre-processor? A macro facility proved to be enough for many years in C programming. Maybe conditionals? All of this can be done with regex.

[Chris]

Thanks for making the topic; it's a good opportunity to hear what others have to say.

I think most would agree that plugins are a "best of breed" feature in terms of their potential seamlessness and professionalism. I contend that plugins are a superset of pre-processing; in other words, #PP might overlap too heavily with plugins. If true, some of the development time spent on #PP would have been wasted because it could have been spent on plugins. But of far more concern to me are the resulting redundancies in the code and the documentation, which increases the learning curve for AutoHotkey.

Over the last three years, expectations have risen for the quality of new features added to AutoHotkey. Therefore, I think new features should be as professional as possible, not "quick and dirty". Since I'm not a language design expert, I look to other languages for professional features and syntax -- yet I'm unaware of any other popular languages that have preprocessing support such as #PP.

Like Laszlo, I think #PP might eventually split AutoHotkey into two or more languages (I realize you have no intention of this; but it might produce that effect over time). This might complicate the documentation by requiring a new section to describe the syntax specific to each #PP DLL.

Even if it were decided that #PP should be added, I feel that features like stdlib are a higher priority. Also, I think stdlib should be a built-in feature (i.e. not dependent on #PP). In part this is because external DLLs would reduce the portable, stand-alone nature of AutoHotkey.exe.

[corrupt]

…just thinking. If you had several preprocessors, the source code would have different flavors. I am not sure if it would lead to fragmentation of the AHK community, as some people would not understand the scripts of the others.

Maybe, but that's nothing new. There are many, many scripts on the forum that others don't understand now and don't bother trying to. Also, it's not much different than someone producing a custom function, from a user's standpoint. The user would need to know what is required to be able to use the function provided. In some cases global variables are created by user functions that would not be available otherwise. This isn't really that much different. I realize that someone could decide to make major syntax changes that could make the code look like a totally different language but that is also possible now and most people are not likely to use a preprocessor like that for everyday scripts as the syntax wouldn't be supported in the official release. On the other hand, if for some reason that does happen, and if a lot of people like a particular change, then maybe changes should be considered for the official release.

Another thing (that was previously mentioned) is that it is already possible to create a preprocessor for AutoHotkey code. This suggestion just makes it easier since workarounds for things like Path variables, Reload, etc... wouldn't be necessary.

If there is just one preprocessor, then you don't need to specify its name.

Maybe and only allowing one preprocessor might be a better way to go but I would be surprised if someone didn't request the ability for more than one. Compatibility between pre-processors obviously wouldn't be AutoHotkey's responsibility. It also wouldn't be difficult to design a pre-processor that wouldn't work if other #PP lines are present in the code if necessary.

Why should it be a dll? An exe looks more natural, but even another AHK script would do. With regular expressions very powerful text processing can be done.

A couple reasons. An exe file is usually used for creating a pre-processor when the language does not support preprocessing. The extension used can be pointed to the pre-processor's exe file instead of the original exe and the resulting source file can be created as a temporary file and run by the original exe. A .dll file is generally more suitable for the task when supported by the language though since the original exe can pass data to/from the dll without the use of external files or the need to build in other methods. Dll files are already designed to interact with exe files. Another reason is that forcing use of a dll file could also discourage many inexperienced users from taking advantage of this functionality for changes that are less likely to be desirable. Using a dll file doesn't mean that a exe file couldn't be used though. A dll file could be designed to run an exe also.

What exactly do you expect from a pre-processor? A macro facility proved to be enough for many years in C programming. Maybe conditionals? All of this can be done with regex.

The goal for requesting built in functionality is to avoid having to create a temporary file and create workarounds for aspects of AutoHotkey scripts that rely on the filename that was passed to AutoHotkey for execution.

[corrupt]

Thanks for making the topic; it's a good opportunity to hear what others have to say.

I'm curious also .

in other words, #PP might overlap too heavily with plugins. If true, some of the development time spent on #PP would have been wasted because it could have been spent on plugins. But of far more concern to me are the resulting redundancies in the code and the documentation, which increases the learning curve for AutoHotkey.

I don't think this would overlap with plugins at all. The reason I say this is that pre-processing would happen first and the resulting code would be passed to Autohotkey to process as normal Autohotkey code. Any syntax related to a particular plugin should remain intact. If there is a conflict between a particular pre-processor and a plugin then the user has a choice to either stop using the pre-processor dll that is providing the functionality for the syntax used or stop using the plugin. Other options might also be available from the authors of the add-ons of course.

The documentation for the suggested functionality should be very brief. Something like "A .dll file can optionally be created by a user to pre-process AutoHotkey code before it is processed and exucuted by AutoHotkey." along with the syntax necessary and name of the function and params that are expected to be in the dll.

Although I realize and respect that every moment of time is valuable and could be spent on something else, from the times you previously estimated (which were probably worst case scenarios), we will likely have spent more time discussing this in this forum than it would take you to implement the changes.

Like Laszlo, I think #PP might eventually split AutoHotkey into two or more languages (I realize you have no intention of this; but it might produce that effect over time).

I don't see this happening. After the code is pre-processed, the resulting code is still AutoHotkey code. If someone wanted to create their own language they would likely go for the source (which is freely available). Also there is nothing stopping someone from creating another language using AutoHotkey now.

This might complicate the documentation by requiring a new section to describe the syntax specific to each #PP DLL.

Why would you want to do that? Documentation for functionality provided by others should be the responsibility of those that create the add-on(s). I haven't seen CMDret in the index in the AutoHotkey documentation (or other functions provided by others) for example (I'm actually surprised to find CMDret mentioned in the FAQ)...

Even if it were decided that #PP should be added, I feel that features like stdlib are a higher priority. Also, I think stdlib should be a built-in feature (i.e. not dependent on #PP). In part this is because external DLLs would reduce the portable, stand-alone nature of AutoHotkey.exe.

I don't don't feel that having to add a third file to a directory would classify as reducing portability (the script, AutoHotkey.exe, and a .dll file) but I agree about stdlib being a higher priority and agree that stdlib would be better built in.

[corrupt]

Over the last three years, expectations have risen for the quality of new features added to AutoHotkey. Therefore, I think new features should be as professional as possible, not "quick and dirty". Since I'm not a language design expert, I look to other languages for professional features and syntax -- yet I'm unaware of any other popular languages that have preprocessing support such as #PP.

I don't see this as being "quick and dirty". Quite the opposite. This allows changes to be made by a user that become transparent and look and feel like features that are built-in. One example of another language (although not an interpreted language) is BCX. This is from the BCX documentation on the subject. The suggestion I'm making is obviously less complex.

$PP directive

Purpose: $PP directive causes a preprocessor named bcxpp.dll to be invoked and each succeeding source line to be preprocessed until a second $PP is encountered.


Syntax:

$PP' Loads and turns on preprocessor.
' source code here to be preprocessed
$PP' Turn off preprocessor.



The preprocessor is a dynamic link library named bcxpp.dll that is located within the paths that Win32 looks for .dlls. See Win32 SDK help file under "LoadLibrary" for details.

The template(bcxpp.bas) for making a pp dll can be downloaded from the BCX Yahoo Files/BCX_Files section. The pp dll contains one exported procedure called ProcessLine. After processing all directives and just before parsing a line of code, BCX passes the line to the preprocessor for handling as it sees fit. Then the pp passes the line back to BCX which proceeds normally.

Here is a template for a Preprocessor DLL:


'====================================================================
' BEGIN Preprocessor DLL TEMPLATE
'====================================================================

$DLL

'====================================================================
' BCX Preprocessor DLL
' Created by Vic McClung 4/19/2003
' ===================================================================
' This dll must be in a place where Win32 looks for DLLs. I
' recommend putting it in the /bin folder of BCX.
'====================================================================
' FUNCTION ProcessLine(Src$) AS LONG EXPORT
' put code to preprocess modify Src$
' Src$ is passed by reference so any changes
' will be returned to BCX for final processing.
' FUNCTION = 1 ' Return 0 means error
' ' Return 2 means to goto ReProcess: label and reprocess line
' END FUNCTION
'====================================================================
' Note: When you arrive here, BCX has already TRIM$(Src$) and processed
' all lines with directives such as $COMMENT, $CCODE, $LIBRARY, etc. If you
' want BCX to run the line back thru from the start, then return 2 and it
' will goto ReProcess label and it will behave just as if it had read the
' line from the source file. Be careful if you do this. In fact, be
' careful when you use the preprocessor, period.
'
' One other thing is worth mentioning, BCX has removed the _ continuation
' characters at the end of lines and concatenated those into one long line
' when this procedure is called.
'====================================================================

' Enums for tokkinds - kinds of tokens
ENUM TOK_ERROR, _ ' Error
TOK_EOF, _ ' End-Of-File
TOK_NL, _ ' Newline
TOK_ID, _ ' identifier
TOK_NUM, _ ' number
TOK_STR, _ ' string literal
TOK_OP, _ ' operators
TOK_SYM, _ ' symbol
TOK_CMT, _ ' comment
TOK_INC, _ ' include
TOK_META, _ ' meta statement
TOK_ILC, _ ' in line 'C' code
TOK_LCC, _ ' line continuation char '_' in BASIC
TOK_KW, _ ' Keyword
TOK_CMD, _ ' Command
TOK_FUNC, _ ' built in function
TOK_EOL, _ ' End of Line CHR$(0)
TOK_LABEL ' label:

GLOBAL stack$[512]
GLOBAL tokkind[512] AS LONG
GLOBAL index AS LONG
GLOBAL p AS CHAR PTR
GLOBAL token$

FUNCTION ProcessLine(Src$) AS LONG EXPORT
LOCAL kind AS LONG, i AS LONG
p = Src$
index = 0
DO
IF *p = 0 THEN EXIT LOOP
token$ = ""
kind = getNext()
IF kind THEN
IF kind = TOK_CMT THEN
token$ = MID$(Src$,(p - Src$))
*p = 0
END IF
IF kind = TOK_EOL THEN
EXIT LOOP
END IF
stack$[index] = token$
tokkind[index] = kind
index++
ELSE ' error
Src$ = token$ ' put error message in Src$ to pass back to BCX
FUNCTION = 0' return 0 to indicate error!
END IF
'===============================================================
' code goes here to process the tokens contained in stack$ array
'===============================================================
LOOP
'====================================================================
' Return a zero to throw an error back to BCX and return the error
' message in the Src$ string. Return 2 if you want to run this line
' back thru from the top just remember that you may get it again
' as the next line to process, depends on what line contains.
'====================================================================
FUNCTION = 1
END FUNCTION

FUNCTION getNext() AS BOOLEAN
' see bcxpp.bas code for parser/tokenizer code
END FUNCTION
'====================================================================
' END Preprocessor DLL TEMPLATE
'====================================================================

The BCX Preprocessor:

Normally, BCX reads each line from the source file, one line at a time. Before BCX reads the next line, a flurry of stuff happens -- called parsing and tokenizing. If BCX's parser / tokenizer does not understand the line coming in from the BASIC source file, either an error is thrown or bad code is emitted.

The preprocessor is a dynamic link library named bcxpp.dll that is located within the paths that Win32 looks for .dlls. See Win32 SDK help file under "LoadLibrary" for details. Simply put, what the bcxpp.dll does is intercept the line of code coming in from the Basic source file and allows the user to change or modify it to suit and then pass the modifed code back to BCX's parser/tokenizer routines to handle as it would normally.

The bcxpp.dll allows one to introduce new meta-commands, structures,functions, constants, almost anything, and to translate these new(NOT BUILT IN FEATURES) into a format that BCX will accept -before- BCX parser/tokenizer gets a crack at it.

Think of the BCX preprocessor(dll) as a user-defined PLUGIN. The bcxpp.dll is only needed if you try to use the functionality defined inside a bcxpp.dll, otherwise BCX will function without it.

Notes about $PP:

When BCX encounters the first occurence of $PP, it loads the dll if it can find it. If it cannot find the dll or cannot locate the ProcessLine procedure in the dll, it aborts with appropriate message. In addition to loading the dll on the first instance, BCX turns on preprocessing and passes the source code line to the preprocessor. Each subsequent encounter simple turns the preprocessor on if off and off if on. The dll is unloaded by BCX upon termination.
Each line of code which is not part of a directive or directive is passed to the preprocessor. For example, lines of code beginning with a comment is not passed, lines of between $comment directives are not passed, etc.
BCX passes the source code line(Src$) with the spaces removed from both ends of the line.
BCX passes a long line or one that has had all of the line continuation characters removed and the line concatenated into one long line of code.
BCX preprocessor has its own parser/tokenizer to build the stack$/tokkind$ arrays and index token counter variable.
Do not use the STDCALL directive with $DLL.
Do not link with the -nounderscores liner switch because the preprocessor function will be called as '_ProcessLine' from BCX.

[PhiLho]

I voted No, I don't like this idea...
First problem I see: you create a dependency to an external file. So far AutoHotkey managed to be self-contained. With this idea, you will need to download some DLL to execute a given script, a DLL which might be different from the 10 others I already have... And when you distribute a script, you need to provide the DLL as well.
Very impractical.

As you point out, the BCX (which I don't know) is compiled: a preprocessor for a compiled language doesn't get in the way -- as long as you have it at compile time, it doesn't influence the generated runtime.

Note that early C compilers uses a separate program to manage the preprocessor directive. I believe it is integrated to the compiler now, but there is an external preprocessor, named m4 if I recall correctly (and lot of non-standard ones).

I'm unaware of any other popular languages that have preprocessing support such as #PP

Lua used to have a preprocessor directive in early versions, but it has been dropped.
Now, they are experimenting with a not-yet-official extension named token filters. I haven't looked closely at it, but it seems it allows source code alteration in C or in Lua, before it is tokenized. This would allow syntactic sugar (eg. changing foo += x to foo = foo + x), syntax changes, and so on.
The same fear of language fragmentation has been raised (although lot of Lua user just change (hard-code) the lexer to fit their taste) and this is still experimental.

Now, I am not opposed to some standard preprocessor, close of the C one (perhaps simpler).
For example, one could use #ifdef DISABLED where DISABLED hasn't been defined, to disable a large section of code (block comments cannot be nested). Or to have a script with different hotkeys, depending on a command line parameter.
Or, most wanted by me, to make some kind of inline functions. My idea here is to make DllCall wrappers, a bit like those in VB:

#define CopyImage(hBitmap)
	DllCall("CopyImage"
			, "UInt", hBitmap
			, "UInt", IMAGE_BITMAP
			, "Int", 0, "Int", 0	; Keep same dimensions
			, "UInt", 0)	; No special flag
#enddefine ; Nicer than C's backslashes on end of lines...
#define LoadImage(fileName)
	DllCall("LoadImage"
			, "UInt", 0				; HINSTANCE hinst, NULL for file
			, "Str",  fileName			; LPCTSTR lpszName
			, "UInt", IMAGE_BITMAP	; uType
			, "Int",  0				; cxDesired
			, "Int",  0				; cyDesired
			, "UInt", LR_LOADFROMFILE		; fuLoad
			, "UInt")
#enddefine
#define BitBlt(hdcDest, xDest, yDest, w, h, hdcMem, xSrc, ySrc)
	DllCall("BitBlt"
			, "UInt", hdcDest	; HDC hdcDest
			, "Int",  xDest	; nXDest
			, "Int",  yDest	; nYDest
			, "Int",  w		; nWidth
			, "Int",  h		; nHeight
			, "UInt", hdcMem	; HDC hdcSrc
			, "Int",  xSrc		; nXSrc
			, "Int",  ySrc		; nYSrc
			, "UInt", SRCCOPY)	; DWORD dwRop=SRCCOPY
#enddefine
; Seen in Laszlo's code
#define AscAt(Pass, a)
	Asc(SubStr(Pass, Mod(a,StrLen(Pass))+1, 1))
#enddefine

It should be faster than making a simple function wrapper (but it has to be proved!) and allows to hide ugly details (like parameters never used or always the same).

Now, as usual, that's just a proposal which might be very inconvenient/hard to implement, and I can live with just function definitions... :-)

[corrupt]

I'm a bit confused by the reasons given so far about why this shouldn't be added. It seems the main reason is that this might cause people to alter the language. Isn't that the point of creating a module/plug-in to begin with?

Also, this is already possible. I'm simply asking to make it easier/more convenient.

The argument that you might already have a dll by that name and need to download an additional file is a weak one. You could have an uncompiled or compiled script by the same name as one that was made available for download. There are scripts available already that require an additional dll to be downloaded and nobody is complaining about them. There are also scripts that require images, ini files, etc...There are many scripts that already require a user to download additional files and we're only talking about sticking one extra file in a directory. Also, like many other add-ons currently available, you wouldn't have to use it if you didn't want to. The dll would be completely optional and wouldn't affect AutoHotkey if it didn't exist.

Oh well, I'll do it the longer way ...or bite the bullet and work on compiling AutoHotkey in a different version of VS (express probably) and make the necessary changes.

[PhiLho]

I didn't wrote my objections were compelling, but these are issues to be raised.
I won't mind having an external DLL to perform stuff that cannot be done in pure AHK, like REs before it has been built-in, or SQL support, etc.
I would be more reticent for a DLL which is just a convenience for the developer, producing pure AHK code.
Well, that's the advantage of a preprocessor in exe form instead of a DLL: you can write a script the way you want, run the preprocessor on it, and distribute the pure AHK code, as is or compiled.
You can even give the two versions: your, which you might find more readable (like my examples of DllCall wrapper), and the final one, running on plain AutoHotkey distribution.
Added bonus: no runtime preprocessing, it has been done once and for all, so no overhead (admittedly probably unnoticeable for most scripts).

[corrupt]

I apologize for the tone of the response, PhiLho. ...need coffee...
I realize what you are saying but I'd prefer to parse and run in one action. Besides being able to distribute code in a way that is more convenient to use (the main reason for making an add-on), I would prefer not to have to take that extra step when designing and testing code. That's one of the nice things about interpreted languages. The fact that you don't have to compile then test, compile then test, compile then test, etc, etc... Creating an option to output the code generated by a dll wouldn't be difficult to be able to provide the generated .ahk code to others.

[PhiLho]

Creating an option to output the code generated by a dll wouldn't be difficult to be able to provide the generated .ahk code to others.

Would be the best of both worlds... :-)

or bite the bullet and work on compiling AutoHotkey in a different version of VS (express probably) and make the necessary changes.

Providing ready to use code might help Chris to adopt the proposal...

[Chris]

Although I realize and respect that every moment of time is valuable and could be spent on something else, from the times you previously estimated (which were probably worst case scenarios), we will likely have spent more time discussing this in this forum than it would take you to implement the changes.

Even if #PP were already coded, there's also the issue of whether it should even be included in the main distribution. The thousands of copies of AutoHotkey.exe out there would each have to carry this code around even if it isn't used by most people. This impacts memory utilization and startup time (not much, but it adds up).

Or, most wanted by me, to make some kind of inline functions. My idea here is to make DllCall wrappers... It should be faster than making a simple function wrapper (but it has to be proved!) and allows to hide ugly details (like parameters never used or always the same).

It's great that you bring that up because it makes me realize how much more I want preprocessor macros than I do #PP. In fact, preprocessor macros might be able to do almost everything #PP can do, without the need to know/learn how to create a DLL.

Corrupt: If you agree with the above, maybe your effort would be better spent in developing a prototype of preprocessor macros.

[majkinetor]

Deduction of our most important members is really below any level this time, including author.

I think most would agree that plugins are a "best of breed" feature in terms of their potential seamlessness and professionalism. I contend that plugins are a superset of pre-processing; in other words, #PP might overlap too heavily with plugins.

Preprocesor has nothing to do with plugins. Its entirely different topic.
Preprocesor is there to solve syntax problems, plugins are there to solve functionality problems. There is not any set relation betwen those two, except that cross-section is empty.

First problem I see: you create a dependency to an external file.

No you don't. Users that want PP create it, those that don't use it don't. If you want PP, then you know what it does, and you can live with additional dll.

With this idea, you will need to download some DLL to execute a given script, a DLL which might be different from the 10 others I already have... And when you distribute a script, you need to provide the DLL as well.

OMG ???
If you create window that have icons, you have to distrubute icons right ?
And those 10 icons you downloaded are different then all 100 you have now ? :lol:
Plese Philho, get serious.

Very impractical.

PPL are allready using other impractical dlls.... :roll:

I'm a bit confused by the reasons given so far about why this shouldn't be added. It seems the main reason is that this might cause people to alter the language. Isn't that the point of creating a module/plug-in to begin with?

Not only that. The problem here is lack of imagination and appropriate argumentation (which is indeed hard, as drawbacks don't exist, up to the design & implementation time)

Also, this is already possible. I'm simply asking to make it easier/more convenient.

Everything is possilbe now to do up to some level.
The point here is do you want to work like a man, or work like a n00b. If you work like a man, than reliablility, performance and simplicity is the goal, something we generaly can't do now without impacting one of the 3 goals we have as serious developers. I don't remember (in time that I visit this forum) any of the ppl showing here to create any more complex self contained addons for AHK, except corrupt and me. If you have looked the code and various workarounds we do as of missing ahk elements you would know there are bunch of problems. Laszlo is in short code camp, so it is contrary to his definition. Philho provides useful things, but they are either functions of specific domain - those that do something with input so don't require more isolation then those provided by function body - or not self contained.

Oh well, I'll do it the longer way ...or bite the bullet and work on compiling AutoHotkey in a different version of VS (express probably) and make the necessary changes.

After a year here, it appears that code-branch is the only solution to make AutoHotKey shine (by other name).

Well, that's the advantage of a preprocessor in exe form instead of a DLL: you can write a script the way you want, run the preprocessor on it, and distribute the pure AHK code, as is or compiled.

Exe or DLL are just different interfaces for the same thing, one to be more convenient then another in some situations. I don't care which will be, dll, or exe. I used exe so far in other languages but they has nothing to do with AHK specific usage and syntax. About problems with viewing produced AHK code that can be easily obtained with DLL too, with appropriate option like corrupt already concluded.

Even if #PP were already coded, there's also the issue of whether it should even be included in the main distribution.

You can always maintain single project with some compiling flags to produce version that will omit or include #PP. Something ppl do for years with ansi/unicode.

It's great that you bring that up because it makes me realize how much more I want preprocessor macros than I do #PP. In fact, preprocessor macros might be able to do almost everything #PP can do, without the need to know/learn how to create a DLL.

I agree that macros are more generaly useful to broader range of ahk population. Its what i called #define and gave the examples in the Wish list. It is not only convinient but it will solve some performance problems.
But again, macros are really small subset of PP. Macro is genearly used to influence local environment, PP is used to influence entire script. Many thigns can be solved with PP that can't be solved with macro.

For instance, specifying functions where we can specify only subroutines (one ugly uspect of AHK) now, like in this code:

Gui, Add, Button, [color=green]g[/color]OnButtonClick

can not be change by any macro to support functions in format

Gui, Add, Button, [color=green]f[/color]OnButtonClick

This can be solved transparently by PP that will search for extended syntax elements and do code changes on various places. In this case, it has to produce following code:

Input:

Gui, Add, Button, fOnButtonClick
OnButtonClick( ctrl ) {
   Msgbox Button %ctrl% clicked
}

Output:

[color=green]Gui, Add, Button, g_OnButtonClick[/color]

OnButtonClick( ctrl ) {
   Msgbox Button %ctrl% clicked
}

[color=green]_OnButtonClick:
        OnButtonClik( A_GuiControl )
return[/color]

Doing the same thing with macros is probably possible but then you will end up like some of the notorious frameworks having mambo-jumbo macros where preprocesor had to enter the job (MFC?)

[corrupt]

The thousands of copies of AutoHotkey.exe out there would each have to carry this code around even if it isn't used by most people. This impacts memory utilization and startup time (not much, but it adds up).

You would be that concerned with the time taken to parse for an additional directive... ?

Corrupt: If you agree with the above, maybe your effort would be better spent in developing a prototype of preprocessor macros.

I would be interested in reading a lot more detail on usage and implementation in a new topic (with a poll maybe). At a glance the suggestion doesn't seem to offer any more functionality than a regular function and could be accomplished using a decent stdlib implementation. The suggestion doesn't seem to offer as much flexibility as #PP so I'm less likely to give it a higher priority.

[Chris]

Majkinetor, you made some good points in your post (even though it didn't much alter my opinion on the subject).

The thousands of copies of AutoHotkey.exe out there would each have to carry this code around even if it isn't used by most people. This impacts memory utilization and startup time (not much, but it adds up).

You would be that concerned with the time taken to parse for an additional directive... ?

I meant the memory used by the code itself. I believe that all code in an EXE is loaded into memory, even parts that never execute. Also, the file-size of AutoHotkey.exe affects how quickly it launches. I realize these are minor considerations compared to things like documentation complexity -- but I think they should be weighed for any new feature that is significant in code size (especially if it also impacts compiled scripts).

I would be interested in reading a lot more detail on usage and implementation in a new topic (with a poll maybe). At a glance the suggestion doesn't seem to offer any more functionality than a regular function and could be accomplished using a decent stdlib implementation. The suggestion doesn't seem to offer as much flexibility as #PP so I'm less likely to give it a higher priority.

It's basically a substitution process (like search and replace) that executes before the script begins running. It would often be used to hide complexity and improve performance, such with DllCall. For example:

#define IS_SPACE_OR_TAB(c) (c == ' ' || c == '\t')  ; A macro from the AutoHotkey C++ source code.

The above is a simple example; more complex ones can substitute multiple lines of code for a single quasi-function located anywhere in the script. These quasi-functions would be replaced with their expanded counterparts before the script begins running.

I won't go into more detail because I think there are some topics somewhere that already cover it in depth. I've also mentioned in some of those topics that preprocessing is planned, perhaps just as a simple #define directive like the above.