AutoIt3Wrapper Resource Update

[Jos]

I guess i need to use Byte instead of wchar to work without null terminated strings.

Something link this:

Local $p_VS_String = DllStructCreate("byte   szKey[16]" )
DllStructSetData($p_VS_String,"szKey",StringToBinary("12345678",2))
ConsoleWrite('szKey = ' & BinaryToString(DllStructGetData($p_VS_String,"szKey"),2) & @crlf)

Edited January 31, 2008 by Jos

[The Kandie Man]

This looks like the winner:

http://msdn2.microsoft.com/en-us/library/m...001(VS.85).aspx

Notice anything similar between that structure and the raw binary data for the version resource? ;-)

Not sure if you already had this, but if you didn't, it will definitely help.

EDIT:

I see you already had this. But I had to figure out where you were getting those struct values from. It is posted here now for easy reference.

- The Kandie Man ;-)

Edited January 31, 2008 by The Kandie Man

[Jos]

I have all needed structures defined and got them all from MSDN. I am able to map it against the file generated by RC.exe.

Its now just a matter of filling them up in the right sequence and ensure the padding is done correctly.

[Valik]

The length is truncated when it is read. That's retarded, I don't know why the code doesn't allocate a larger block than the user requested so that it can do house-keeping stuff like this.

Jos, you shouldn't need to use byte unless you plan to read the string using DllStructGetData(). The truncation happens in DllStructGetData() so the raw data itself is safe.

The strings should be NULL terminated anyway.

[Jos]

I got the RT_VERSION structure building Function working in native AUtoIt3 code and am going through some testing right now. (Its really is lots of fun concatenating Structs together in a complex setup as RT_VERSION). This means we don't need any external software anymore top update the output program resources.

Just wondering if anybody other then TheKandieMan tested the TEST version ?

Edited February 1, 2008 by Jos

[The Kandie Man]

I have tested it a couple times. I don't get errors when I don't update resources, however, I have been getting the same error when I try to update a resource.

Msgbox(16,"Error","_WinAPI_CloseHandle: The handle is invalid.")

I am not sure where this error is occuring because I have been unable to run the script in SciTE with the latest beta verion of AutoIt. Ver v3.2.11.0 (beta).

I am assuming this is being generated by the _WinAPI_GetLastErrorMessage() function. I believe you might be trying to close an invalid file handle with _WinAPI_CloseHandle()

- The Kandie Man ;-)

[Jos]

I have tested it a couple times. I don't get errors when I don't update resources, however, I have been getting the same error when I try to update a resource.

Msgbox(16,"Error","_WinAPI_CloseHandle: The handle is invalid.")

I am not sure where this error is occuring because I have been unable to run the script in SciTE with the latest beta verion of AutoIt. Ver v3.2.11.0 (beta).

I am assuming this is being generated by the _WinAPI_GetLastErrorMessage() function. I believe you might be trying to close an invalid file handle with _WinAPI_CloseHandle()

- The Kandie Man ;-)

This means that the RES file isn't created/available. I am added proper error checking for that too ...

Strange tho that you get this error when you update anything in the Version Struct, I am pretty sure I tried that before posting.

Anyways, I will soon post a new TEST version with the modifications mentioned..

Thanks for testing

EDIT: This is probably when you use a different Language ? encountered that one and fixed it .

Edited February 1, 2008 by Jos

[The Kandie Man]

This means that the RES file isn't created/available. I am added proper error checking for that too ...

Strange tho that you get this error when you update anything in the Version Struct, I am pretty sure I tried that before posting.

Anyways, I will soon post a new TEST version with the modifications mentioned..

Thanks for testing

EDIT: This is probably when you use a different Language ? encountered that one and fixed it .

Yes, this is when I attempt to change the language.

- The Kandie Man ;-)

[Jos]

Just uploaded a Beta version of AutoIt3Wrapper & AutoIt3Wrapper_GUI modified to do all ResourceUpdates with internal code:

http://www.autoitscript.com/autoit3/scite/..._SciTE4AutoIt3/

Curious to hear if all is working as needed on both x32 as x64 systems

Edited February 1, 2008 by Jos

[The Kandie Man]

Jos, the above link is broken.

For those of you wanting to try the beta out, this is where the link was supposed to go:

http://www.autoitscript.com/autoit3/scite/..._SciTE4AutoIt3/

- The Kandie Man ;-)

Edited February 1, 2008 by The Kandie Man

[The Kandie Man]

Bugs:

1. #AutoIt3Wrapper_Version=Beta doesn't work correctly. It still compiles with the production version if I press F5 and the directive is present in the script.

2. Another bug is that the wrapper seems to default to compiling to a 64bit exe when the #AutoIt3Wrapper_UseX64 directive isn't present and it is running on a 64bit OS. This is not right because the wrapper GUI clearly states when the #AutoIt3Wrapper_UseX64 is omitted that it will not be compiled to a 64bit version. If I create a new script, add some code, and then open the wrapper GUI, I will see that "Use X64 version of AutoIt3/Aut2Exe" is unchecked. I then go to compile it only to find that the wrapper saw I had a 64bit OS, didn't see any "#AutoIt3Wrapper_UseX64" directive, and then it proceeded to compile it to a 64bit exe by default. It should not compile to a x64 bit exe by default when on a x64bit OS when the "#AutoIt3Wrapper_UseX64" directive isn't present because the wrapper GUI clearly states that it won't compile to a 64bit exe.

I hope that helps.

- The Kandie Man ;-)

Edited February 1, 2008 by The Kandie Man

[Jos]

1. #AutoIt3Wrapper_Version=Beta doesn't work correctly. It still compiles with the production version if I press F5 and the directive is present in the script.

This is a dilemma. This is what I put in my script when I created it because my approach was when /prod or /Beta is specified on the command line it will take priority over the directive.

Case $i_Rec_Param = "#AutoIt3Wrapper_Version"
    ; Only use the compiler directive when the /prod or /beta is missing from the commandline

2. Another bug is that the wrapper seems to default to compiling to a 64bit exe when the #AutoIt3Wrapper_UseX64 directive isn't present and it is running on a 64bit OS. This is not right because the wrapper GUI clearly states when the #AutoIt3Wrapper_UseX64 is omitted that it will not be compiled to a 64bit version. If I create a new script, add some code, and then open the wrapper GUI, I will see that "Use X64 version of AutoIt3/Aut2Exe" is unchecked. I then go to compile it only to find that the wrapper saw I had a 64bit OS, didn't see any "#AutoIt3Wrapper_UseX64" directive, and then it proceeded to compile it to a 64bit exe by default. It should not compile to a x64 bit exe by default when on a x64bit OS when the "#AutoIt3Wrapper_UseX64" directive isn't present because the wrapper GUI clearly states that it won't compile to a 64bit exe.

Not sure why it does this other then that aut2exe_x64.exe defaults to the x64 bin, but that should be overridden.

What is the commandline show in the console when you compile (F7) the script for aut2exe:

>*** AUT2EXE: ............

This should tell me what type BIN is used.

(Have you copied the aut2exe_x64.exe from Beta into the production aut2exe directory to ensure all parameters are supported ?)

Thanks

Edited February 1, 2008 by Jos

[The Kandie Man]

Console Output For Beta Compile (my production version is older and doesn't work with the wrapper):

>Running:(3.2.11.0):D:\Program Files (x86)\AutoIt3\beta\aut2exe\aut2exe_x64.exe  /in "D:\Documents and Settings\Administrator\Desktop\TestScript.au3" /out "D:\Documents and Settings\Administrator\Desktop\TestScript.exe" /comp 2 /pack

When installing AutoIt, I checked off "Do not use native x64 bit tools". However, whenever I run or compile a script, the wrapper uses AutoIt3_x64.exe by default to run the script and it uses Aut2exe_x64.exe by default to compile the script into a 64bit executable. I want to explicitly tell it when to use the 64bit version, that is why I checked that radio button option during installation.

- The Kandie Man ;-)

Edited February 1, 2008 by The Kandie Man

[Jos]

Console Output For Beta Compile (my production version is older and doesn't work with the wrapper):

>Running:(3.2.11.0):D:\Program Files (x86)\AutoIt3\beta\aut2exe\aut2exe_x64.exe  /in "D:\Documents and Settings\Administrator\Desktop\TestScript.au3" /out "D:\Documents and Settings\Administrator\Desktop\TestScript.exe" /comp 2 /pack

When installing AutoIt, I checked off "Do not use native x64 bit tools". However, whenever I run or compile a script, the wrapper uses AutoIt3_x64.exe by default to run the script and it uses Aut2exe_x64.exe by default to compile the script into a 64bit executable. I want to explicitly tell it when to use the 64bit version, that is why I checked that radio button option during installation.

- The Kandie Man ;-)

Ok understand now. The /BIN commandline parameter is only used when you update resources thus it will use the defaults.

I need to check on what the installer does with the option you specified (wasn't aware of that option for x64). Probably need to check the registry for an entry which aut2exe to use.

[Jos]

Could you try the current one available? It will always use aut2xe.exe and will always used the /bin parameter to ensure the proper BIN usage.

I am not going to worry about using the aut2exe_x64 since it does the same thing as aut2exe.

We are just having tooooooooo much options these days

[The Kandie Man]

Could you try the current one available? It will always use aut2xe.exe and will always used the /bin parameter to ensure the proper BIN usage.

I am not going to worry about using the aut2exe_x64 since it does the same thing as aut2exe.

We are just having tooooooooo much options these days

The current wrapper, aut2exe in beta SciTE4AutoIt, autoit beta, or latest production version?

- The Kandie Man ;-)

[Jos]

The current wrapper, aut2exe in beta SciTE4AutoIt, autoit beta, or latest production version?

- The Kandie Man ;-)

The newly uploaded Beta AutoIt3Wrapper in : http://www.autoitscript.com/autoit3/scite/..._SciTE4AutoIt3/

Using the BETA aut2exe either in the BETA or Production AUT2EXE directory should do it.

Edited February 1, 2008 by Jos

[GEOSoft]

I got the RT_VERSION structure building Function working in native AUtoIt3 code and am going through some testing right now. (Its really is lots of fun concatenating Structs together in a complex setup as RT_VERSION). This means we don't need any external software anymore top update the output program resources.

Just wondering if anybody other then TheKandieMan tested the TEST version ?

Sorry Jos I haven't had the time yet. It would be really nice to see this as a stand-alone as opposed to just being part of the wrapper.

[Jos]

Sorry Jos I haven't had the time yet. It would be really nice to see this as a stand-alone as opposed to just being part of the wrapper.

The resource update is done by 3 UDF's in AutoIt3Wrapper and could easily be used standalone .... Maybe project 291 on your list ?

[The Kandie Man]

The newly uploaded Beta AutoIt3Wrapper in : http://www.autoitscript.com/autoit3/scite/..._SciTE4AutoIt3/

Using the BETA aut2exe either in the BETA or Production AUT2EXE directory should do it.

Ok, tested. The compiling now appears to work fine. However, it still uses AutoIt3_x64.exe for running. Now, if your script is simple, this isn't a big problem. It only becomes a problem if you use SQLite.dll.au3(one or two of my most recent scripts are using it). Running a script that uses this udf with a 64bit version of AutoIt will cause a fatal error because it will not be able to load the 32bit SQLite.dll.

All WinAPI functions work fine I believe(though of course I haven't tested). The reason being is that the system kernel has 32bit and 64bit versions of the WinAPI.

- The Kandie Man ;-)

Edited February 1, 2008 by The Kandie Man