cmacrun

I noticed since upgrading to 3.3.14.2 version of Autoit, that when I compile a script and specify a file version along with an icon via: #AutoIt3Wrapper_Res_Fileversion=2017.11.1.0 #AutoIt3Wrapper_Icon=C:\somelogo.ico and everything else left blank (from a gui perspective, though I generally just populate these lines in the script manually), on the compiled exe, the Description field is populated with Aut2Exe.exe instead of the actual compiled executable name. This was not the behavior we experienced in previous versions of the compiler and if I remove the fileversion line from the code, the Description is again populated with correct name. I know I can override what gets placed in the Description field of the exe via #AutoIt3Wrapper_Res_Description but his was never required in the past, and is more cumbersome to have to track. Am I the only one who sees this behavior and is it an intended change and I just overlooked it in the chg log? Thanks in advance!

Ok it appears to still fail in our lab using version 1.0 of ad.au3. I used the following credentials: un: testcrazypassword pw: password1@@@ I get the following returned from AD_Open: ExitCode=0 @Error=8 @Extended=-2147352567 (if this matters) Thanks!

Not certain on Kerberos, but the characters which I know are giving us issue, are included in the acceptable table in aforementioned kb: Only characters that are identical in ASCII and ANSI are treated correctly. These characters have the same mapping in ANSI and ASCII: !"#$%&'()*+,-./ 0123456789:;<=>? @ABCDEFGHIJKLMNO PQRSTUVWXYZ[\]^ Still working to get a test script...should have something shortly.

I can build a test script with the latest version and see what happens.

Has anyone experienced issues with _AD_Open when passing credentials, specifically a password that ends with a special characater such as @ or $? I've been using AD_Open as a means to test credentials that users are passing via gui interface. This works perfectly outside of those few folks who have a password like "mypassword@@@". Anyone willing to test this to see if they see the same issue? I must mention I am using version .41 of AD.au3 so it's possible this bug has been addressed with a more recent version and possibly already mentioned in one of the 27 pages of this post. I read through most of the pages, but didn't see anything mentioning this. Thanks for any assistance!

I know this is cold thread, but ran across it this morning while looking for something similar and it didn't look like there was a resolution. Anyway, sysinternals (cough microsoft) provides a free tool to do this: http://technet.microsoft.com/en-us/sysinternals/bb963905.aspx Possibly you can incorporate it into whatever script you're creating.

Sorry, it just occurred to me that I could easily figure that out. It returns a value of 2, same as cancel. Sorry for the waste of space...it's monday!

I have a few messages boxes come up prior to a silent install of XPSP2 that give the user the option to delay the install. Problem I see is the window close aka red X is active and can be used to close the window instead of clicking Yes/Cancel. I would either like to disable or know the return value so I can catch it if a user clicks on it. Right now if clicked it just continues on with the script..... Thanks much.

See, I knew it was just a formatting issue! Thanks Dave. I did have to mod your code due to another formatting issue, Didn't include the "" for the path info runwait requires. Final code: $VBSPath = "G:\foo\problem name.vbs" RunWait(@Comspec & ' /c cscript.exe "' & $VBSPath & '"', "",@SW_HIDE) Thanks again!

Hey guys/gals, I hope that this is an easy question and probably just a formatting issue.... I have a vbs file that is located at a location which is stored in the variable $VBSPath. I am trying to execute the vbs file within a script using cscript.exe. I found some other posts in regards to vbs files and cscript but none of them talk about having the path to the vbs file in a variable(at least that I could find). I have tried a whole slew of different combinations of the following command but I'll just include the one I have entered at the moment. RunWait(@Comspec & " /c cscript.exe " & $VBSPath, @SW_HIDE) Thanks in advance!

Ok this is strange, when I look at the actual registry value, it shows %systemdrive%, but when I go through system properties, it shows C:\. This was not happening prior to running the script, so it must be something with the way the OS is processing the key after being modified. Go figure. Thanks for the prompt responses on this. Sorry for the false alarm!

I must be retarded then. I have XP Pro SP1 installed on this packaging machine. Not sure what the deal is. The only thing I see here is that you are creating the key, and I'm overwriting one that is already created. They key type is a bit different too, yours being REG_SZ, mine being REG_EXPAND_SZ. Test it with that key type and let me know. Thanks.

I'm not trying to convert it actually. RegRead and RegWrite are converting it for me... Anyway I'm trying to read in the "Path" info, which contains Env. Variables, specifically, %systemdrive%. I want to write back to the registry what I read out, not C:\. Thanks.

I am attempting to read in a reg value, append some data to that value and the write it back to the same key. The data I'm reading is contains Env. Variables such as %systemdrive%. When I read it into a variable, autoit converts it to the literal or C:\. I can work around this by doing a string replace, but when I do a RegWrite, I get C:\ back into the registry. Any ideas how to get Rewrite to write %systemdrive% instead of C:\? I have tried using Opt(ExpandEnvStrings, 1/0) to no avail. Any help would be appreciated!