jayterry Posted August 21, 2010 Share Posted August 21, 2010 Basically I was wondering if there was a way I could check to see if a func was available. For example, I have an include file with routines that manage opening, writing to, and closing a log file for an app. Wondering if there was a way I could detect if the logfile functions had been included, then I could programmatically avoid calling them if not. Thanks Link to comment Share on other sites More sharing options...
Tvern Posted August 21, 2010 Share Posted August 21, 2010 The closest thing I can come up with is this: Execute("_UnExisting()") ;try to call a function that does not exist If @error Then MsgBox(0,"Error","Function not found") Execute("_Existing()") ;call an existing function If @error Then MsgBox(0,"Error","Function not found") Func _Existing() ConsoleWrite("This function does nothing." & @CRLF) EndFunc However it would probably be best to add functions to an array when they are added, so you get a list of existing functions. Link to comment Share on other sites More sharing options...
jayterry Posted August 21, 2010 Author Share Posted August 21, 2010 Hmm, good idea to try Execute. Only problem is that it would actually run the function. May not actually want to do so at that point, rather just find out if it's there. The other idea is very workable also, i.e., adding to an "array of functions" if/when you load them. Only problem with that one is that it would be a PITA to build into every set of generic functions I want to optionally be able to include. But then, I did ask for it didn't I?! Just kinda seems like a waste since the AutoIt runtime obviously already has to have a table of available functions, just like it already has a table of available variables. Would simply be nice to be able to query for functions the same as you can query for vars. Oh well, c'est la vie. Thanks Link to comment Share on other sites More sharing options...
Spiff59 Posted August 21, 2010 Share Posted August 21, 2010 (edited) Here's a sneaky way of testing if a function exists without calling it: $oMyError = ObjEvent("AutoIt.Error","MyFunction") If @error then MsgBox(0,"","Function does not exist") $oMyError = 0 ; clear error handler Edit: I can't swear without testing that just clearing the object $oMyError resets the COM error handling. Maybe "ObjEvent("AutoIt.Error","Dummy")" would better ensure that one of your functions isn't kicked off accidentally by some COM error (assuming you're even using COM+) Edit2: I guess there's no point in even assigning the result of the ObjEvent() call to an object. Maybe this is sufficient: ObjEvent("AutoIt.Error","MyFunction") If @error then MsgBox(0,"","Function does not exist") Calling ObjEvent() with no second parm is supposed to return what function the event is set to call, and after those lines, calling "ObjEvent("AutoIt.Error") returns nothing. So maybe there is no cleanup necessary? I suppose if you are using COM+ applications it would be safer to reset to an actual error handling routine. Or maybe there is a value other than "Autoit.Error" that could be used in the ObjEvevt() call that would not run the risk of causing an unwanted function execution. Maybe a dev or AutoIt guru will pipe in here with some inside info on how ObjEvent() works internally (or a completely different way to get your desired result) Edited August 21, 2010 by Spiff59 Link to comment Share on other sites More sharing options...
Tvern Posted August 21, 2010 Share Posted August 21, 2010 That's a nice trick Link to comment Share on other sites More sharing options...
jayterry Posted August 21, 2010 Author Share Posted August 21, 2010 Yes it is! Thank you Link to comment Share on other sites More sharing options...
Richard Robertson Posted August 21, 2010 Share Posted August 21, 2010 You don't need an IsDeclared for functions. Just #include the file in your own file and don't worry about it. Well written UDFs have an #include-once directive in them that makes is so no matter how many times you #include it, it doesn't use it more than once for the entire script. Link to comment Share on other sites More sharing options...
jayterry Posted August 21, 2010 Author Share Posted August 21, 2010 Good point Richard. Thanks 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