Pre-execution Code Topic is solved

Propose new features and changes
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Pre-execution Code

29 Nov 2017, 14:44

It would be useful to have the ability to pre-execute code prior to loading any scripts. Say, you have hundreds of scripts and want to apply `#Include <MyClass>` to all of them. Currently you have to insert the line in every single script. I'd like to see a more convenient way for it. Not only including classes, this allows us to pre-set directives like `#NoEnv`, `#SingleInstance, Force` etc.

When `AutoHotkey.exe` is double-clicked, it first tries to find AutoHotkey.ahk in the same directory or the current user's Documents directory and executes it if exists. I'm wondering whether a similar approach could be done. Like, if there is AutoHotkey.ini (the name can be settings/config/manifest and the file extension can be xml/yaml/json or whatever) in the same directory, AutoHotkey.exe tries to read the settings from it. Then if there is an entry like `PreExecutionPath`, then it loads the code of that specified file path before loading the actual script code.

Another idea to achieve the suggested functinality is that when a reserved file name (like `.ahk` without any base name or whatever) is in the `Lib` direcotry, `AutoHotkey.exe` first loads the code of that file and continues the actual script.

This adds an overhead of checking file existence, however. To avoid that, this behavior can be enabled only when a switch in script arguments such as `/pre` is passed.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: Pre-execution Code

29 Nov 2017, 15:27

why?

the only use-case you suggested so far is to save typing #include in each script, which can already be saved by using the library paths

A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

29 Nov 2017, 16:27

guest3456 wrote:why?
Why? I'm surprised to see such a response. Needless to say, it will be incredibly useful. When you have hundreds of scripts you regularly use, this allows you to change necessary settings applied to all of them at once such as SetBatchLines, #NoEnv, #SingleInstance, SetTitleMatchMode, FileEncoding and so on. Not only that, even you won't need to write #Include lines any more if the pre-execution file has them. This will make your script code compact and clean. Also, if you want to implement a plugin system in your program, this can take care of loading necessary components so that plugin writers do not have to care about them.
guest3456 wrote:which can already be saved by using the library paths
Can you elaborate? I might be missing something.
A_AhkUser
Posts: 1147
Joined: 06 Mar 2017, 16:18
Location: France
Contact:

Re: Pre-execution Code

29 Nov 2017, 16:52

Hi A_User,

Consider this part of the documentation:
Libraries of Functions: Standard Library and User Library
my scripts
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

29 Nov 2017, 17:05

A_AhkUser wrote:Consider this part of the documentation:
Libraries of Functions: Standard Library and User Library
Hello. I don't see how it is related to the suggestion.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Pre-execution Code

29 Nov 2017, 17:19

This has come up before.

All it saves is a single line at the top of the script. That line could be #include <something> or something(), where something() can perform auto-execute code or do nothing at all. (Either way it would cause the inclusion of something.ahk, which may contain directives or other things.)

It makes scripts less portable (each user must have the same auto-inclusions) and there are costs implied by having code invisibly added to the script (such as causing confusion if the user forgets or is otherwise unaware).
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

29 Nov 2017, 17:26

I like the idea in theory, I've said that ideally A_AhkPath should be usable with #Include. This would be the simplest way to implement such an idea. That way the script could use #Include *i to check for something like 'C:\Program Files\AutoHotkey\AutoHotkey.exeSettings.ahk' (slightly odd name). And so you could have unique settings for every AHK exe that you used. E.g. this would be useful for varying initial setups and supporting multiple versions of AHK.

Wish List 2.0 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 13&t=36789
- #Include: support more 'A_' variables (A_Desktop, A_AhkPath, A_UserName, possibly 'A_Args##')
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
Nextron
Posts: 1391
Joined: 01 Oct 2013, 08:23
Location: Netherlands OS: Win10 AHK: Unicode x32

Re: Pre-execution Code

29 Nov 2017, 17:36

A_User wrote:it will be incredibly useful. When you have hundreds of scripts you regularly use, this allows you to change necessary settings applied to all of them at once such as SetBatchLines, #NoEnv, #SingleInstance, SetTitleMatchMode, FileEncoding and so on. Not only that, even you won't need to write #Include lines any more if the pre-execution file has them.
Although I understand your reasoning, you're ending up with an unreferenced dependency for your code. If you change default settings such as SetTitleMatchMode from an external file, either by including a script or calling a library function, you'll know something is being done when you only read the main script. Importantly; without those files your script will not run.
However, if you change defaults settings from an external file that apply to all your scripts automatically, your scripts become less portable/reliable. Running it from a computer without your settings will not prevent the script from running, but it may prevent it from running as expected or it may even completely misbehave.

Edit: Hm.. Looks like I missed the notification there were new posts since clicking reply.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

29 Nov 2017, 17:44

- If you were able to use A_AhkPath with #Include as I described, you could use a go-between exe (AHK + script or compiled script) as the exe that opens when you double-click an AHK file.
- That go-between exe could scan the script's code/check its path and open the script with the appropriate AHK exe. That AHK exe would then have its own settings script (if it exists) as specified by the #Include line.
- I've often thought about temporarily creating scripts by combining an AHK 'settings' file and a script proper, and then launching it, but not wanting to do this.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

29 Nov 2017, 18:04

lexikos wrote:All it saves is a single line at the top of the script. That line could be #include <something> or something(), where something() can perform auto-execute code or do nothing at all. (Either way it would cause the inclusion of something.ahk, which may contain directives or other things.)
It saves hundreds of lines when there are hundreds of scripts.
lexikos wrote:It makes scripts less portable (each user must have the same auto-inclusions) and there are costs implied by having code invisibly added to the script (such as causing confusion if the user forgets or is otherwise unaware).
Scripts relying on libraries already not portable in that sense.

There are two types of users: script writers who write code and script executors who just execute provided scripts. For the latter, the script portability does not matter. The maintenance is done by script writers who distribute the script. The former type of users indeed need to remember what is done with the pre-execution code. But to maintain the script is what they are for when providing useful scripts to the general public.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Pre-execution Code

29 Nov 2017, 18:19

There are several use-cases for this. Including Scripts automatically is just first step.
What if we automatically recognize needed object includes - that normally need the #Include line.
What if we automatically built a project structure for this script with the neccessary includes moved into the correct place.
What if we automatically compile included Machine Code from source.
The possibilities of this are endless.
Recommends AHK Studio
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: Pre-execution Code

29 Nov 2017, 19:01

A_User wrote:
guest3456 wrote:why?
Why? I'm surprised to see such a response.
you can be surprised all you want, but you've yet to give a use-case other than defining some autoexecute directives. as lexikos said, your request saves 1 include line. and i thought that you didnt need to have the include line if the class file was in your library folder, but maybe i was wrong about that

it saves 100s of lines if and only if a user is running 100s of seperate scripts that all would require the same autoexec settings. why would a user be running 100s such scripts? why wouldn't those scripts be combined into a smaller number?

so again, why? it was a direct question. give specific examples of how you would use this and what benefit you think it provides

User avatar
Exaskryz
Posts: 2882
Joined: 17 Oct 2015, 20:28

Re: Pre-execution Code

29 Nov 2017, 20:08

A_User wrote:
lexikos wrote:All it saves is a single line at the top of the script. That line could be #include <something> or something(), where something() can perform auto-execute code or do nothing at all. (Either way it would cause the inclusion of something.ahk, which may contain directives or other things.)
It saves hundreds of lines when there are hundreds of scripts.
lexikos wrote:It makes scripts less portable (each user must have the same auto-inclusions) and there are costs implied by having code invisibly added to the script (such as causing confusion if the user forgets or is otherwise unaware).
Scripts relying on libraries already not portable in that sense.

There are two types of users: script writers who write code and script executors who just execute provided scripts. For the latter, the script portability does not matter. The maintenance is done by script writers who distribute the script. The former type of users indeed need to remember what is done with the pre-execution code. But to maintain the script is what they are for when providing useful scripts to the general public.

To the contrary, I believe for script portability it is vital. I've accidentally run into it a few times here. I run a Test Script.ahk where I experiment with thousands of hotkeys to help solve problems for users on the board. My auto-execute section looks like this:

Code: Select all

#If
SetWorkingDir, %A_ScriptDir%
#SingleInstance, Force
SetTitleMatchMode, 2
SetKeyDelay, 70
SetWinDelay, -1
CoordMode, ToolTip
CoordMode, Mouse, Screen
SetTimer, StopWinStick, 1000
;SetTimer, Motivation, 3600000
SetWindowBlur()
OnMessage(0x999,"Test")

SetTimer, Pushups, % 60000 * 25
Tooltip HELLO
Sleep 500
Tooltip
return
I have actually run into a couple of times where the CoordMode, Mouse, Screen setting not being the default (it's normally Window/Relative) has messed up my answer when I provided working code to someone and it doesn't work for them. And I believe a couple of times the SetTitleMatchMode being changed, although I usually try to remember I've set that. Several of these functions are just my own not being moved into my "Usual" script where they really should be; I do that ever few months. But because of that, I don't actually share my auto-execute section which is cluttered when I make answers. (Never mind that I have a few "short-term" hotkeys and hotstrings below the auto-execute section but before my "testing area" in my script.)

The point of all this is that if a script author forgets to share his Configuration File with the predefined path and what functions and settings s/he is defining, that will result in non-working code for the author. Never mind if the code that is attempted to be used is years old and the original author cannot be contacted. Even if you do find a pre-execution code/config file to use in conjunction with that script, it may only work for that one script. Imagine if the user is using code from multiple authors who use different pre-execution code that necessarily creates a conflict. Either on every script launch they edit the config file to use the correct script, or they manually edit one of the files' auto-execute sections to overwrite the settings of the pre-execution code (like SetTitleMatchMode, 2 vs SetTitleMatchMode, RegEx. If a script depends on RegEx, but another author uses 2 in his pre-execution code, using the second author's pre-ex code will break the first's code.)

Using #Include A_AhkUser_PreExecution.ahk and #Include Exaskryz_PreExecution.ahk gets around this conflict of different default settings from different authors and "universal" functions. It also makes it explicit to the end user that there are other scripts they need to have to get the code to work.

----

For your scenario of having hundreds of these scripts and just now deciding you want to be able to change up the defaults, consider AHK to do that. FileRead all your scripts into vars (one at a time), then FileDelete the script (well, create a back up (FileCopy/FileMove) or just append to a differently named file), then use FileAppend to #include your universal A_AhkUser_PreExecution.ahk, and finally FileAppend the var from FileRead.
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

29 Nov 2017, 21:06

guest3456 wrote:and i thought that you didnt need to have the include line if the class file was in your library folder, but maybe i was wrong about that
It seems you have misunderstood the behavior of #Include and the rest of what you wrote is based on your misunderstanding.

My personal use case would be inserting code that does presets for scripts which serve as child processes. Those child process scripts can be written by anybody so the requirement to write #Include ... in every child script is not realistic. This is my personal need but the suggested functionality should be useful in many other ways.
Exaskryz wrote:To the contrary, I believe for script portability it is vital.
As I said, it does not matter for the other type of users who do not read the code.

Furtheremore, this is suggested to be an option with a script argument. If you don't think you can handle it, you can choose not to enable the option. Use AutoHotkey in the way you have been using. On the other hand, this will give more freedom to advanced users.
FileRead all your scripts into vars (one at a time), then FileDelete the script (well, create a back up (FileCopy/FileMove) or just append to a differently named file), then use FileAppend to #include your universal A_AhkUser_PreExecution.ahk, and finally FileAppend the var from FileRead.
Frankly, not convenient at all.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

29 Nov 2017, 22:30

- Perhaps an idea would be syntax to enable including files via the command line. You double-click an AutoHotkey script, the go-between script (that ahk files open with) sees what folder it's from, and launches AutoHotkey instructing it to include files X.Y.Z via the command line.
- Btw, re. an automatically included file: it would limit AutoHotkey if you could only ever have one automatic 'settings file' per exe. In general, I don't like the idea of anything hidden, although again, you could have a command line option, that, if on, looks for a specific file, with a predetermined filename pattern, to include.
- Btw, I'm just thinking through the options, for a long time, personally, the only thing I'd change about #Include, is to allow a few more 'A_' variables.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
Nextron
Posts: 1391
Joined: 01 Oct 2013, 08:23
Location: Netherlands OS: Win10 AHK: Unicode x32

Re: Pre-execution Code

30 Nov 2017, 01:44

jeeswg wrote:- Perhaps an idea would be syntax to enable including files via the command line. You double-click an AutoHotkey script, the go-between script (that ahk files open with) sees what folder it's from, and launches AutoHotkey instructing it to include files X.Y.Z via the command line.
I like this solution. You could even duplicate the .ahk extension handling in the registry to something else to highlight the non-standard setup. E.g: .ahkx files automatically invoking c:\Program Files\AutoHotkey\AutoHotkey.exe c:\Program Files\AutoHotkey\Defaults.ahk %1

And Defaults.ahk would read %1%, prepend it with your default commands and dynamically run it.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

30 Nov 2017, 01:57

You could have a command-line switch, which if present, means that AutoHotkey concatenates the paths after the switch, and executes it as one script. So AutoHotkey.exe /switch Path1 Path2 Path3 Path4, would be like a blank script with 4 #Include lines.

[EDIT:] One file would have to be specified as the main file. E.g. for programs that list and interact with AutoHotkey scripts. So perhaps AutoHotkey.exe /switch Num Path1 Path2 Path3 Path4. But then there could be complications re. errors and stating which line in which script has a problem. So perhaps back to adding an #Include line at the top of each script, but supporting a few more 'A_' variables.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Pre-execution Code

30 Nov 2017, 16:26

nnnik wrote:The possibilities of this are endless.
Everything you can do with the proposed feature, you can already do by adding a single #Include to the top of your script. Your first two ideas appear to require pre-processing; and if you have a pre-processor, you can use it to insert whatever auto-includes you want.

nnnik here - I accidently clicked on edit instead quote and now the post is mostly gone if anyone has still parts of the content and could help me restore it I would be grateful
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

30 Nov 2017, 16:41

- @lexikos: You're right about it being potentially 'needlessly complicated and unfamiliar', I suppose I had in mind that you might want the contents of the scripts to be concatenated in a particular order, i.e. which go before/after the main script.
- Or you might have a situation, the more limited functionality, where included files are only placed after the main script.
- So you would need to somehow indicate (a) which is the main script, (b) the order of the scripts.
- [EDIT:] You might for example, specify the main script twice in the command line, once as the script to launch, and, if you don't want it to be the first script, once in the list of included scripts, perhaps by specifying '.' (some invalid filename), instead of writing out the path again.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

30 Nov 2017, 18:28

lexikos wrote:So? The relative time saved is still next to nothing.
Not really. It includes the time to research the requirements. If the program allows users to add their own scripts as a plugin and if the plugin script requires some lines to be added on the top of the script, those users have to know about them and spend time for it. This is the cost. To make the program easier and attact many, the first impression of user experience is higily important. If there is no required line of code, they can freely start coding without concerning any requirements.
Scripts which rely on libraries are less portable than scripts which don't, but that does not mean they are not portable, or that portability ceases to have value.
You say scripts relying on libraries are still portable. Similary, scripts with presets/auto-incluses are still portable. It's a matter of degree. It appears to you that auto-includes are less portable than the library mechanism.
The core purpose of the library mechanism is portability: it attempts to solve the problem of libraries being at a different location on each system, and allows them to be installed per system, per user, or per script/project.
It does not sound portable. Each user has to have the required libraries in some ways. If one of them is missed, the script won't run properly, which is not actually fully portable. The preset/auto-include mechanism is the same thing then. It just a bit appears to be obscure than the library mechanism. The benefit will be huge which you haven't imagined yet.
By contrast, the author's auto-includes must be replicated by every user, unless they are truly unnecessary to the script.
The same applies to library scripts. To run a script relying on libraries in a different environment, the user must have copies of the required libraries. Here, the user is replicating the script author's environment to some extent.
The author may not even remember that they are in effect, in which case the user has little chance of replicating them. If these auto-includes are common to all scripts, a user wanting to use multiple scripts with conflicting requirements would be required to modify the script.
If this suggested feature uses a configuration file, what are in effect will be all written in the configuration file. Or if this suggested feature uses a reserved library file name, what are in effert will be all in that file. If you are afraid of conflicts on script behavior due to different settings such as SetTitleMatchMode, CoordMode, or DetectHiddenWindows, those conflicts are already happening with libraries which use those. That's why there are variables like A_TitleMatchMode, A_CoordMode, and A_DetectHiddenWindows and so on. If you argue that one has to check those values and it will be waste of time, again already one has to check those values when using libraries written by somebody else.
The user cannot simply download the script and its dependencies and run it.
It's already happening with libraries. I often have to find required dependencies when using a library such as ObjTree(). And some Gdip wrapper libraries require Gdip.ahk and it has different versions. To make it work on 64bit environments, Gdip_All.ahk is required.

I'm just telling you that it's already happening and I see no different than what you predict for the suggested feature.
It matters to both - script portability aids every user of a script written by someone else, by definition.
No, it depends. If the author publishes his/her program in one package that includes a number of AutoHotkey scripts and the user just executes the main program's executable, the user only needs to know about the main program. This type of user is the latter type I mentioned.

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 13 guests