best practice for COM Error

[gcue]

im not sure how to go about this..

i have a few functions that call on com objects so i do this

$Custom_COM_Error = ObjEvent("AutoIt.Error", "Custom_COM_Error")

within the same script i also run some _IE functions which i get prompted to

_IEErrorHandlerRegister()

even when i already have the com_error registered up above

on top of this, some of the UDFs i use do their own COM registers

so now im getting messages saying "cant install a new errorhandler when one is still active"

so i have a couple of questions:

1. how do i address the first prompt to register ierrorhandler

2. how do i handle com_error registering within my own script and other udfs?

anyone come across something similar?

thanks in advance

Edited March 2, 2011 by gcue

[PsaltyDS]

This is a painful issue with AutoIt because only one handler for AutoIt.Error can be registered at a time. At one point, I think Valik said something about the possibility one day of a handler stack instead of just one exclusive handler, but that's a low priority feature request not to be counted on for now.

The best you can do now is to be aware of the issue and track it manually in your script. Generally the COM error handlers of the UDFs are loaded at the top where the #include statement is. In the case of IE.au3 it is usually loaded manually by _IEErrorHandlerRegister(), but can be loaded/unloaded when you do certain functions that require that error handling (like _IEAttach).

As for the specific error message you received, it may not be a big deal. Almost all of the error handlers simply write some console text and return. So as long as any one of them is registered, you are not in bad shape.

Note that if you run _ObjEvent("AutoIt.Error"), without the second parameter, it will return the name of the current handler function. So you do this:

; Save current handler
$sOldHandler = ObjEvent("AutoIt.Error")

; Set current handler
$oMyErrorHandler = ObjEvent("AutoIt.Error", "_MyErrorHandler")

; ... do stuff

; Restore old handler
$oOldHandler = ObjEvent("AutoIt.Error", $sOldHandler)

Here's the problem with that: How do you know the old handler function is looking for $oOldHandler as the name of the object? There is no way to know programatically what variable name was used to save the object of the old handler, so no way to restore it to same name. If the old handler contains references like $oHotComHander.number, they will fail because even though you have pointed back to the same function, the variable is now $oOldHandler.

Edited March 2, 2011 by PsaltyDS

[water]

@PsaltyDS,

do you have any recommandations for UDF scripters? How should I write the COM error handler for the AD UDF? Should I implement it the same way as in the IE UDF?

Now I install the COM error handler if no error handler exists.

[PsaltyDS]

Dale discussed this issue with the Devs while working on IE.au3. He and Devs certainly know more about it than I do, and I consider the method inside IE.au3 to be the best practice example until something changes, like:

1. We get an assumed variable name established by convention and implemented that way in all the standard UDFs (i.e. "$oAutoItError shall be the standard error handler object's variable name.").

2. We get a way to retrieve the name of the existing error handlers variable (i.e. $sName = Eval("AutoIt.Error"), or $sName = @AutoItErrorHandler).

3. We get a different mechanism completely, like a stack of multiple possible handlers that each test internally if they want to handle the error then either handle it and exit the stack, or ignore it and pass to the next handler in the stack.

4. We get something smarter and simpler than any of the above, that I'm just not bright enough to think of right now.

Edited March 2, 2011 by PsaltyDS

[water]

Thanks a lot for your reply!

I will check how the error handling stuff is implemented in the IE UDF and put it on the todo list for the next version of the AD UDF.

[gcue]

awesome thanks fellas for your help!