Zugg Software :: View topic - Using Functions in Expressions for Expression triggers

Apprentice Joined: 03 Nov 2007 Posts: 132

I have no idea if this is a bug or working as intended but I was playing around with expression triggers in a clean package. I did the following:

#TRIGGER (@TestFunc()) {#say hi}
#FU TestFunc {#IF (@Test1 && @Test2) {#RETURN 1} {#RETURN 0}}

Then I changed Test1 and Test2 on the command line to 1 and 1 respectively. My understanding would be that the expression trigger would fire as soon as the second variable got set to 1 assuming the @TestFunc() worked the same as other variables do in expression triggers.

So I guess my question is, should this work? If not, would it be possible for it to work?

Posted: Fri Nov 09, 2007 3:52 pm

This probably won't work since expression triggers are evaluated every time one of the variables in question changes. But since there're no actual variables in the expression trigger, it probably won't be checked properly.

Depending on what you want to do, there's probably a way to build it directly into the expression trigger. The example you have there is easy - I'm sure you can think of some more difficult ones :P

Apprentice Joined: 03 Nov 2007 Posts: 132

Well, there's always a work around. I'm just obsessed with clean looking expression triggers hehe

Posted: Fri Nov 09, 2007 5:19 pm

Yep, this won't work. CMUD only creates "update references" for the actual variables listed in your expression trigger pattern. It does not (and cannot) recursively look through every function that you might call.

In the case you show, the expression trigger would be changed when @TestFunc is assigned a different value, but not when something within the current TestFunc definition changed. Doing that kind of recursive testing would make CMUD really slow everytime you changed a variable because of everything that would need to be searched.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

#TRIGGER (@TestFunc(@Update)) {#say hi}
#FU TestFunc {#IF (@Test1 && @Test2) {#RETURN 1} {#RETURN 0}}

When you want the trigger to check you toggle the update variable between 0 and 1 with
Update=(!@Update)

This method could probably be used to fire off a whole bunch of them. Since the function itself can send commands it becomes possible to combine things in very odd ways, I really wouldn't recommend this. You should be able to make a more efficient script by just using an #IF at the same place you would force the update testing. The only way I can see any use for this is in extensibility, and that is already covered better by events.

Posted: Sat Nov 10, 2007 12:41 am

Clever idea Vijilante :) Yes, this will make the trigger dependant upon the @Update variable, even though that argument isn't used anywhere in the script.