Upcoming Ahk2Exe changes

[jiyongred]

@fincs

I really wanted .ico resource support in this preview, so I added it and submitted a pull request. https://github.com/fincs/Ahk2Exe/pull/42

There are a lot of firsts for me here (this post, a pull request on open source, etc) so please feel free to point out ways it could be done better or if this approach is completely wrong. I'm willing to learn.

Jiyongred

[lexikos]

Hi Jiyongred, welcome to the forums and thanks for the contribution. Looks like fincs has merged it already.

[Nextron]

So now AHK 1.1.23 supports handles for image commands, how would that work with compiled scripts with included resources?

[lexikos]

The same way as before, except that once you have loaded the resource and got a bitmap/icon handle, using it is easier.

[Nextron]

I was hoping for an actual example (with might be useful for others too, because in this thread I can't find one). What I found in other threads was setting a handle to an actual file and using sendmessage to a controls hWnd to update an image. In this case, it wouldn't concern a file, I wouldn't know the hWnd for a SplashImage and settings it afterwards would mean wrong window dimensions.

[Taurus]

Hi,

I have a problem with this:

Code: Select all

;@Ahk2Exe-AddResource lib\lib_add.exe	

BinRun("lib_add.exe",,, 0, A_ScriptFullPath) ; from ahk h

It's not working. Is there another way to run an exe from resource? Maybe something like RunWait, res:\lib_add.exe?

Would be very great, if we can use resources like files on a disk. That would make things much easier.

[BGM]

Yay! I was just talking to GeekDude about this! Now I won't have to use Resource Hacker anymore!

[Daniel Beardsmore]

I'm just throwing this out there to gauge opinion, as I'm not wholly certain of its merits yet.

I'm contemplating whether it would make sense to indicate the target detail.

;@Ahk2Exe-Base base-name
;@Ahk2Exe-OutputDir target-dir

Where the output directory is relative to the script.

This way, you could have:

My Project 32-bit.ahk :=

Code: Select all

;@Ahk2Exe-Base Unicode 32-bit.bin
;@Ahk2Exe-OutputDir My Project 32-bit
#Include "Main.ahk"

My Project 64-bit.ahk :=

Code: Select all

;@Ahk2Exe-Base Unicode 64-bit.bin
;@Ahk2Exe-OutputDir My Project 64-bit
#Include "Main.ahk"

The idea is that you could simply right-click each of the "My Project*.ahk" files and click Compile, to directly create 32-bit and 64-bit builds.

I don't know yet whether I'm going to use separate builds. My program is a wrapper around 7-Zip, and the only 32-bit/64-bit concern that I have is the need to read from HKEY_LOCAL_MACHINE\SOFTWARE\7-Zip in the native architecture view (assuming that the correct version of 7-Zip is installed), and I should be able to do this with RegView from a single 32-bit build. Even so, it would be nice to be able to assert to the compiler that, even though I normally run in 64-bit Unicode, that the single build is to be 32-bit Unicode for use on 32-bit PCs.

The alternative is to write a separate script that invokes the compiler, but what good is right-click → Compile if you're trapped with whatever settings you chose during installation?

[lexikos]

I can see where that might be useful.

I think that "Bin" would be more intuitive than "Base". Aside from the filename extension, we already use "bin" for the command-line switch.

What if the compiled file should be named differently than the main source file?

Perhaps it would make sense to allow specifying defaults for the command line switches within the script.

/out could allow a directory (and just append the name automatically), but if the directory doesn't exist, it would be necessary to create the directory manually or pass "target-dir\\" (otherwise the slash has the effect of escaping the quote mark).

It would also be useful for the /bin switch to take a bin file from the Compiler directory if it wasn't found in the working directory.

[joedf]

I think ill implement this.
Btw, shouldn't it be "target-dir\^" on windows? :0

[lexikos]

No, that is neither the correct escape character nor the correct place to put it. Escaping the quote mark is exactly what we don't want. It's easily tested by running a script with ListVars from another script.

[Daniel Beardsmore]

Another thing I noticed — there are no constants in AutoHotkey. This isn't unique to AHK — they're also missing from JavaScript and CSS. Constants have that nice semantic that the reader knows that the value specified will not change, cannot change, and is not intended to change. It also prevents accidental overwrite.

It's always a nuisance when you have to define the same details in numerous places, such as the compiler directives, script, readme, installer script and website.

Personally I would put most of the @Ahk2Exe-Set… details in constants.

Like:

define k_APPNAME "7-ade"

;@Ahk2Exe-SetName @{k_APPNAME}
;@Ahk2Exe-SetOrigFilename @{k_APPNAME}.exe

…

Gui, Show, Center, % k_APPNAME

[TAC109]

Any chance that preview2a will be incorporated into the main AHK download anytime soon?

This enhancement has been around for about 2.5 years now, and fincs doesn't seem to be around anymore to complete the implementation.

[joedf]

No, that is neither the correct escape character nor the correct place to put it. Escaping the quote mark is exactly what we don't want. It's easily tested by running a script with ListVars from another script.

Oh wow haha sorry! please excuse me, I was half asleep when I posted that. What i meant was ^"target-dir\^".
Now that I am myself why is it not simply "target-dir\" instead of "target-dir\\"?

[...]define k_APPNAME "7-ade"[...]

That looks like a c-style definition which is usually more on the compiler side than it is on the "script" part.
I imagine ahk2exe could have something like ;@Ahk2Exe-Define MY_CONSTANT "some text and numbers. 1234567890".

Any chance that preview2a will be incorporated into the main AHK download anytime soon?
This enhancement has been around for about 2.5 years now, and fincs doesn't seem to be around anymore to complete the implementation.

Yes, a long hiatus I must say. However, he has given us his notice. Sadly, this can happen quite often in smaller size open source projects.

[Daniel Beardsmore]

[...]define k_APPNAME "7-ade"[...]

That looks like a c-style definition which is usually more on the compiler side than it is on the "script" part.
I imagine ahk2exe could have something like ;@Ahk2Exe-Define MY_CONSTANT "some text and numbers. 1234567890".

If you define the constants inside ahk2exe, then the script won't run. AutoHotkey must be responsible for them, otherwise the script will contain symbols that won't exist until compilation. The idea was that the constants would be shared between the compiler directives and the script, so that you don't get your .exe VERSIONINFO and program details out of sync. (Which will already happen between the program, readme, installer and website … :S )

(In the case of the likes of Inno Setup, one could actually rebuild the .iss file from this data. I've gone over to a compile.ahk script that runs ahk2exe, and I guess I could #include a common file with the version data in, and include a rebuild of the .iss file in there somewhere. But only if the version is a constant. Inno Setup is in my bad books though for ISPP being such a pig to use.)

("However, he has given us his notice." — does that not indicate an intention to resign in Canadian English? It does in Britain. That's the opposite of what his thread seems to indicate :-)

[joedf]

You a correct. However, since this topic is about Ahk2Exe I assumed you wanted ahk2exe (the compiler) to do something about this "constants" issue. Otherwise, it would be better to discuss this here: about why AutoHotkey doesn't have them.

Inno Setup is somewhat easier to use than NSIS, but can be a little bloated due to its "ease".

You're completely right, but you know what I mean. that said, if you know fincs and how it is developing open source projects he means "hiatus, hiatus, hiatus". I am guilty of this, so are many other opensource devs.

[Daniel Beardsmore]

Well, here goes nothing …

[real_Napster]

Has or will this ever become a final version?
In the actual ahk2exe that comes with latest autohotkey installer the ";@Ahk2Exe"-commands aren't working..

I replaced my ahk2exe with the preview 2a from this thread, but it would be awesome if this would work by default.

[lexikos]

Does anyone know what needs to be done before this is considered complete?

[TAC109]

No, but some comments-

I used to use this special version , but found some problems with it.

1. When compiling there were often transient file errors when trying to create the .exe. (I keep my sources in a Dropbox folder.) There errors do not occur with the standard version. (I believe that the file handling and error checking in the standard version was greatly enhanced after the fork for this version.)

2. The compiler didn't not allow 'comments' to be added to the special directives.

3. Relative paths in 'fileinstall' commands were not parsed correctly.

I later switched to using Compile_AHK_II which provides for more options such as specifying icons, etc. Compile_AHK_II is a front end to the standard compiler that also hooks into it in some way - it wouldn't work with this special compiler.