smashly Posted September 27, 2009 Share Posted September 27, 2009 (edited) Hi, I've been poking around AutoIt UDF includes. I notice that most the error checks after a DllCall have the @extended macro in the SetError() return. eg:$aResult = DllCall(xxxx, xxxx, xxxx, xxxx, xxxx) If @error Then Return SetError(@error, @extended, 0) I've looked through AutoIt help file and I can't see any mention of @extended returns when using DllCall() I have tried making an error DllCall() and check what the @extended value is retuning and it's always 0 no matter what error type is returned. So when error checking after a DllCall() what's the @extended meant to be for? I'm mainly asking as I'm writing some gdiplus udf functions and it's sorta bugging me as i can't see the logic of it atm. Am I missing something? Cheers Edited September 27, 2009 by smashly Link to comment Share on other sites More sharing options...
PsaltyDS Posted September 27, 2009 Share Posted September 27, 2009 Hi, I've been poking around AutoIt UDF includes. I notice that most the error checks after a DllCall have the @extended macro in the SetError() return. eg:$aResult = DllCall(xxxx, xxxx, xxxx, xxxx, xxxx) If @error Then Return SetError(@error, @extended, 0) I've looked through AutoIt help file and I can't see any mention of @extended returns when using DllCall() I have tried making an error DllCall() and check what the @extended value is retuning and it's always 0 no matter what error type is returned. So when error checking after a DllCall() what's the @extended meant to be for? I'm mainly asking as I'm writing some gdiplus udf functions and it's sorta bugging me as i can't see the logic of it atm. Am I missing something? Cheers DllCall() leaves @extended undefined. The syntax of the SetError() function requires you to specify a value for @extended if you want to set the return value. In order to leave that value unchanged, you set @extended = @extended. It may not be significant in the case of functions using DllCall(), but is a good generic practice any way. The alternative is to destroy its previous value by something like SetError(@error, 0, 0). Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law Link to comment Share on other sites More sharing options...
smashly Posted September 27, 2009 Author Share Posted September 27, 2009 Hi and Thank You for taking the time to explane. Until you explained it I thought there might of been some undocumented @extended value returned by DllCall() on error that I was missing. lol Yep my logic saw it as SetError(@error, 0, 0) Cheers Link to comment Share on other sites More sharing options...
PsaltyDS Posted September 27, 2009 Share Posted September 27, 2009 Hi and Thank You for taking the time to explane. Until you explained it I thought there might of been some undocumented @extended value returned by DllCall() on error that I was missing. lol Yep my logic saw it as SetError(@error, 0, 0) CheersI should have tested before spouting off. @error and @extended are both set to 0 when DllCall() or any function is called, and since DllCall() doesn't change @extended during execution, it remains zeroed out. Any value from previous to the DllCall() is gone. In addition, SetExtended() and SetError() are themselves functions and any previous value not re-set in the parameters will be lost. Even Return will not leave the values of @error and @extended unless SetError() is used on the same line: expandcollapse popupFor $n = 1 To 5 $iRet = Call("_Test" & $n) ConsoleWrite($n & ": $iRET = " & $iRet & "; @error = " & @error & "; @extended = " & @extended & @LF) Next Func _Test1() ; Returns @error, but previous @extended is lost on DllCall() SetExtended(-1) DllCall("NoneSuch.dll", "int", "NoSuchFunction") ; Generate an error Return SetError(@error, @extended, 1) EndFunc ;==>_Test1 Func _Test2() ; Both @error and @extended are lost on Return SetExtended(-1) DllCall("NoneSuch.dll", "int", "NoSuchFunction") ; Generate an error Return 2 EndFunc ;==>_Test2 Func _Test3() ; Both @error and @extended are lost because there is no Return SetExtended(-1) DllCall("NoneSuch.dll", "int", "NoSuchFunction") ; Generate an error EndFunc ;==>_Test2 Func _Test4() ; @error is lost when SetExtended() is called SetError(-1) SetExtended(-2) Return 3 EndFunc ;==>_Test3 Func _Test5() ; Returns both @error and @extended SetError(-1, -2) Return 4 EndFunc ;==>_Test4 The safe bet is what was used: Return SetError(@error, @extended, $iRetVal) Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law Link to comment Share on other sites More sharing options...
smashly Posted September 28, 2009 Author Share Posted September 28, 2009 Hi, Dang what did you go and do that for .. lol I thought it made logical sense the first time round when you explained it.. Basically your tests were similar to what I tried before I originally posted. My logic sees it as @extended is unneeded in the situation of: $aResult = DllCall("xxxx", "xxx", xxxx","xxx","xxxx") If @error Return SetEerror(@error, @extended, 0) The reason it got my attention was due to I use at @extended to get a value return of a function that sets @extended data. But if a function does not set @extended value and I'm Returning the SetError on the first line after a DllCall, then @extended will always be 0 no matter what value @extended was before the DllCall(). So once again I really can't see the logic of why @extended has been used the way it was in the udfs when placed after a DllCall(). I mean it's not causing any problems or issues apart from to my logic , but I still couldn't see why @extended would be used as opposed to 0. In the end against my logic telling me that 0 is visually shorter then @extended I opted to be a sheep and follow the the tried and proven way it's been done before. After a DllCall() I use If @error Return SetEerror(@error, @extended, "failure return value") Once again thank you for taking the time to check it out. It's appreciated. Cheers Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now