Sign in to follow this  
Followers 0
smashly

DLLCall()

5 posts in this topic

#1 ·  Posted (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 by smashly

Share this post


Link to post
Share on other sites



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).

:D


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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

I 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:

For $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)

:D


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

Share this post


Link to post
Share on other sites

Hi,

Dang what did you go and do that for .. :D 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 :D,

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. :D

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

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0