SpinningCone

Hmm, might work, though I'm not sure if it will make maintenance harder or easier. I've not used that before so i'll ahve to look at the output and really see the results and how it works with project maintenance.

Different scripts are different age and respond differently , now that I think about it I do have one that works but can no longer compile (there's a parsing error in one of the libraries, but it runs from the editor, i think it's an AU check compatibility issue but haven't spent much time investigating) another I had issues with file.au3 where in the new version _FileWriteToLine() decided that it should delete the last CRLF of a file when called. this caused parsing problems with a flat file I had when it would later add content to said file (or parse it expecting a final EOL). some scripts go a long time without needing anything then might need an update (years), others get more frequent updates (months). I hope to try to get everything on the same page and all working again with the latest versions but moving forward I need to mitigate the issues Though it's more stuff it's probably the best will be to just use the wrapper and maintain a full version of autoit for each project. It creates a ton of bloat but in the end it should allow me to have a known good working library/autoit pair preserved for making updates. I might still develop a little dependency manager utility to help with upgrading and then write a bunch of documentation for handling the project files.

Ive considered writing (in autoit ironically) a dependency manager that would open a script parse all the includes, make sure they were copied to the include folder in a project then recursively find all the includes of the includes etc etc and then re-write each library include to point to the local directory. It would be relatively portable as I could zip the project folder and take the whole file structure with me. an advantage here is that it would only need copies of the actual dependencies not the whole include directory. a disadvantage is that there might still be incompatibilities especially if later i add a library that had the same base dependency (like a GUI or Array library) and now there's two different versions. that contingency could be handled but it could get messy fast. another disadvantage is needing to take the time to write such a utility. Overall i was hoping for a line similar to the wrapper line that AdamUL mentioned except rather than point to an install directory where it expects a full autoit install just point to the include directory. While I could still get incompatibility with later versions of autoit generally the newer version of autoit itself handle s the older libraries just fine and it would be a big step up. Overall I'm not sure what the "ideal" dependency management would be , maybe if all core libraries had versions and a version history were maintained. ie under include was "old versions" and the #include <> statement could take a version as a parameter, if that version wasn't found it would look in the old versions folder and try to find the old version. might looks something like : +include Date.au3 +old versions Date-1.0.au3 Date-1.1.au3 Date-2.2.au3 . . Then old version dependencies could be installed independently as they would only be used in scripts that provided a version parameter.

Hmm that might work, though it'd be nice not to have to copy a full auto-it install for each, I might give that a try. Compiling isn't a solution (most of these run compiled anyway) , if i need to fix a bug or add a feature or make any change I need the original script working.

OK so long story short about a year ago I upgraded auto it and have pretty much had problems since. Mostly stemming from the fact that my scripts were old enough to be using different library file versions. Since a bunch of my stuff does production level work I can't afford to have it break on every update so what I want to do is isolate all the include files per script. ie each new script would get it's own folder for the au3 and a complete copy of the libraries at the time it was written. Thus all it's dependencies would be self contained and each script could be upgraded individually. Now I know I can explicitly put a path for my includes. for example if i had array.au3 i could copy that library to the project then explicitly point to the copy . however array.au3 has it's own includes which will point back to the install root, and those includes could have includes etc etc. hand editing each library isn't practical. Is there a way to indicate at the top of a script where the include folder is (without doing a registry hack each script) ?

nm, figured out my problem.

To better understand the issue i started from scratch and made 3 different scripts to illustrate the problem (see attached) cmdBug-Script.au3 works as intended. cmdBug-Hotkey.au3 and cmdBug-form.au3 exhibit the oddity with sending old commands. cmdBug-hotKey.au3 cmdBug-form.au3 cmdBug-Script.au3

OK so i'm trying to build a tool part of which adds a GUI to a command line tool. my tests seemed to work fine but when i ported my function into a GUI they break, the first time i invoke the commandline it returns nothing, then each subsequent time i press the button that calls to command line it ignores the current command and re-sends the last command. if i press the button a second time the command updates. IE let's say i have a command line app with a counter as one of the inputs. Press button to generate output -> "0" returned Press Button again with same paramaters -> "Hello world 1" returned Change counter to "2" press button -> "Hello world 1" returned press the button again -> "Hello world 2" returned THis was boggling my mind so i stripped out the GUI and took the function that was being called in the GUI and make it a hotkey call. now the exact same code that calls the commandline has different behavior Press hotkey to generate output -> "0" returned Press hotkey again with same paramaters -> "Hello world 1" returned Change counter to "2" press hotkey-> "Hello world 2" returned So a hotkey act's "normally" bot only after the initial "0" is returned. if I perform the function call for the command line before the hotkey while loop it functions properly the first time. : This seems like some sort of autoit bug but i have no idea how to work around it. : example code #include <Constants.au3> #include <array.au3> #include <ButtonConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> Opt("GUIOnEventMode", 1) #Region ### START Koda GUI section ### Form=c:\users\datwater\documents\autoit\projects\otp tool\otp tool.kxf $Form1 = GUICreate("Form1", 392, 448, 191, 148) GUISetOnEvent($GUI_EVENT_CLOSE, "Form1Close") $Label1 = GUICtrlCreateLabel("seed", 23, 57, 35, 17) $txtSeed = GUICtrlCreateInput("", 66, 55, 213, 21) $btnRandomSeed = GUICtrlCreateButton("Create Seed", 287, 53, 74, 25) GUICtrlSetOnEvent(-1, "btnRandomSeedClick") $txtCounter = GUICtrlCreateInput("5", 72, 96, 71, 21) $txtLength = GUICtrlCreateInput("6", 223, 96, 48, 21) $Label2 = GUICtrlCreateLabel("Counter", 24, 99, 41, 17) $label3 = GUICtrlCreateLabel("Length", 173, 98, 37, 17) $txtOutput = GUICtrlCreateEdit("", 38, 213, 326, 201) $btnGen = GUICtrlCreateButton("Run Command", 149, 154, 80, 25) GUICtrlSetOnEvent(-1, "btnGenClick") GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### local $key = "" local $length = 8 local $count = 5 Local $cmd = Run("cmd.exe", @ScriptDir, @SW_SHOWNORMAL, $STDIN_CHILD + $STDOUT_CHILD) While 1 Sleep(100) WEnd Func btnGenOTPClick() $length = GUICtrlRead($txtLength) $count = GUICtrlRead($txtCounter) $Seed = GUICtrlRead($txtSeed) $otp = runCommand($Seed,$length,$count) GUICtrlSetData($txtOutput,$otp & @CRLF, "|") EndFunc Func btnRandomSeedClick() GUICtrlSetData($txtKey,genKey(40)) EndFunc func runCommand($s,$l,$c) ;build the command $command = "oathgen.exe -c " & $c & " -l " & $l &" -s " & $s & "& @CRLF ConsoleWrite("COMMAND: " & $command & @CRLF) ; debug check ;send command to the console StdinWrite($cmd, $command) $line = "" ;loops and gathers all the command output While True $line &= StdoutRead($cmd) ConsoleWrite($line) ;debug If @error Then ExitLoop ;to exit the while loop we look for the blank command prompt, the trimming is needed to get a clean match. If StringRight($line,StringLen(@ScriptDir) + 1) = @ScriptDir & ">" Then ExitLoop Sleep(30) WEnd ;i do some parsing here of the output then return it , that all works fine EndFunc Basically where i'm calling StdinWrite($cmd, $command) i can see that $command is what i want it to be, but the first time it runs nothing is sent and the second time you press the button the command is correct but it actually sends the *old* command to standard in . This is only when running in a GUI though. if you lop out the runCommand function and run it just in a script it works as expected

Cool, yeah I can take a look at the beta and see if it exhibits the same problems. Might even be better, part of the reason it took so long for me to suspect a real bug is that i would occasionally see EOL errors with autoit (emails not formatted right and other storage files with missing EOLs) but it was pretty rare and only really happened with a script that uses a file that's now larger than it should be.

Thanks Melba23 , for now i'll just stick with the old library instead of manually inserting EOL after each call. I'll just mark it as dependent on that version (this way i don't end up with doubles if the library changes again). This will also help fix some errors I've been getting in another process that uses a flat file for storage. Long term I might switch out to a sqlite db though that will take quite a bit of re-writing. or i'll write a function smart enough to correct errors in the document format to accommodate changes in library functions.

Thanks , i'll take a closer look at it when i get the chance (last minute changes before higher priority items) , for the moment I have rolled to 3.2 since that's what i was using (I was slow to do updates, if it ain't broke don't fix it right?). this is the old code from 3.2: Func _FileWriteToLine($sFile, $iLine, $sText, $fOverWrite = 0) If $iLine <= 0 Then Return SetError(4, 0, 0) If Not IsString($sText) Then $sText = String($sText) If $sText = "" Then Return SetError(6, 0, 0) EndIf If $fOverWrite <> 0 And $fOverWrite <> 1 Then Return SetError(5, 0, 0) If Not FileExists($sFile) Then Return SetError(2, 0, 0) Local $sRead_File = FileRead($sFile) Local $aSplit_File = StringSplit(StringStripCR($sRead_File), @LF) If UBound($aSplit_File) < $iLine Then Return SetError(1, 0, 0) Local $hFile = FileOpen($sFile, $FO_OVERWRITE) If $hFile = -1 Then Return SetError(3, 0, 0) $sRead_File = "" For $i = 1 To $aSplit_File[0] If $i = $iLine Then If $fOverWrite = 1 Then If $sText <> '' Then $sRead_File &= $sText & @CRLF Else $sRead_File &= $sText & @CRLF & $aSplit_File[$i] & @CRLF EndIf ElseIf $i < $aSplit_File[0] Then $sRead_File &= $aSplit_File[$i] & @CRLF ElseIf $i = $aSplit_File[0] Then $sRead_File &= $aSplit_File[$i] EndIf Next FileWrite($hFile, $sRead_File) FileClose($hFile) Return 1 EndFunc ;==>_FileWriteToLine

FOr a while now i've been running a script that uses a flat text file to keep track of users to perform actions on. I have some logic in the block that adds new users with some comma delimited fields with FileWriteLine and then updates that line with _FileWriteToLine this has been running fine for years but suddenly i'm having problems with the script crashing because when the very last line of the file is losing it's CRLF so the next appended line concatenates with the last line and the parser fails to parse the last line. this has been driving me nuts for a while so i finally took apart all my code and have discovered that for some reason _FileWriteToLine deletes CRLF off the bottom of the file after use. i don't know why this started suddenly, i even copied an old file.au3 library and it still does it (maybe a change to shell32.dll? ) I was able to replicate the bug by making a new file with each line having CRLF at the end then with the following code: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_UseX64=y #AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** _FileWriteToLine($FilePath,12,"Test rewrite",1)After running the code and refreshing the file i can see that the last blank line disappears (no final CRLF) Is there a way to prevent this behavior? (without a huge logic rewrite to use a DB or another write method) EDIT: actually it seems that replacing the old au3 is working, or at least working some of the time. not sure if it's a *sometimes* bug with the older library.

I'm trying to build a script to call some functions of a web service. I have found this example for doing SOAP ?do=embed' frameborder='0' data-embedContent> so I assume I can manually read out the wsdl file and figure out how to hand build a payload to do what I want ( I think, honestly this is all new to me). the problem I have is that the service requires authentication via client certificate. and I can't seem to find any example of how to use a webservice like that with autoit. I *might* have a basic auth option to access the service too but that's not 100% and even if I can I don't know how to do basic auth in autoit either. is this possible with autoit it (with either auth)? can anyone point me to some code?

OK , I'll look around. might just start looking at migrating to Powershell. Thanks for the help.

OK i guess I don't know how to get that to work. The array now looks like this '> So I see the DN of the folders and activesync objects. so I tried this code to iterate through the array and call delete on them . $aResult = _AD_GetObjectsInOU($sUser, "(distinguishedname=*)", 2, "distinguishedname,objectclass") If @error Then MsgBox(0, "Error", "Error " & @error & " occurred!") Else _ArrayDisplay($aResult) Endif for $i = 2 to UBound($aResult) - 1 $explode = StringSplit($aResult[$i][1],"|") $class = $explode[UBound($explode) - 1] ConsoleWrite("Deleting:" & $aResult[$i][0] & @crlf & "Class: " & $class & @crlf) _AD_DeleteObject($aResult[$i][0],$class) Next _AD_DeleteObject($aResult[1][0],"user") Doing this I get some COM errors - output (condensed) Deleting:CN=ExchangeActiveSyncDevices0ACNF:c4d72d52-287f-4a88-8bc3-a0d9a7f5fe7d,CN=[CN],OU=[OU],OU=[OU],DC=[OU],DC=[DC],DC=[DC] Class: msExchActiveSyncDevices [no com error here for some reason, object not deletedthough] Deleting:CN=iPhone§ApplC8TJ6LZSDPNG,CN=ExchangeActiveSyncDevices0ACNF:c4d72d52-287f-4a88-8bc3-a0d9a7f5fe7d,CN=[CN],OU=[OU],OU=[OU],DC=[OU],DC=[DC],DC=[DC] Class: msExchActiveSyncDevice [no com error here for some reason, object not deletedthough] Deleting:CN=ExchangeActiveSyncDevices,CN=[CN],OU=[OU],OU=[OU],DC=[OU],DC=[DC],DC=[DC] Class: msExchActiveSyncDevices COM Error Encountered in AD tests.au3 Description = The directory service can perform the requested operation only on a leaf object. Deleting:CN=iPhone§ApplC8TJ6LZSDPNG,CN=ExchangeActiveSyncDevices,CN=[CN],OU=[OU],OU=[OU],DC=[OU],DC=[DC],DC=[DC] Class: msExchActiveSyncDevice COM Error Encountered in AD tests.au3 Description = Access is denied. [user delete] Description = The directory service can perform the requested operation only on a leaf object. Might come down to an access thing. I can't delete one of the iphone objects inside one of the activesyncdevices folders. Not sure why the other ones won't delete and why the same object appears twice. Also not sure that if i had permission to delete the one that it would take care of all objects inside this user. Also seems weird that i get an acess error since i can perform the delete via subtree in ADUC.