Dynamically call a handler

Is it possible to Dynamically call a handler… for example, I want to have a handler or function that calls another handler from another script but I won’t know the name of the handler until execution time.


on callAnotherHandler handlerName
    send handlerName to "SomeOtherScript"
end callAnotherHandler

when I do that above I get an error that ‘handlerName’ does not exist. Is there a way to but the value of handlerName into some form that can be used as a handler?

Thanks!

Your example actually works as posted for me when the called handler is a command or “on” handler. But there are some alternative syntaces that will also work. For commands:

on callADynamicCommand commandName
     do ( "run myOtherScript's" && commandName )
end on

or

on callADynamicCommand commandName
     do ( "send" && commandName && "to myOtherScript" )
end on

For functions there seems to be a problem with the “value” function and the newer function calling syntaces; however, the following form will work:

function callADynamicFunction functionName
     return value( "[myOtherScript" && functionName & "]")
end function

Hope this helps.

strange… your examples work for me, but mine does not… Thanks again for your help! :lol:

I’m trying to do something similar. My test cases have a ‘setup’, ‘main’ and ‘cleanup’ section, and they call out to another script that has the responsibility of running these three functions at the appropriate time. Thus, the other script generates the function calls on the fly and calls them using ‘do’, since it builds them as strings. (each function can have a unique id, thus the need to be doing the work on the fly).

However, I’ve noticed that ‘do’ seems to be a huge bottle neck. It takes 5 - 10 seconds to move from the ‘do’ statement into the function that it will eventually call.

Can I get around this? It looks like it’s taking a long time to convert the string into something that eggplant understands as a function call …

Chris.

When you use the “do” statement, the compiler is invoked again to compile the evaluated code. This will definitely tend to slow the process down a bit. If the timing of your script runs is that critical to your test process, I’d suggest that you have your “main” functions write out some timing messages to a separate log file. Either that, or depending on exactly what your test configuration looks like, you might be able to call your “main” functions using the RunWithNewResults command. Your “functions” would actually need to be individual scripts in order for this to work, but this would allow you to isolate the scripts doing the work from the scripts that are just managing those scripts. As it’s name suggests (we hope), RunWithNewResults runs a script as though it were being executed by itself, rather than as part of a larger script, thus allowing it to generate a result file of its own instead of having its results lumped in with a bunch of other script output.

It turns out my delay wasn’t really in the ‘do’ call.

I was sending function calls into space and eventually they found the correct destination and were executed, however, they seemed to be searching for a long time.

I reorganized things so that my callbacks were targeted directly at the script that was expecting them, and it increased the speed by 3 - 5x.

It’s nice that functions can just be called and they’ll eventually find the correct destination, but you have to be careful.

I thought I’d post this as a heads up if anyone else is seeing the same issues. Or maybe I’m the only one who has things written in such a backwards way :slight_smile:

Chris.