i'm interested and i think i'm not alone. Thank you so much for your (goes to all) work.
Upcoming Ahk2Exe Changes (2024)
Re: Upcoming Ahk2Exe Changes (2019)
Good to know. And you're welcome.
I'm not following that branch, didn't know. Generally I hate Github with a passion, find it completely unusable according to my own style of working, and extremely aggressive regarding logging in when cookies are always cleared in browser (keeps sending e-mails asking for that stupid verification code).
Yeah, maybe it needs some tweaking. It worked fine in Wine but in a virtual Win10 there was a blank entry at the top of the list. Noticed it too late and never got to work on the GUI afterwards (life keeps throwing lemons at me and I'm out of vodka).
Yes, in my version I had added a timer so that when user dropped the desired packer exe in the right place, the "missing" warning as well as the hint as to where to put it were immediately (in 1.5 sec) cleared, as a feedback that the user did the right thing. The official version (I know of) requires another manual cycling through packers in order to check whether the operation was succesful or not.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
The main focus of my enhancements to Ahk2Exe have been orientated to incorporating the 'Compiler Directives' enhancement that @fincs started many years ago. In addition I’ve incorporated many enhancements to the Directives; some asked for in old forum messages, some conceived by myself, and some asked for during the recent development process.
Use of Compiler Directives allows the script writer to define exactly how the script is to be compiled so that there is no need to remember details which need to be supplied to the Ahk2Exe GUI; they are already in the script.
I believe that I have covered most, if not all requests as they have related to Compiler Directives. I envision that most invocations of Ahk2Exe will be via the right-click 'Compile' context menu item. It is simple, 'right there' with the script file, and will compile the script quickly, using the details supplied in the Directives.
Use of the Ahk2Exe GUI is likely to be limited to ad hoc use, and for setting the .exe compression required. I don’t see a need for incorporating additional options which will be of limited use, into the GUI.
At this stage, I see that the current Beta_5 version is likely to be the final product, subject to any bugs found.
Use of Compiler Directives allows the script writer to define exactly how the script is to be compiled so that there is no need to remember details which need to be supplied to the Ahk2Exe GUI; they are already in the script.
I believe that I have covered most, if not all requests as they have related to Compiler Directives. I envision that most invocations of Ahk2Exe will be via the right-click 'Compile' context menu item. It is simple, 'right there' with the script file, and will compile the script quickly, using the details supplied in the Directives.
Use of the Ahk2Exe GUI is likely to be limited to ad hoc use, and for setting the .exe compression required. I don’t see a need for incorporating additional options which will be of limited use, into the GUI.
At this stage, I see that the current Beta_5 version is likely to be the final product, subject to any bugs found.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
Sure, the Directives are very useful and you did a great job implementing them. My reasoning for completing the GUI is that new users may find the Directives sometime later, and some older scripts may take some time before being modified to incorporare the Directives, so in the mean time the GUI should be as complete as possible for a quick operation. Once the (new) users find out about all possible tweaks through the GUI it will be easier for them to transition to Directives.
Some users may not even need directives if they work on a single script - simply dragging the script onto the compiler icon and having all other options already set and remembered will do the job. it all depends on habit, experience, spare time and so on. As I said before: it's best to have all the bases covered. BTW, is there any way to set the UPX compression level through directives, and does the actual compilation command take it into account? Can't remember now.
Anyway, that's just my personal opinion - it may be valid or not. It's all up to you. Good luck!
Some users may not even need directives if they work on a single script - simply dragging the script onto the compiler icon and having all other options already set and remembered will do the job. it all depends on habit, experience, spare time and so on. As I said before: it's best to have all the bases covered. BTW, is there any way to set the UPX compression level through directives, and does the actual compilation command take it into account? Can't remember now.
Anyway, that's just my personal opinion - it may be valid or not. It's all up to you. Good luck!
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
For what it's worth, I agree with Drugwash about this.My reasoning for completing the GUI is that new users may find the Directives sometime later, and some older scripts may take some time before being modified to incorporare the Directives, so in the mean time the GUI should be as complete as possible for a quick operation.
- hoppfrosch
- Posts: 443
- Joined: 07 Oct 2013, 04:05
- Location: Rhine-Maine-Area, Hesse, Germany
- Contact:
Re: Upcoming Ahk2Exe Changes (2019)
Can Ahk2Exe also be used via commandline only (without showing the GUI)?
This would be very helpful here to implement a fully automated deployment chain ...
This would be very helpful here to implement a fully automated deployment chain ...
Re: Upcoming Ahk2Exe Changes (2019)
Yes, one just has to specify one or more command line parameters: /in,/out,/icon,/pass,/bin,/mpress or /compress,/cp.
Actually /pass is invalid for this compiler version. And /in is mandatory since it's the path to the ahk script being compiled.
If /icon, /bin or /mpress | /compress are missing, their corresponding LastUsed values will be used.
Actually /pass is invalid for this compiler version. And /in is mandatory since it's the path to the ahk script being compiled.
If /icon, /bin or /mpress | /compress are missing, their corresponding LastUsed values will be used.
Part of my AHK work can be found here.
- hoppfrosch
- Posts: 443
- Joined: 07 Oct 2013, 04:05
- Location: Rhine-Maine-Area, Hesse, Germany
- Contact:
Re: Upcoming Ahk2Exe Changes (2019)
@TAC109
Great!
Let me know when you're ready for a merge with the official repo, so we can start the process of shipping it with the installer.
Great!
Let me know when you're ready for a merge with the official repo, so we can start the process of shipping it with the installer.
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Upcoming Ahk2Exe Changes (2019)
@joedf
Do I have write access to AutoHotkey/Ahk2Exe on GitHub?
Do I have write access to AutoHotkey/Ahk2Exe on GitHub?
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
@Drugwash @joedf (and all the other responders)
Thanks for all your input to the development process! You’ll realise that most of your requests have been included in the current beta product, and I hope that I’ve been able to clearly explain why some requests have not made the cut.
I’m looking forward to seeing these enhancements appearing in the official Ahk2Exe included with the AutoHotkey download.
Cheers!
Thanks for all your input to the development process! You’ll realise that most of your requests have been included in the current beta product, and I hope that I’ve been able to clearly explain why some requests have not made the cut.
I’m looking forward to seeing these enhancements appearing in the official Ahk2Exe included with the AutoHotkey download.
Cheers!
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
Yes, full access to everything on AutoHotkey/
That's a good-to-go sign?
That's a good-to-go sign?
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
- hoppfrosch
- Posts: 443
- Joined: 07 Oct 2013, 04:05
- Location: Rhine-Maine-Area, Hesse, Germany
- Contact:
Using AutoHotkey from local directory
Hi,
running Ahk2Exe.exe (1.1.30.03_Beta_5) on my project, I get the following error:
I've got following file/folder structure
Ahk2Exe is executed via the following commandline:
Working directory is c:\project\src. Running this commandline results in the warning above.
I need this structure, because I have to use another AHK version within this project as I usually use.
What happens here? Is Autohotkey.exe needed unless I have specified AutoHotkeySC.bin explicitly? Is there an explicit way to specify AutoHotkey.exe to be used?
Using the Ahk2Exe-Gui: how can I select a different AutoHotkeySC.bin (beside the ones defined in C:\somewhere)?
BTW: MyScript.exe is available after the compilation - but it seems that the used libs and the specified icon are not included
running Ahk2Exe.exe (1.1.30.03_Beta_5) on my project, I get the following error:
Code: Select all
---------------------------
Ahk2Exe Warning
---------------------------
Warning: AutoHotkey.exe could not be located!
Auto-includes from Function Libraries, and 'Obey' directives will not be processed.
I've got following file/folder structure
Code: Select all
|--\somewhere
|--Autohotkey.exe <--- Main AutoHotkey executable
|--\project
|--\bin
|--Ahk2Exe.exe
|--AutoHotkey.exe <--- This should be used with Ahk2Exe.exe
|--AutoHotkeySC.bin <--- This should be used with Ahk2Exe.exe
|--\src
|--MyScript.ahk <--- This should be compiled via Ahk2Exe
|--MyScript.ico <--- This should be used with Ahk2Exe.exe
|--\lib
|--lib1.ahk <--- This is referenced from MyScript.ahk via #Include
|--libn.ahk <--- This is referenced from MyScript.ahk via #Include
Ahk2Exe is executed via the following commandline:
Code: Select all
C:\project\bin\Ahk2Exe.exe /bin C:\project\bin\AutoHotkeySC.bin /in c:\project\src\MyScript.ahk /out MyScript.exe /icon c:\project\src\MyScript.ico
I need this structure, because I have to use another AHK version within this project as I usually use.
What happens here? Is Autohotkey.exe needed unless I have specified AutoHotkeySC.bin explicitly? Is there an explicit way to specify AutoHotkey.exe to be used?
Using the Ahk2Exe-Gui: how can I select a different AutoHotkeySC.bin (beside the ones defined in C:\somewhere)?
BTW: MyScript.exe is available after the compilation - but it seems that the used libs and the specified icon are not included
Re: Upcoming Ahk2Exe Changes (2019)
Currently this script does not have an option to select a particular Autohotkey.exe for its internal operations; it assumes AHK is installed in the default path and that Ahk2Exe resides in the Compiler subfolder in that path. Your setup is different, that is why you get that warning and those issues.
Quite a few changes would be required in Ahk2Exe in order to accomodate non-standard setups. I have asked for custom bin selection in the GUI some time ago but it didn't make it. In the mean time you can use the in-script directives to select custom binaries, custom icon and whatever else possible. An Autohotkey.exe in the default path would be necessary for certain directives (such as Obey) and for the auto-includes, as mentioned in the warning.
Quite a few changes would be required in Ahk2Exe in order to accomodate non-standard setups. I have asked for custom bin selection in the GUI some time ago but it didn't make it. In the mean time you can use the in-script directives to select custom binaries, custom icon and whatever else possible. An Autohotkey.exe in the default path would be necessary for certain directives (such as Obey) and for the auto-includes, as mentioned in the warning.
Part of my AHK work can be found here.
- hoppfrosch
- Posts: 443
- Joined: 07 Oct 2013, 04:05
- Location: Rhine-Maine-Area, Hesse, Germany
- Contact:
Re: Upcoming Ahk2Exe Changes (2019)
Thank you for your fast response - I haven't used AHK2EXE before, so the directives have not been in my focus yet. I will give it a try ....
Re: Upcoming Ahk2Exe Changes (2019)
A simple check for the working directory to search to use the autohotkey.exe there first, then if none is found proceed to use the install path?
EDIT: in ScriptParse.ahk around line 174:
For now you could add it in a parent folder? Not sure why this is like this... and seems non-standard. I would a add a "Smart" search/find function to look for autohotkey.exe ...
Look recursively in to child folders up to 3 deep, parent up to 2 out maybe?, check script & working dir first, then install path?
EDIT2: ahh yes, parent folder because it assumes the normal installation folder structure. where ahk2exe is normally in a subfolder called Ahk2Exe/ ...
EDIT: in ScriptParse.ahk around line 174:
Code: Select all
global AhkPath:=A_IsCompiled ? A_ScriptDir "\..\AutoHotkey.exe" : A_AhkPath
AhkPath := FileExist(AhkPath) ? AhkPath : A_AhkPath
IfNotExist, %AhkPath%
{
Util_Error("Warning: AutoHotkey.exe could not be located!`n`nAuto-include"
. "s from Function Libraries, and 'Obey' directives will not be processed.",0)
break ; Don't bother with auto-includes because the file does not exist
}
Look recursively in to child folders up to 3 deep, parent up to 2 out maybe?, check script & working dir first, then install path?
EDIT2: ahh yes, parent folder because it assumes the normal installation folder structure. where ahk2exe is normally in a subfolder called Ahk2Exe/ ...
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Upcoming Ahk2Exe Changes (2019)
It may be easier if there was a manual option to select the path to a custom Autohotkey.exe to use with the current (and future) script(s).
For all we know, the user may install/deploy multiple (un)official AHK packages anywhere on their system, and they may need any of them at any time. Any fixed search structure we may devise would be unsatisfactory although incidentally it may match.
For all we know, the user may install/deploy multiple (un)official AHK packages anywhere on their system, and they may need any of them at any time. Any fixed search structure we may devise would be unsatisfactory although incidentally it may match.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
Interesting, I like the idea of specifying. I think this would be better suited as a directive and/or command-line option of some kind.
We don't want to add too much to the GUI. It has to remains relatively simple for newer users, even I was confused, at first, as to what compiling meant for ahk and what the options were...
We don't want to add too much to the GUI. It has to remains relatively simple for newer users, even I was confused, at first, as to what compiling meant for ahk and what the options were...
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Upcoming Ahk2Exe Changes (2019)
@hoppfrosch
Ahk2exe should be installed as stated in the first post of this topic, i.e. the Compiler sub-directory under where AutoHotkey has been installed. (Usually C:\Program Files\AutoHotkey\Compiler\.).
Additionally, if not found there, Ahk2Exe looks for an installed AutoHotkey.exe (by using A_AhkPath). This is primarily to allow testing of Ahk2Exe during development.
So, failing an installed copy of AutoHotkey, you should follow the installation requirement and place Ahk2Exe in a subdirectory of the appropriate AutoHotkey.exe you wish to be used. (You can have multiple copies of Ahk2Exe, one for each AutoHotkey.exe to be used, if this is necessary.)
Ahk2exe should be installed as stated in the first post of this topic, i.e. the Compiler sub-directory under where AutoHotkey has been installed. (Usually C:\Program Files\AutoHotkey\Compiler\.).
Additionally, if not found there, Ahk2Exe looks for an installed AutoHotkey.exe (by using A_AhkPath). This is primarily to allow testing of Ahk2Exe during development.
So, failing an installed copy of AutoHotkey, you should follow the installation requirement and place Ahk2Exe in a subdirectory of the appropriate AutoHotkey.exe you wish to be used. (You can have multiple copies of Ahk2Exe, one for each AutoHotkey.exe to be used, if this is necessary.)
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Return to “Scripts and Functions (v1)”
Who is online
Users browsing this forum: Wala27 and 70 guests