TriggerEvent question

[widert]

Hello all

I'm having a (probably stupid) problem related to the TriggerEvent function.

I'm trying to have the following script:
portstatus = 0
portstatus = PORTIO_ReadBYTE( 889 )
if ( portstatus < 128 ) then
print ("Switching Receiver On")
TriggerEvent("Receiver On",53);
end

start an event called "Receiver On" (Which actually starts notepad) but nothings happens , except that "Switching Receiver On" is showed in my LUA window.

Anybody has any suggestions?

Regards,
Tom

[Ron]

You used device id 53, is the event that you created also assigned this id ? most likely it is id 18, try that.

[widert]

I've tried that ID as well, but I'm stil not getting it to work... :cry:

Maybe I'm doing something fundamental wrong?

What I'm trying to do is:

One IR command is triggering one command, which contains the script.

This script checks status on parallel port (works great!!) and is supposed to trigger another command (which at the moment simply starts notepad).

To trigger this second command I've added an EventString (called "Reciver On" which I'm calling from my script, using TriggerEvent.

I must be doing something wrong here...

Tom

[Mark F]

Are you confusing the event's name with the event's value?

The name is what appears in the tree control (defaults to EventString). This is cosmetic and makes the command tree human readable.

The value is what appears in the "LED display" (on the right side, middle of the Girder window) when you choose the event name in the tree control.

The TriggerEvent() function wants the event's VALUE.

Try adding the Logger plugin to your system. It will show you the events as they flow through Girder. Once you get this debugged, you can remove the Logger plugin. :)

[drobertson]

Even though you have creadted the event string (I hope the speeling mistake in your name was a mistake).

I am not in front of my computer at the moment (well not the one with Girder installed) but I think you want to use the Event drop down to select "Girder Event" and then press the button "Learn Event".

You will get a dialog box where you can type in your "Receiver On" and press OK. Girder has now learned the event. Then retry your code.

David

[widert]

Yepp, and there she goes :)

Thanks guys, you're doing a great job!!

[drobertson]

I must be getting used to this Girder. Now I'M helping people :o

[widert]

Hope I'll get there some day as well... :)

[johnp]

This thread answered a question I had about why LUA's TriggerEvent was not triggering my Girder Event. Basically I had to use device ID 18 as an argument. The first question is what exactly is this field for? Next can I adjust this value in the event somehow and if so, how?

Just curious more than anything.

Thanks.

[Mark F]

The Device ID represents the plugin that is generating the event string. In the case of Girder events, the value is 18.

Different plugins will generate events with different Device IDs. If you look at the developer page (http://www.girder.nl/developer.php), there is a table about half way down called "Girder 3.2+ Plugin numbers". The first column in this table is the Device ID.

If you have already learned an event from a device to trigger a command, you can use the TriggerEvent() routine to spoof the event (with correct event string and ID) to cause the command to execute.

[johnp]

Ahh, I see. This could be very useful. I won't have to learn a new Girder event just to include a trigger inside LUA. I previously assumed this was the case.

Very cool. Thank you.

[chros]

It was a very helpful intro !!! Thanx !

But I don't know what payloads is for ! ( payload1, payload2 ...)

BTW: as I look at the table that You' ve mentioned there's 2 UIR device ID (I have an serial-port UIR):
1 and 201

What is the difference between them ???? I'm using the 201, which I must select in the Settings .
Strange: when no button pushed on the RC, Girder diplays some number (events) in the status line .... What's this ?

[Mark F]

Payloads allow extra data to be sent through Girder with an event. For example, a script or plugin could generate an eventstring called "ElapsedTime" and include the actual time value as payload data. This way, a command could be triggered by the constant eventstring "ElapsedTime" while the variable information (the elapsed time value) would be available for the command in one or more of the payload variables [pldx].

The difference between the 1 and 201 plugins is the one with ID 1 is for earlier versions of Girder while the 201 ID is for the current one.


Strange: when no button pushed on the RC, Girder diplays some number (events) in the status line .... What's this ?
Sounds like your IR receiver may be generating data (events) when it shouldn't.

[miked]

What is the advantage to using payloads rather than, say, in the script that is triggering the event, define some variables, and then use those variables in the commands that are triggered? :roll:

[Mark F]

The advantage of passing data as payloads vs using global variables:

Consider this scenerio - Based on a condition, a script or plugin sets a global variable to a value and generates an event. Before the event is processed, the condition occurs again and the global variable's value is changed to reflect the second condition, not the first. The two events are processed and both use the current global variable value (for the second condition).

The revised scenerio - Based on a condition, a script or plugin generates an event and passes event specific data through the payload data mechanism. Before the event is processed, the condition occurs again and another event and payload data pair are generated. The two events are processed and the correct event specific data is processed with each event.

For some things, global data vs payload data won't matter. For others, this is vitally important.

Does this help at all?

[chros]

A bit for me ... :) (Thanx for the quick answer.)

But the last thing of the basics is that not clear for me:
the variable scope , function scope, regxx scope, payloadx scope

If there're couple of Groups, moultigroups, commands I don't know which I must use !

If I am rigth:
- regxx scope is: the whole scripts, plugins in girder
- variable : it dies when another Event is coming
... ???

If U explain it to us this too, the whole thread should be included in the FAQ !!!!! :D

[Promixis]

LUA vairables and funtions are available thoughout the entire girder script - doesn't matter where they are defined. (unless of course you use local)

However, the girder command containing the lua code must have been "run" before any vaiables or functions are added to the global list.

[Mark F]

As Mike said, most things in Girder's LUA script implementation have global scope.

Exceptions:
variables specifically declared with the "local" keyword
values passed to functions (parameters)

The pldX variables are global but only contain valid data during the processsing of the associated event.

The regX and tregX variables are global.

For anyone who wants to drown in technical information on Girder's LUA implementation :) , also see the LUA 4.0 on-line manual (http://www.lua.org/manual/4.0/). Incomprehensible? Maybe. Usable? Maybe.

[vynce]

There is also a Lua Book that I have found to generally be more useful than the manual since it has examples: http://www.inf.puc-rio.br/~roberto/luabook1.pdf

[miked]

Mark, thanks for the clarification in why use payload versus variables. In my situation, I'm passing on caller id info to commands that then display them on the screen (and on various other devices). Inasmuch as the second call of the OSD command will erase the contents that were displayed by the first call of the OSD command anyway, having the first call accidentally or inadvertently use the second version of the variable values doesn't matter -- since even if it had used the correct first version of the variable values, those values would be quickly erased on the screen anyway. So that's why I didn't understand why you would even need payload stuff. But I see what I would be needed where having correct variable values for each execution of a command is critical.

[Liickdude]

Well, I must be really challenged. I had this work once, and now it wont do it again for me. I created a command called "Ring1", which I made open notepad. This works if I test the command with F5. I learned a girder Event to it called "say_test" So then I write a small script in a different command under Variable Manipulation Script, and the script is simply

TriggerEvent&#40;say_test,18&#41;;
Now I test this script, and it shows "22:26:25 Thursday, October 16, 2003 EVENT: Dev: 18 say_test" in the logger, but it wont open notepad. Arrgh, I dont know why this is giving me so much trouble. It did work once, I am sure of it. And I have rebooted since, and the rest of my gml works fine still. Anyone have any ideas?

[Bitmonster]

Of course the right syntax should be:

TriggerEvent&#40;"say_test", 18&#41;
But the Logger output indicates, you got the right value in your actual script.

Also take note, that EvenStrings are case-sensitive.

[Liickdude]

Got it, I had the event in a multigroup. Does that mean that I can only use TriggerEvent for basic commands? Or is there a trick to using it inside a multigroup? This works for me now, just curious is all, thanks for the help!

[Bitmonster]

There shouldn't be any problem to use TriggerEvent inside a Multigroup. I think I have many commands this way. But of course the sending code and the target of the event must be in separate commands/Multigroups or you would build some kind of loop.

But this is obvious so I don't think it was the problem.

Maybe you can export your "faulty" group and send it to me. Would be interesting for me to see, where the actual problem is.

[Liickdude]

I am not sure what I had before, but it is working now. I had a multigroup set to load the number from the modem in my caller Id gml, and then to say it out loud using the Text to Speech engine, now I just use a single command to trigger the event from the modem, and the command uses girder>goto my multigroup that parses the number (from 12345 to 1 2 3 4 5) so the speech engine can read it, then the say plugin to read it out. It works great and has excellent 'cool factor'!