Au3stripper issue

[Jos]

Thats not the log but the generated stripped script, which by the way no errors has when I perform an Ctrl+F5 (au3check)  

Edited June 13, 2023 by Jos

[Shark007]

where would I look for the log?

[Jos]

%localappdata%/autoit v3/scite/au3stripper 

... but more importantly: There are no errors in the previous attached stripper output, so what exactly is the problem now?

Edited June 13, 2023 by Jos

[Shark007]

The problem is that I get 6 errors from au3stripper so nothing gets stripped and the compiler reverts to using the original script.

Log attached - it exeeded allowable size so I had to compress it.

Au3Stripper.7z

Edited June 13, 2023 by Shark007

[Shark007]

also realize, I am using a simple script that reproduces the errors I am dealing with instead of the 4400+ lines of my originating script that I'd like to strip.

[Jos]

Ok, so it is not the issue with the variable anymore but rather the feature of autoit3wrapper which will restore the original script in case of errors/warnings? This can be overridden to force it to use the stripped version anyway!

#AutoIt3Wrapper_Au3Stripper_OnError=f

 

Edited June 13, 2023 by Jos

[Shark007]

continue ... please share how to allow stripping even though there are errors.

The errors do not affect functionality, only deprive my of using au3stripper.

Edited June 13, 2023 by Shark007

[Jos]

I had to look it up aswell in the helpfile and edited my post...  

So

#AutoIt3Wrapper_Au3stripper_OnError=             ;(C/S/ForceUse) Continue/Stop on Errors/Continue using stripped source in Exe (Default=C)

f or forceuse will tell autoit3wrapper to use it anyways in case of errors/warnings.

I have done this to get rid of the people reporting that a script didn't work anymore after simply ignoring the shit-load of warnings/errors they got from au3stripper.

Edited June 13, 2023 by Jos

[Shark007]

I understand your reasoning. I suppressed the errors as mentioned.

I have tested the mouse UDF functionality and everything seems to be OK (at this moment)

@Jos , your time and knowledge are appreciated.

Edited June 13, 2023 by Shark007

[Shark007]

I ended up giving up on using Au3Stripper because of the incompatibility with MouseOnEvent.au3

Fixing this is beyond my capabilities and having the functionality provided by MouseOnEvent.au3 is more important to me.

[TimRude]

@Jos

I see the same 6 errors reported when the latest beta of Au3Stripper (23.402.1150.1) is run on either the MouseOnEvent.au3 file itself or if it's an include in another script.

But all of the instances of the '$aRet...' lines are still in the stripped filed, so you've definitely fixed that.

Your help text for Au3Stripper says that a warning usually occurs if "a function takes a literal string parameter defining a function or variable.  In this case the resulting string might not be able to be correctly linked to the correct variable or function name during the process." And it specifically names the Call() function as one of the ones it occurs with.

So since the 6 Call() statements that are getting flagged are referencing a variable function name whose value isn't known until runtime, it appears that these 6 warnings are safe to ignore in this file.

Since these warnings occur only within the two functions __MouseSetOnEvent_MainHandler and __MouseSetOnEvent_WM_CALL, I thought that I could just add

#Au3Stripper_Ignore_Errors_in_Funcs=__MouseSetOnEvent_MainHandler,__MouseSetOnEvent_WM_CALL

to the directives to have errors in just these two functions ignored, rather than using the more comprehensive

#AutoIt3Wrapper_Au3Stripper_OnError=f

directive which would seem to apply globally to any error found while compiling the entire application. However, the  #Au3Stripper_Ignore_Errors_in_Funcs directive made no difference. The errors were still flagged and still prevented AutoIt3Wrapper from using the stripped version of the file.

Am I misunderstanding the purpose or syntax of the #Au3Stripper_Ignore_Errors_in_Funcs directive?

EDIT: I then went and tried wrapping each of the 6 problematic Call(...) lines with #Au3Stripper_Off and #Au3Stripper_On directives.  Like this:

#Au3Stripper_Off
$iRet = Call($a__MSOE_Events[$i][1], $iEvent, $a__MSOE_Events[$i][4])
#Au3Stripper_On

If @error = 0xDEAD And @extended = 0xBEEF Then
    #Au3Stripper_Off
    $iRet = Call($a__MSOE_Events[$i][1], $iEvent)
    #Au3Stripper_On

    If @error = 0xDEAD And @extended = 0xBEEF Then
        #Au3Stripper_Off
        $iRet = Call($a__MSOE_Events[$i][1])
        #Au3Stripper_On
    EndIf
EndIf

...

#Au3Stripper_Off
Call($sFuncName, $iEvent, $vFuncParam)
#Au3Stripper_On

If @error = 0xDEAD And @extended = 0xBEEF Then
    #Au3Stripper_Off
    Call($sFuncName, $iEvent)
    #Au3Stripper_On

    If @error = 0xDEAD And @extended = 0xBEEF Then
        #Au3Stripper_Off
        Call($sFuncName)
        #Au3Stripper_On
    EndIf
EndIf

That worked. No more errors thrown by those 6 lines, and no need to turn off global error checking while stripping.

Edited June 22, 2023 by TimRude
Tried another method

[Shark007]

30 minutes ago, TimRude said:

That worked. No more errors thrown by those 6 lines, and no need to turn off global error checking while stripping.

I tried that also but after compiling, the mouse functions no longer work.

Edited June 22, 2023 by Shark007

[TimRude]

2 hours ago, Shark007 said:

I tried that also but after compiling, the mouse functions no longer work.

After further testing, I agree. I'm seeing the same thing. If Au3Stripper processes the MouseOnEvent.au3 file and compiles it into the .exe, the mouse trapping no longer works.

What does work is not letting Au3Stripper strip down the script files. Or let it try and then let the default behavior take effect (where Au3Stripper throws those 6 errors up about the Call() statements, and so the compiler reverts back to using the unstripped script files.) In that case the (obese) compiled exe does work as expected.

Edited June 23, 2023 by TimRude

[TimRude]

I've figured it out. It's not a problem with Au3Stripper, and it's not a problem with the MouseOnEvent.au3 file being run through Au3Stripper. It's simpler and much more basic than that.

In your primary script where you're creating the event handler function(s), you have to let Au3Stripper know that these functions are being used. Since these functions are never called by name anywhere in the code, Au3Stripper thinks they're unused and strips them out of your script. It doesn't recognize the string parameter with the function name that you pass to the _MouseSetOnEvent function as being a reference to your event handler function. It just thinks it's a random string.

To fix this, you have to add a directive to tell Au3Stripper to not strip out these functions you've created. So if, for example, you created an event handler function named "MousePrimaryDown_Event", you'd need to include this in the script in which that function resides:

#Au3Stripper_Ignore_Funcs=MousePrimaryDown_Event

Once you do that, you can run it through Au3Stripper and compile a nice smaller executable that actually works. 

And don't forget to either include

#AutoIt3Wrapper_Au3Stripper_OnError=f

as Jos recommended so the 6 Call() lines don't block Au3Stripper from completing successfully, or else bracket each of those Call() lines in the MouseOnEvent.au3 file with #Au3Stripper_Off and #Au3Stripper_On as I suggested earlier.

Edited June 23, 2023 by TimRude

[Shark007]

IMHO, @Jos should add a directive to AU3Stripper where we could just tell it to ignore an entire UDF. I am using 9 of the functions offered  by MouseOnEvent.au3

I've since moved on from this issue by moving the mouse functionality into its own separately compiled script that I call and use from within my main script.

[Jos]

Do you mean the whole file with your entire udf statement as an udf can be ignored already!

Either way, that is already possible with the current available directives but it likely will not work since when you ignore an whole file the au3stripper program doesn't check for the funcs used in it so I bet there will be funcs stripped required by that file!

It really isn't that difficult: you get warnings for a reason, so simply don't use au3stripper when you script isn't strippable. 😉

[TimRude]

@Jos You're right that excluding the entire UDF from Au3Stripper while stripping the rest of the script won't work. I tried it and there were a bunch of missing constants and things from the other include files that the UDF code needed.

And I have to say that the error messages from Au3Stripper about the Call() statements were exactly correct. It's warning that it can't determine what function those Call() statements are pointing to, so there's a good chance that target function might get stripped out. And that was exactly what was happening. Once I figured that out and took steps to protect the target function from being stripped, it all works fine.

It's impressive how well Au3Stripper works, when you actually pay attention to what it tries to tell you. Thanks for your hard work on it.