 |
Hazram
Wanderer
Joined: 24 May 2005
Posts: 71
|
 Posted: Fri Aug 26, 2011 8:01 pm
Indirect Function syntax?
|
What's the syntax for calling an indirect function?
I tried:
#FU func1 {#PRINT success!}
#VAR myFunc = func1
@{@myFunc}()
but that doesn't work. |
|
|
|
|
Fizgar
Magician
Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia
|
Posted: Fri Aug 26, 2011 8:22 pm
|
Try putting something between the parenthesis when calling the function indirectly, like:
| Code: |
| #show @{@myfunc}(a) |
|
|
_________________
Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
 |
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Fri Aug 26, 2011 9:01 pm
|
You don't need to put anything for arguments. Not all functions require arguments.
However, to solve your problem, you'll need to do this:
| Code: |
| #EXEC %concat("@",@myFunc,"()") |
Yes, it's probably an awkward way of doing it, but it's the only way I can think of for now. |
|
|
|
|
Fizgar
Magician
Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia
|
Posted: Fri Aug 26, 2011 9:07 pm
|
Putting the argument in will work as well.
|
|
_________________
Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
|
|
|
Hazram
Wanderer
Joined: 24 May 2005
Posts: 71
|
Posted: Fri Aug 26, 2011 9:27 pm
|
Confirmed that using #exec and %concat works. Also found that relying on the bracket-evaluation syntax does not always work. Putting the indirect function call in an #alarm does not work with the bracket notation, but does work with #exec and %concat.
Because #EXEC @{@myfunc}(a) does not work, while #SHOW @{@myfunc}(a) does, I suspect the difference is tied to the difference between #show and #exec. |
|
|
|
|
Fizgar
Magician
Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia
|
Posted: Sat Aug 27, 2011 1:10 am
|
I guess it's possible the package I'm testing in is corrupted and is causing odd behavior on my end, since it's been a while since that has happened. Also I'm not sure how exactly you are using this in an alarm, but my simple tests below work fine without the slowdown everyone talks about experiencing when using #exec.
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<class name="test" copy="yes">
<trigger name="test" type="Alarm" priority="9550" prompt="true" copy="yes">
<pattern>10</pattern>
<value>@{@myfunc}("")
</value>
</trigger>
<alias name="test" copy="yes">
<value>$loc = %1
@func1(%1)
@{@myfunc}(%1)</value>
</alias>
<func name="func1" copy="yes">
<value>#print success!</value>
<arglist>$a</arglist>
</func>
<var name="myFunc" copy="yes">func1</var>
</class>
</cmud> |
|
|
_________________
Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Tue Aug 30, 2011 12:40 pm
|
The slowdown from #EXEC comes from the need to compile the script during execution, instead of when you save it. This slowdown is small if the script can be compiled quickly (as yours can, Fizgar), but can become noticeable with complex scripts.
In addition, it is a bad idea to execute a function without a command in front of it. The general rule of thumb is that you should never start a command line with @ or %. While this may work some of the time, it is not guaranteed to work, and could stop working unexpectedly. The proper way to execute a function is to precede it by a proper Cmud command, such as #CALL, #EXEC, #SAY, or whatever is appropriate. In this case, you probably want #CALL. |
|
|
|
|
|
|
|
