bhoar

My original SPTI-based optical tray control/detection code thread is here: http://www.autoitscript.com/forum/index.ph...mp;#entry201117 -brendan

Note also that _CommListPorts() takes a second, optional, parameter which changes the return type. By default the current code base returns an array but it can be changed to a single string by passing 0 as the second parameter. Perhaps the default behavior of the current releases may have changed from early versions. -brendan

Valik, Thanks for all the great work you've done in the libraries. I especially found the _Singleton() function extremely useful this weekend...after a couple of tweaks. Now, hear me out before the flaying of my flesh commences. Perhaps I will deserve it. I know that the original purpose (your purpose) for the _Singleton() function was simply to ensure that a single copy of the script would run. I made several *minor* modifications to the _Singleton() function and came up with a way to add two features: 1. The ability to, in a loop, use _Singleton() to wait for another process to exit. This required fixing a bug in the original, which was the creation of duplicate handles to the same mutex if the _Singleton() function is called more than once from inside a process. Sounds crazy, I know...but when you call CreateMutex with a name that matches an existing mutex...it actually does create a different handle to the mutex, while also returning the $ERROR_ALREADY_EXISTS error. So _Singleton() now discards that duplicate handle before exiting when called with the "1" flag. 2. The ability to use _Singleton() to protect critical regions by allowing the process to discard the mutex handle it created. It's not quite full on mutex support, but it is quite a bit more useful to me. To prevent confusion, my functions are currently named _SingletonXX() and _SingletonReleaseXX(). I have included them below. Let the flaying of my flesh begin. -brendan CODE; #FUNCTION# ==================================================================================================== ================ ; Name...........: _SingletonXX ; Description ...: Check if no other occurence is running. 20081221 - if one is, you can now continue checking for its exit in a wait loop, or even pair the function with _SingletonReleaseXX() to protect critical regions of code. ; Syntax.........: _SingletonXX($sOccurenceName[, $iFlag = 0]) ; Parameters ....: $sOccurenceName - String to identify the occurrence of the script. This string may not contain any \ characters unless you are placing the object in a namespace. ; $iFlag - Action if @error ; |0 - Exit if occurrence already exists ; |1 - Return if occurrence already exists ; |2 - Allow the object to be accessed by anybody in the system. This is useful if specifying a "Global\" object in a multi-user environment. ; Return values .: Success - handle to mutex (new 20081221 by bhoar) ; Failure - 0 ; Author ........: Valik ; Modified.......: 20081221 by bhoar - incorporates original function but also allows for waiting for other script to exit before continuing or even protecting critical regions of code. ; Remarks .......: You can place the object in a namespace by prefixing your object name with either "Global\" or "Local\". "Global\" objects combined with the flag 2 are useful in multi-user environments. ; Related .......: ; Link ..........; ; Example .......; Yes ; ==================================================================================================== =========================== Func _SingletonXX($sOccurenceName, $iFlag = 0) Local Const $ERROR_ALREADY_EXISTS = 183 Local Const $SECURITY_DESCRIPTOR_REVISION = 1 Local $handle = 0, $lastError, $pSecurityAttributes = 0 Local $hMutex = 0 If BitAND($iFlag, 2) Then ; The size of SECURITY_DESCRIPTOR is 20 bytes. We just ; need a block of memory the right size, we aren't going to ; access any members directly so it's not important what ; the members are, just that the total size is correct. Local $structSecurityDescriptor = DllStructCreate("dword[5]") Local $pSecurityDescriptor = DllStructGetPtr($structSecurityDescriptor) ; Initialize the security descriptor. Local $aRet = DllCall("advapi32.dll", "int", "InitializeSecurityDescriptor", _ "ptr", $pSecurityDescriptor, "dword", $SECURITY_DESCRIPTOR_REVISION) If Not @error And $aRet[0] Then ; Add the NULL DACL specifying access to everybody. $aRet = DllCall("advapi32.dll", "int", "SetSecurityDescriptorDacl", _ "ptr", $pSecurityDescriptor, "int", 1, "ptr", 0, "int", 0) If Not @error And $aRet[0] Then ; Create a SECURITY_ATTRIBUTES structure. Local $structSecurityAttributes = DllStructCreate("dword;ptr;int") ; Assign the members. DllStructSetData($structSecurityAttributes, 1, DllStructGetSize($structSecurityAttributes)) DllStructSetData($structSecurityAttributes, 2, $pSecurityDescriptor) DllStructSetData($structSecurityAttributes, 3, 0) ; Everything went okay so update our pointer to point to our structure. $pSecurityAttributes = DllStructGetPtr($structSecurityAttributes) EndIf EndIf EndIf $handle = DllCall("kernel32.dll", "int", "CreateMutex", "ptr", $pSecurityAttributes, "long", 1, "str", $sOccurenceName) $hMutex = $handle[0] $lastError = DllCall("kernel32.dll", "int", "GetLastError") If $lastError[0] = $ERROR_ALREADY_EXISTS Then If BitAND($iFlag, 1) Then ;20081221 - First release the mutex! The original Singleton() code created a new, duplicate handle *every time* you looked for a mutex. ; Granted, that worked ok for the original purpose where you'd inevitably exit immediately if another script was found running, which destroyed the mutex... ; But if you wanted to wait on another process or even use the mutex to protect critical regions, you definitely don't want multiple handles to the same mutex ; name lying around... _SingletonReleaseXX($hMutex) Return SetError($lastError[0], $lastError[0], 0) Else Exit -1 EndIf EndIf ; 20081221 - Remember to keep track of the return value, it's the handle to the mutex you now own... Return $hMutex EndFunc ;==>_SingletonXX ; #FUNCTION# ==================================================================================================== ================ ; Name...........: _SingletonReleaseXX ; Description ...: Accessory function to _SingletonXX() and can be paired with _SingletonXX() to protect critical regions of code. ; Syntax.........: _SingletonReleaseXX($hMutex) ; Parameters ....: $hMutex - handle to mutex originally generated by _SingletonXX() ; Return values .: None ; Author ........: bhoar ; Modified.......: ; Remarks .......: This is a bridge approach between the original untradeable lock of _Singleton() and real mutex requesting and trade between processes, but without diverging too far from the current _Singleton() function ; Remarks .......: Technically this is actually destorying the mutex, not just releasing it. ; Related .......: ; Link ..........: ; Example .......: ; ==================================================================================================== =========================== Func _SingletonReleaseXX($hMutex) Local $handle $handle = DllCall("kernel32.dll", "int", "ReleaseMutex", "int", $hMutex) $handle = DllCall("kernel32.dll", "int", "CloseHandle", "int", $hMutex) EndFunc ;==>_SingletonReleaseXX And an example of how I use it here: $hMutex = _SingletonXX("AnyDVDAutomation", 1) If $hMutex = 0 Then ConsoleWrite("Waiting up to 20s to get mutex for AnyDVD window control." & @LF & @LF) $mutexTimer = TimerInit() While $hMutex = 0 And TimerDiff($mutexTimer) < 20000 Sleep(1000) $hMutex = _SingletonXX("AnyDVDAutomation", 1) WEnd EndIf If $hMutex = 0 Then ConsoleWrite("Unable to get mutex for AnyDVD control...exiting." & @LF) Exit ($rcReject) EndIf ;;;; ;;;; CRITICAL REGION OF CODE GOES HERE ;;;; $rc=_SingletonReleaseXX($hMutex)

Sorry, don't have any experience with any 64-bit Windows OSes. -brendan

Like martin, I'm interested in progress in this as well. Autoit native code that removes the need to use an external dll (much as I appreciate martin's) would be nice. -brendan

Sleep or hibernate? If sleep, then it is probably windows unlocking the tray during resume. If hibernate, the power to the drive is cut, so the drive wakes up unlocked. If it doesn't work when it resumes at all, the handle might be stale. In some situations, I've found it's safer to get rid of the handle (via the appropriate windows function) when you're not using it and just grab it when you need it. -brendan

You're welcome! -brendan

Search the forums for "obfuscator". It doesn't block the ability to see the script, but what they get is so completely stripped of contextual clues to be almost useless. -brendan

thanks for the keen eye and the re-link, weaponx. -brendan

Glad I was able to help. -brendan

Martin, just another update (though we talked about this a while back via email or PM, IIRC): I distributed your DLL as part of an early version of my Universal Loader CLI a couple of months ago, which was released publicly as part of the the dbpoweramp R13 alpha/beta cycle (the code is in the driver set for the batch ripper modules). I've tested on some of my own 600 and 900 disc robots with very good success. Some other folks out there on the interwebs are now ripping 1000s of CDs hands-free with your little gem (and dbpoweramp, of course). Meanwhile, I have to finish the work on the ULCLI, primarily to make it handle errors/problems encountered by the hardware and to enhance cooperation amongst processes serving a single robot. Then I'll unleash it on my own arena of robots. Pperhaps I will call it...Ripperdome. -brendan

Try one of these two substitutions: _CommSendString("setinp 8e" & @CR, 1) or _CommSendString("setinp 8e" & @CRLF, 1) Probably the first one. -brendan

Are these USB-connected virtual com ports? If so, I think this is substantially outside of the scope of the DLL and UDF. From my experience, Windows itself (or the driver(s) that XP SP2 shipped with) does not handle the loss/disconnect of an already-opened virtual com port well at all. I've had both BSODs and devices that failed to work when plugged back in (until the next reboot) in these situations. e.g. how well does Hyperterminal handle the same situation that martin's code doesn't handle? -brendan

Hopefully you found the solution, but my original script used the wrong datatype on a call related to the drive handle. See the original thread here: http://www.autoitscript.com/forum/index.php?showtopic=28326 And search thread for the text "fix for the drive", which points to this thread with discussion of the bug: http://www.autoitscript.com/forum/index.php?showtopic=39368 Again, thanks to garyfrost for the fix. -brendan

My approach was to extend my SPTI code (posted in these forums) which talks directly to the drive and use the Get Configuration CDB (0x46). I'd post the code I'm using now, but it is desperately in need of a cleanup. -brendan