Pre-execution Code Topic is solved

Propose new features and changes
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Pre-execution Code

30 Nov 2017, 19:17

A_User wrote:It does not sound portable.
It's a matter of degree. :roll:
If one of them is missed, the script won't run properly, which is not actually fully portable.
Library files can be included with the script (using the "local library"), and do not require overwriting global configuration which affects all scripts. Generally, if a library is missed, the program will tell the user that a library is missing, and the script will not run at all. Missing lines in an auto-include will not be so clear. (I believe Nextron already addressed this.)
The same applies to library scripts.
Copying library scripts into a Lib folder is easier and much less likely to cause conflicts than editing a global configuration or auto-include file. Depending on how the script is packaged, the user may not need to do anything specifically for the libraries.
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.
I think you are saying that the script author should distribute the configuration file with their script, but I think you are missing the point.
It's already happening with libraries.
This is a fault of script authors or the lack of a central library repository. The design of libraries encourages modularity, whereas your global configuration file suggestion encourages conflicts. Many authors of libraries tend to avoid changing global settings (or limit the scope of change to their own functions). If any global changes are made, they only affect scripts which use that library.
I'm just telling you that it's already happening and I see no different than what you predict for the suggested feature.
It's a matter of degree.
This type of user is the latter type I mentioned.
It was reasonable to assume you were talking about a larger majority of users, who use scripts they find on the forum. Now I suppose you meant users of AutoHotkey vs. users of programs written with AutoHotkey. For the second type, none of this matters.
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

30 Nov 2017, 21:43

lexikos wrote:Library files can be included with the script (using the "local library"), and do not require overwriting global configuration which affects all scripts
A library script of a different(possibly old) version must be overwritten; otherwise, the script relying on it will misbehave. Here, it takes a copy-and-replace task in the same way the configuration/auto-include file needs to be replaced.
Generally, if a library is missed, the program will tell the user that a library is missing, and the script will not run at all. Missing lines in an auto-include will not be so clear.
Not sure about what you mean by missing lines. I guess you meant missing files. The point you are making is script misbehaviors caused by different presets and the cause will be less obvious. Then you can just make it show an error message when the specified auto-include/configuration file is missing. It will be as obvious as missing library files.
Copying library scripts into a Lib folder is easier and much less likely to cause conflicts than editing a global configuration or auto-include file. Depending on how the script is packaged, the user may not need to do anything specifically for the libraries.
The same thing. The user just needs a copy of the configuration file and place it alongside AutoHotkey.exe.

If you worry about the possible conflicts so much, a variable to check preset-configuration path or a list of configuration values could be introduced as well shch that the user can call msgbox % A_CongigurationPath(or A_Congigurations/A_AutoIncludePath) to check whether a configuration/auto-include file is in use or not.
I think you are saying that the script author should distribute the configuration file with their script, but I think you are missing the point.
The point you are addressing is possible conflicts brought by different global settings and these will be less obvious than the library mechanism. So I replied it's a matter of degree. It will be obvious enough to track down conflicts by:
- showing messages if the specified path does not exist
- adding an A_... variable that indicates the use of this feature.

I imagine light users would stay without enabling this feature and they won't even care such option exists. Those who use this feature should be experienced enough to predict preset conflicts so they will keep different copies of AutoHotkey.exe and have the plain version of it for testing scripts.
This is a fault of script authors or the lack of a central library repository.
Similarly, conflicts you predict will be a fault of script authors who distribute scripts with required presets.
The design of libraries encourages modularity, whereas your global configuration file suggestion encourages conflicts.
This only applies to those who use only one copy of AutoHotkey.exe. Some users are not limited to this case.

One can always choose not to use the global configurations. That's why this is suggested to be implemented as an option, not by default. You concern a loss of modilarity with this feature. Ironically, it helps to build a modular system for AutoHotkey-driven programs that support plugins to be added and those plugins can be written in the AutoHotkey language without any required lines.
It was reasonable to assume you were talking about a larger majority of users, who use scripts they find on the forum. Now I suppose you meant users of AutoHotkey vs. users of programs written with AutoHotkey. For the second type, none of this matters.
To make it clear what I mentioned regarding user types, there are two types; one is script writers, namely coders. Another is script executors who just run the script and don't read code. There is one I haven't mentioned but implied (actually they belong to the former) those who add AutoHotkey scripts to an AutoHotkey-driven program as a plugin. For them, requiring even a single line of #Include will damage their user experience.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: Pre-execution Code

01 Dec 2017, 00:10

A_User wrote:
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.
no, i'm well aware of what #include does.
A_User wrote: 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.
why is adding one #include line not realistic? you've still yet to give a concrete example. explain these 'child processes'. post some example script and child process and how your suggestion saves anything other than 1 line. if your parent script already knows the presets it needs, then just enforce those when it reads in the plugin script. then your plugin authors dont need to worry about it.

its more likely that your parent/plugin project is just poorly engineered and your suggestion is merely a bandaid to fix your bad design

maybe you should post your example in Ask For Help and ask how it can be done better

User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Pre-execution Code

01 Dec 2017, 00:39

lexikos wrote:
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.
That is as long as the script turns out to be valid AutoHotkey syntax even without pre-processing. E.g. a function that is used and the include is not in the standard library would already make this way impossible.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Pre-execution Code

01 Dec 2017, 01:39

I have no strong opinion on any syntax for this, however, I have tried to come up with a viable syntax, that is both simple and in keeping with the existing command-line syntax.

AutoHotkey Scripts and Macros
https://autohotkey.com/docs/Scripts.htm#cmd

Code: Select all

;2 scripts concatenated: main script is the 1st script.
Run, AutoHotkey.exe [Switches] /inc S2.ahk [Switches] [Script Filename] [Script Parameters]

;4 scripts concatenated: main script is the 1st script.
Run, AutoHotkey.exe [Switches] /inc S2.ahk S3.ahk S4.ahk /endinc [Switches] [Script Filename] [Script Parameters]

;4 scripts concatenated: main script is the 2nd script. Asterisk needed to specify 2nd.
Run, AutoHotkey.exe [Switches] /inc S1.ahk * S3.ahk S4.ahk /endinc [Switches] [Script Filename] [Script Parameters]

;Perhaps '/endinc' isn't needed.
Run, AutoHotkey.exe [Switches] /inc ""S1.ahk" * "S3.ahk" "S4.ahk"" [Switches] [Script Filename] [Script Parameters]
[EDIT:]

Code: Select all

;Perhaps '/endinc' isn't needed.
Run, AutoHotkey.exe [Switches] /inc S1.ahk|*|S3.ahk|S4.ahk [Switches] [Script Filename] [Script Parameters]
Last edited by jeeswg on 01 Dec 2017, 20:27, edited 1 time in total.
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

01 Dec 2017, 04:03

A_User wrote:
lexikos wrote:Library files can be included with the script (using the "local library"), [...]
A library script of a different(possibly old) version must be overwritten; otherwise, the script relying on it will misbehave.
What are you talking about? If the library files are included with the script using the local library, there is no reason to overwrite anything. Just extract the script to its own directory and run it. Perhaps you don't know what the local library is?
Not sure about what you mean by missing lines.
Lines of code which must be present in an auto-include for the script to function correctly, but that are actually missing, either because there is no auto-include configured, or because it instead contains code required by some other script.
Then you can just make it show an error message when the specified auto-include/configuration file is missing.
What specified file? Where is it specified? What should it contain, and how should the program know that it does not contain what it should? I think you missed the point.
If you worry about the possible conflicts so much, a variable to check preset-configuration path or a list of configuration values could be introduced as well shch that the user can call msgbox % A_CongigurationPath(or A_Congigurations/A_AutoIncludePath) to check whether a configuration/auto-include file is in use or not.
I don't see how this solves the problem.
So I replied it's a matter of degree.
I do not see how that is of any relevance to the part of my post to which you are replying, as indicated by the nested quotes.
Similarly, conflicts you predict will be a fault of script authors who distribute scripts with required presets.
When the design makes it impossible to use a feature without risk of conflicts, the design is at fault.
You concern a loss of modilarity with this feature.
No, I did not say that.
This only applies to those who use only one copy of AutoHotkey.exe. Some users are not limited to this case.
Some users won't be affected. For everyone else, it is still a problem.
A_User
Posts: 36
Joined: 21 Aug 2017, 01:15

Re: Pre-execution Code

01 Dec 2017, 05:15

lexikos wrote:What are you talking about? If the library files are included with the script using the local library, there is no reason to overwrite anything. Just extract the script to its own directory and run it. Perhaps you don't know what the local library is?
I talked about the similarity between the library mechanism and the suggested preset configurations. They both would require certain files to run properly. Even with the local library, if the library file is a different version than the version the script expects, the script will misbehave, similar to your predicting conflicts with different presets.
Lines of code which must be present in an auto-include for the script to function correctly, but that are actually missing, either because there is no auto-include configured, or because it instead contains code required by some other script.
The same applies to any library files. If a library file misses lines that do certain tasks, the script relying on the library won't run properly.
What specified file? Where is it specified? What should it contain, and how should the program know that it does not contain what it should? I think you missed the point.
Your point was possible script misbehaviors caused by different presets and they will be less obvious than the library mechanism.

The suggested code pre-execution feature may require a file that is loaded prior to running any scripts. For that, a file path will need to be specified. An idea would be to have a configuration file that has the path, or a library AutoHotkey script with a reserved name. This is talked about in the initial post.
I don't see how this solves the problem.
The problem you addressed was preset conflicts and their causes would be less obvious than the library mechanism. This provides the user a means to check his/her presets so it helps to determine the conflicts.
I do not see how that is of any relevance to the part of my post to which you are replying, as indicated by the nested quotes.
My saying a matter of degree refers to the similarity between the library mechanism which provides portability and the presets feature which you think less portable.
When the design makes it impossible to use a feature without risk of conflicts, the design is at fault.
Likewise, you cannot cover all the risks of conflicts with any design. In fact, the library mechanism already produces conflicts.
No, I did not say that.
So this suggested feature won't damage modurality.
For everyone else, it is still a problem.
I imagine majority of users won't even care the existence of this option. By making the feature as an option that the user must explictly set to enable it, there will be less problems than you predict.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Pre-execution Code

09 Dec 2017, 02:06

Likewise, you cannot cover all the risks of conflicts with any design. In fact, the library mechanism already produces conflicts.
It's a matter of degree.
Even with the local library, if the library file is a different version than the version the script expects, the script will misbehave, similar to your predicting conflicts with different presets.
For that to happen, instead of extracting all files from the archive provided by the author into their own directory as per instructions the author would give (or even as the most obvious thing to do in the absence of instructions), the user must either:
a) extract the main script file from the archive provided by the author into an existing directory which already contains the conflicting library (under the Lib sub-directory); or
b) extract all files from the archive provided by the author, and then replace one Lib file with an incorrect version.

The situation seems very contrived; i.e. your argument holds little weight.
This is talked about in the initial post.
I know, as I read it. You have neither said anything new nor actually answered my questions. (My goal was not the answers themselves, but to get you to go through the process required to give more specific answers.)
This provides the user a means to check his/her presets so it helps to determine the conflicts.
This "answer" provides no new information. I still believe that you haven't actually solved the problem.
So this suggested feature won't damage modurality.
That is neither here nor there. My point was that the suggested feature is inherently inferior than current related features.
I imagine majority of users won't even care the existence of this option.
I agree, and will rest easy with my decision to not develop it.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Pre-execution Code  Topic is solved

02 Dec 2022, 20:27

I believe the /include "IncFile" switch implemented by v1.1.34 supersedes the idea of /pre, with less risk of conflict since the filename must be specified when launching the EXE.

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 18 guests