Page 15 of 19

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 04 Nov 2019, 23:31
by joedf
:thumbup: Sounds good

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 07 Nov 2019, 20:01
by TAC109
New version available -

Beta_8, 8 November 2019 -
  • GUI is now resizable (thanks @joedf).
  • Changed GUI 'Compress' to DDL.
  • Fixed GUI 'Default destination'.
  • Improved CLI parameter error messages.
  • Implemented PostExec directive 'when' parameter.
  • Added 'BinMod.ahk', a simple fast binary editor which can be called by 'PostExec'.
  • Compiler Directives documentation is now in draft AutoHotkey.chm help file (included).
See this post for download details.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 07 Nov 2019, 20:08
by TAC109
@lexikos
I've changed my Git GUI to GitHub Desktop and can now push directly to AutoHotkey/Ahk2Exe, and the UTF-8 BOM issue has resolved itself. :eh:

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 08 Nov 2019, 00:52
by JoeWinograd
Hi TAC,
Just tested Beta_8 on W7/64-bit via both CLI and GUI. Directives tested were many of the SetProp ones, UpdateManifest (to replace name and version), AddResource (to replace the 160, 206, 207, 208 icons), and PostExec with BinMod (to replace the RCData entry). Everything worked perfectly with both the CLI and the GUI!

Regarding the GUI, the Source folder is sticky now (bug fixed) and the DDL for compression works well (nice UI improvement)...tested with all three DDL choices. One suggestion (purely cosmetic) is that MPRESS is all upper case, as far as I know (your DDL shows MPress).

Great job! Thanks very much for your efforts. Regards, Joe

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 08 Nov 2019, 02:26
by TAC109
@JoeWinograd
Thanks for the feedback. :thumbup:

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 08 Nov 2019, 09:23
by joedf
Great stuff! :)
Yes, GItHub Desktop does pre-setup preprocessing magic for the user, or rather "automagically" processes the files ;)
Mainly, newline chars and any text encodings.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 18 Nov 2019, 00:33
by AHKStudent
Is it possible to add a feature that sets UIaccess in the manifest to true?

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 18 Nov 2019, 01:08
by TAC109
Yes, this would be possible. I’ll look into it.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 18 Nov 2019, 08:01
by AHKStudent
TAC109 wrote:
18 Nov 2019, 01:08
Yes, this would be possible. I’ll look into it.
The reason the method lexikos posted (part of his EnableUIAccess script) cannot be used is because if you exe is in mpress it wont be able to change the manifest

Code: Select all

EnableUIAccess_SetManifest("file")

EnableUIAccess_SetManifest(file)
{
    xml := ComObjCreate("Msxml2.DOMDocument")
    xml.async := false
    xml.setProperty("SelectionLanguage", "XPath")
    xml.setProperty("SelectionNamespaces"
        , "xmlns:v1='urn:schemas-microsoft-com:asm.v1' "
        . "xmlns:v3='urn:schemas-microsoft-com:asm.v3'")
    if !xml.load("res://" file "/#24/#1") ; Load current manifest
        throw
    
    node := xml.selectSingleNode("/v1:assembly/v3:trustInfo/v3:security"
                    . "/v3:requestedPrivileges/v3:requestedExecutionLevel")
    if !node ; Not AutoHotkey v1.1?
        throw
    
    node.setAttribute("uiAccess", "true")
    xml := RTrim(xml.xml, "`r`n")
    
    VarSetCapacity(data, data_size := StrPut(xml, "utf-8") - 1)
    StrPut(xml, &data, "utf-8")
    
    if !(hupd := DllCall("BeginUpdateResource", "str", file, "int", false))
        throw
    r := DllCall("UpdateResource", "ptr", hupd, "ptr", 24, "ptr", 1
                    , "ushort", 1033, "ptr", &data, "uint", data_size)
    if !DllCall("EndUpdateResource", "ptr", hupd, "int", !r) && r
        throw
}

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 19 Nov 2019, 18:09
by TAC109
New version available -

Beta_9, 20 November 2019 -
  • UpdateManifest directive now supports 'highestAvailable' execution level, and setting UIAccess=true.
  • Shows warning message if MPRESS/UPX requested but not found when compiling.
See this post for download details.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 19 Nov 2019, 19:03
by JoeWinograd
Hi TAC109 and AHKStudent (and anyone else who wants to jump in),

I was not familiar with uiAccess in the manifest until you folks just started discussing it. I see that both my AHK-compiled EXEs and my installer EXEs (via NSIS) have uiAccess="false" in the manifest. Please explain what that means in the context of EXEs created from AHK compiles and installers created with those EXEs...and why it would be better to have uiAccess="true". I spent some time Googling to try to figure it out with less than satisfying results. Thanks much, Joe

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 19 Nov 2019, 20:32
by TAC109
@JoeWinograd
I don't know much about UIAccess myself, but there is an AutoHotkey installation option that references it. This is documented here. It seems to be a quite specialised option.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 19 Nov 2019, 23:30
by JoeWinograd
Thanks for the link...I'll give it a read.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 20 Nov 2019, 12:45
by ahk7
@tag109
just me wrote:I wish to have a CLI switch to show the compiler GUI even though other command-line parameters are passed.
I just remembered a "/forcegui" flag I added - see https://www.autohotkey.com/boards/viewtopic.php?f=13&t=796&p=6134
I've long since removed the repo from GH but if you wish I can prepare a diff if you want to check / add it

ahk2exe ... /forcegui 1

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 20 Nov 2019, 16:11
by TAC109
@ahk7
Thisr proposal was mentioned 6 years ago but was not taken up or pursued further at that time. Thus, I don’t see a need for this now.
Cheers

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 20 Nov 2019, 22:00
by joedf
@ahk7
If you think it's worth it or not too much effort, make a pull request and I'll review it :+1:

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 20 Nov 2019, 22:59
by TAC109
@joedf
The original request was by @just me and he hasn’t raised it again. Many CLI parameters don’t have a direct equivalent in the GUI so this could be a problem e.g. /ahk and /cp. Others may translate badly e.g. /bin where the bin file is nonstandard or in an unusual location. The script may be using Compiler Directives which override the parameters, so what would be shown in the GUI may bear no relation to what actually happens during the compilation process.

Surely if you want to see what parameters you’re using, just look at them??

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 21 Nov 2019, 01:36
by joedf
¯\_(ツ)_/¯
I agree, but I just thought to force-display the GUI wouldn't be a big issue.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 21 Nov 2019, 03:46
by Drugwash
TAC109 wrote:
20 Nov 2019, 22:59
what would be shown in the GUI may bear no relation to what actually happens during the compilation process.
That's why the GUI should be revisited and all possible options added there. A button switching between Novice and Expert modes, a quick analysis of the selected script looking for Directives, and a statusbar message hinting/asking to switch to Expert mode when necessary, could be the way to level between command line parameters, directives and GUI options.

Re: Upcoming Ahk2Exe Changes (2019)

Posted: 21 Nov 2019, 11:51
by joedf
I'm not sure the gui needs to change much :/
Adding more things would clutter it and can be handled very easily and cleanly with the directives.
Removing anything would be make it very bare and limited.
Perhaps, a switch button for expert vs basic could be a plausible solution. However, I'm not convinced yet until see some concepts UI for both. :think: