AutoHotkey Community

If you run scripts from a USB stick, you might want to check if there is a newer version of AHK installed (with its standard library) on the host, than the one in your stick, but you might want to use your own UserLib in stick, so you seem to be better off specifying explicit include paths or files in the scripts run from the USB stick. The registry telling the non-default include directory locations still does not look too bad.

If you run from a USB stick you only have to unzip AutoHotkey to the drive. Having to modify the .exe is inconvenient. If I wanted to modify the .exe I would change the paths manually in C++ and compile my own version to use. The registry entry still doesn't make sense for the reasons that I mentioned and will still produce a delay at the beginning of every script since accessing the registry still involves reading from a separate file (although likely faster than from an ini file). Do you have something against using #Include <c:\YourPathHere> ? This would obviously be the fastest method (other than modifying the .exe itself) as it would be an option that would be built into AutoHotkey and an option that could be changed on a per script basis. This would also be handy for using/testing different directories for Include paths as you had mentioned.

Hmm, but Library seems to be a very common word for the purpose, e.g. DLL (Dynamic Link Library), VCL (Visual Component Library), STL (Standard Template Library)

This is what I found on Wikipedia

_________________
Ciao
toralf

Good point but that definition is mostly known by programmers and the usage here doesn't fully comply.
The data in the .ahk files would mainly be executable and would not really be linked. In AutoHotkey, the code in the .ahk files would just be dumped in at the end of the script as if it was part of the regular script as regular AutoHotkey code. There's no other magic involved in the process. That's one of the reasons that it might be better to use Include so that users realize that that is all that is happening when the code gets auto-included.

First of all, let me clarify that the standard library will be discovered in the folder of the AutoHotkey.exe that was just launched, which isn't necessarily the one where AutoHotkey was installed. This seems to be justified due to portability.

I think altering the EXE is too non-traditional to be seriously considered. The auto-included .ahk file (config/settings), while it might add a 50ms delay to startup when uncached, is probably the lesser evil. In fact, there might be no delay at all if the settings file doesn't exist, which for most people it won't.

That is a good point; but it appears that choice is a small minority unless others have changed their minds.

At first glance, I think the benefit/cost is poor due to its added complexity and rarity of use.

Currently, I don't like the idea of having both command-line parameters and registry entries. For one thing it's complicated, both in code and documentation. For another, the registry is somewhat icky for things like this because it reduces the portability of AutoHotkey.exe; furthermore, a lot of people simply don't like it when software relies heavily on the registry.

In summary, I think there are only 3 approaches: registry, environment variables, and config/settings file. The first two seem undesirable, mostly due to lack of portability, but also because they may require a high-privileged user to make the changes. The latter (config file) -- while also clearly undesirable (and a bit slower during launch) -- seems like the lesser evil. Another advantage of having a config file is that it can be a generic .ahk script that is auto-included at the top of every script. It could contain any commands or directives, most notably a directive like #userlib C:\My Custom Lib Location.

The config file would be discovered in the same folder as the AutoHotkey.exe that was just launched, which isn't necessarily the one where AutoHotkey was installed. However, this config-file feature won't be in the next release, so there will be more time to discuss it.

Yes. The key concept is that the config file would always be in the same directory as the AutoHotkey.exe that is being launched. There would be no dependency on the registry or on having run the AutoHotkey installer.

Instead of overloading #Include, I prefer some kind of new directive. Perhaps #lib stdlib > userlib > C:\OtherDir > ..., which would set the search order. To change the user lib, it could be #userlib C:\My Includes

Thus, the directive #lib stdlib could be used to force only the stdlib to be used for lookups (i.e. omit userlib). This would allow publicly-posted scripts to avoid any chance of interference from a userlib.

Those who voted for "Lib" in the poll: if you feel strongly about lib vs. library, please state the reasons. Otherwise I'll probably go with Library or Include under the assumption that most everyone can live with it.

Thanks.

That sounds good to me. I was actually going to suggest a new directive but suggested #Include <> instead since I had remembered that you had suggested similar syntax recently (as I mentioned).

Well the only reason for the userlib as i see it is to keep the sdlib and 3rd-party libs seperated. I wonder if it would be possible to add subfolders to the stdlib folder. This way keeping sdlib and 3rd-party libs seperated would be easy and it would enable us to create modules that would be distributed as folder which one would just need to copy to the stdlib folder.

Edit: Dang i forgot about the adminrights problems on Vista.

Oops , it looks like I was mistaken with the last syntax that was suggested for this purpose.

One of the reasons for the separate location is that in Windows Vista a user does not have write privileges in the Program Files directory by default. Since this is the most common installation directory, this would prevent most users from being able to add or modify files in that location.

Another purpose for the User directory is to be able to override an existing "Standard" function with a modified version. This can be handy if you prefer to customize a function but don't want to lose your changes when a new version of AutoHotkey is released that might contain an updated version of the function that you had customized. Although it hasn't been discussed in detail yet, it sounds fair to say that anything in the standard directory might be updated when a new version of AutoHotkey is released (or at least a new version of the standard functions if Chris decides to release the standard functions separately).

Yeah i just realised the Vista problem. It could be so convenient but then there is Vista.

It is not only a Vista problem. I use a normal user account, not an admin account for my daily use. Thus I do not have write permissions for the A_Programfiles folder.

_________________
Ciao
toralf

I like "Library" and I like "Include". But since the majority want "Lib" (and there doesn't appear to be any vote fraud), and since the user library is something of a power-user feature, we'll go with Lib as the default name. In a future version, the names and locations will be customizable.

Edit: Here's the vote as of the time of this post:

That's fair

I've updated the following file in case anyone wishes to try it out prior to release (in a day or two): http://www.autohotkey.com/misc/AutoHotk ... llback.exe

The directories are:
UserLib: %A_MyDocuments%\AutoHotkey\Lib
StdLib: (path of AutoHotkey.exe)\Lib

Will there be any built-in variables for these paths ?