Girder 3.2.5 pre 6 [Archive] - Promixis, LLC Forums

Ron

October 13th, 2002, 03:55 PM

TriggerCommand("treePath-to-girder-command-or-multigroup"[, payloaddata]);

I'm not in favour of this because this completely throws the Event-Idea to the side. Also there is no unique path-to-girder-command because the names of the commands and groups are by no means unique.... I can see it being usefull but it's also bad-form. I'll have to think about it.

about the httpd plugin problem, no code is needed :-)

Do this instead:

Select "Girder event" from the dropdownbox next to the "learn event" button
Click on the "learn event" button.
In the first dropdown box Select "On Event"
In the second dropdown box select "Httpd"

et voila that command will be triggered on any event coming from the httpd plugin!

Ron

October 13th, 2002, 03:55 PM

Goto is not the same, Goto uses ID's to find the target command, not the name. I agree with Malversán on this. One thing I do not get, why would TriggerCommand be less work for you then TriggerEvent?

For both commands you'll need exactly as many commands in the tree, and both commands can be dynamically generated in Lua.....

Ron

October 13th, 2002, 03:55 PM

:-D

Isn't that your second proposal on this forum Mark ? Man you are in great demand :-)

I'm not going to release the source anytime soon, so no marriage for me, pfew!

Ron

October 13th, 2002, 03:55 PM

One more thing (that isn't important, in fact). Once a command reference is assigned to a conditional command using the tree picker, you can't unassign the command reference. You can change it for another command reference using the tree picker again, but you can't simply erase it.

Wouldn't it be convenient to give the "Cancel" button in the tree picker a command reference eraser behaviour, instead of having to recreate the conditional command if you have put the "then" or the "else" command reference in the wrong place?

I suppose it may not be difficult to include this improvement... unless you have to code that behaviour in every standard conditional command, instead of in just one place. If so, just save your time for more important things. ;-)

I've arrived to this point when thinking about the "switch" plugin explained before, where you will have to pick many command references and a mistake in the command assignments would be usual.

To remove the links/ID's from the command look at the command menu and select "Clear Links". :-)

Ron

October 13th, 2002, 03:55 PM

Mark, how come your plugin doesn't work with Lua ? Is there an imcompatibility in the API ? I tried to make it compatible....

Ron

October 13th, 2002, 03:55 PM

Aaaah I see,... your plugin 'writes' code that is being processed by the GVMS/Lua. Didn't think of that possibility.

Ron

October 13th, 2002, 03:55 PM

hmm I found the reason :

void __stdcall delete_variable(char *name)
{
// unsupported right now.

UpdateReg();
}

oops :-) I'll try to implement that tomorrow, I'm just beat today. After a week working like crazy for a class I'm going to take it easy tonight.

Ron

October 13th, 2002, 03:55 PM

Mark you are the lucky owner of number 52! Congratulations!

Mark F

October 13th, 2002, 03:55 PM

When you get a chance, would you please correct the return codes from t_get_variable_type?

It currently says:

typedef int (WINAPI *t_get_variable_type) (PCHAR name); // 1 = int, 2 = double, 3= integer, -1 = does not exists.

Which one of the integers is really string? ;)

Mark F

October 13th, 2002, 03:55 PM

What is the intended behavior when the user presses cancel or close (X in the upper right) in the script editor window? Right now, it appears the open_script_editor() function returns 2. Perhaps it could return NULL to indicate this condition?

By the way, the script editor window works very well on my system. :)

Mark F

October 13th, 2002, 03:55 PM

Bon appetite!

Only worry about the return value if nothing else is pressing. I'm at work so I won't be able to test/change anything until this evening, at the earliest. It works pretty well now and I can make progress. :D

Mark F

October 13th, 2002, 03:55 PM

The tamper protection won't let me use the above (pre6-2) linked file. :(

Mark F

October 13th, 2002, 03:55 PM

Great! Pre6-3 returns NULL for both the close (X) and cancel buttons.

Thanks. :D

Mark F

October 13th, 2002, 03:55 PM

I'm not going to weigh in one way or another on this. I'm just trying to help. :)

Would it help if I made a plugin that would allow you to do one of many gotos based on the value in a variable? I don't know how much programming experience you have but it could work like a C-language switch() statement:

switch ( Variable ) {

case 0:
goto Cmd0;
break;

case 1:
goto Cmd1;
break;

case 2:
goto Cmd2;
break;

case 3:
goto Cmd3;
break;

default:
goto CmdDefault;
break;
}

if Variable == 0 then Cmd0 (chosen using the tree picker dialog in Girder) would execute.

OR

It could work like an if/elseif/else construct:

if ( VariableExpression0 ) {
goto Cmd0;
} elseif (VariableExpression1) {
goto Cmd1;
} elseif (VariableExpression2) {
goto Cmd2;
} elseif (VariableExpression3) {
goto Cmd3;
} else {
goto CmdDefault;
}

where the first expression that evaluates to TRUE would have the associated GOTO executed.

In either of these cases, your script could set a variable to force the right goto and could generate 1 event to make it happen. I mention this because I have a plugin at home that incorperates both the switch() and if/elseif/else constructs above for GVMS (not LUA). If it would help, updating it to support LUA may be easy.

As I said, I'm just trying to help here. :)

Mark F

October 13th, 2002, 03:55 PM

Since I only want to do one command only, it seemed reasonable to avoid having to set up all the UserEvent EventStrings, and just execute the command I wanted, by name.
Yup, that seems reasonable. Slow, cumbersome and error prone; but, reasonable. :)

Unfortunately, as you now know, that is not how Girder works. Girder bases the decision for executing a command (like a goto) on a specific, unique, ID number. Ron has stated before that changing this behavior would be a "BIG DEAL"(tm).

Gack! Using the tree picker is exactly what I'd like to *AVOID*.
Sorry you feel that way. This is the mechanism supplied to get the information needed to execute the goto. If you want to execute a specific command, you need to reference it via the only unique ID it has in this system. Yadda, yadda, yadda. The unique ID is returned by the tree picker. ;)

Only a little over 30 years ...
DAMN MAN! You ARE old! :D

Mark F

October 13th, 2002, 03:55 PM

So I will love you if you release this simple plugin. And if you release the source code, I will marry you. :-)
Thanks for the offer but I'm already hitched. :D

I'll try to update this to LUA before next Monday. I will release the source code as well.

Mark F

October 13th, 2002, 03:55 PM

Sorry I wasn't clear. In a previous post, I had said:

I mention this because I have a plugin at home that incorperates both the switch() and if/elseif/else constructs above for GVMS (not LUA). If it would help, updating it to support LUA may be easy.
What I meant when I said:

I'll try to update this to LUA before next Monday.
I'll update the Switch plugin (.dll) to support both GVMS and GVMS-LUA. I believe this is what you want. :)

Mark F

October 13th, 2002, 03:55 PM

There is not an incompatibility between LUA and GVMS at the API level. The incompatibility is in the two languages. This is expected.

My plugin forms expressions that need to be evaluated to TRUE and FALSE. In GVMS, this was simple enough. Passing the string "x == y;" to the parser would evaluate the expression and return the result. LUA doesn't work that way so I have to change my plugin.

Mark F

October 13th, 2002, 03:55 PM

At the time, this seemed like the easiest way to do what I needed.

To make this work with LUA, I'm introducing a variable which will get set to one of two values. This works pretty well; but, I'm having a problem with the delete_var() interface. When I use it, the variable still shows up in the variable window when I press F10.

The name of the variable is "__SWITCH_VAR__3fd5e860_d1d9_11d6_a1ef_0050bae11cbc __" and when I pass it through the delete_var() interface, the return code is 1.

Mark F

October 13th, 2002, 03:55 PM

Works for me. :) Have a relaxing evening.

I have to clean up some more stuff before this is complete anyway. (the plugin has a dialog refresh problem that I have to find. :x )

When you get a chance, could you send me a plugin number for this? Thanks.

Mark F

October 13th, 2002, 03:55 PM

Thanks, Ron. :)

Marsupial

October 13th, 2002, 03:55 PM

Hi Ron!

It is my understanding that the new version supports LUA.

Is there any GVMS-LUA conversion utility?

I have extensive scripting usage, and I am not quite willing to translate all of it by hand. Might get stucked with older version.

thanks.

Marsupial

October 13th, 2002, 03:55 PM

Ron does the lates girder version takes my GVMS GML file without trouble or I need translation of some sort?

I am thinking on upgrading anytime soon... ifever there is a conversion utility, tough, I am willing to sacrifice as a tester ;)

psg

October 13th, 2002, 03:55 PM

Ron,

BRAVO! I'm beginning to really like this!

I do have a request (as usual :lol:).

Can you add another function to LUA? What I have in mind is this:

TriggerCommand("treePath-to-girder-command-or-multigroup"[, payloaddata]);

Essentially, this would be the same as having created a UserEvent for the command and calling TriggerEvent. The benefit is that it avoids the necessity of creating hundreds of UserEvent strings.

Another minor enhancement to the HTTPD plugin ... is it possible to define an eventstring that matches ANY page, rather than a specific page? A single LUA script is going to be able to handle everything I need to do ...

Regards,
Paul

psg

October 13th, 2002, 03:55 PM

TriggerCommand("treePath-to-girder-command-or-multigroup"[, payloaddata]);

I'm not in favour of this because this completely throws the Event-Idea to the side.

Well ... you've really already done this, by way of the GirderAction->Goto, so please don't let philosophical concerns stop you from exposing the same functionality via Lua. :-)

Also there is no unique path-to-girder-command because the names of the commands and groups are by no means unique.... SNIP

Yes, quite true, but easily solved by simply saying either "the first matching command gets executed", or "all matching commands get executed". Either way would be fine.

about the httpd plugin problem, no code is needed :-)

Do this instead:

Select "Girder event" from the dropdownbox next to the "learn event" button
Click on the "learn event" button.
In the first dropdown box Select "On Event"
In the second dropdown box select "Httpd"

et voila that command will be triggered on any event coming from the httpd plugin!

Now THAT is nice!!!

Regards,
Paul

psg

October 13th, 2002, 03:55 PM

It occurs to me that I should probably explain what I'm doing, so that you'll understand what I'm after.

Top level: control large, complex home theater including HTPC from a webpad.

A bit more detail: HTPC runs TheaterTek DVD player & Girder, controls ALL other components via serial output or UIRT2 ouput. No other remote is contemplated.

Background: I was doing this with a Pronto before, until I got an Extron LD4 RGB switch, which only talks serial i/o.

The plan (partly implemented): Three top-level groups, Devices, Macros, and Web. Devices contains groups containing mostly single action commands that send the IR code (or serial output) for a function to be done by a device. Macros have multi-groups containing Girder GoTo's to accomplish functions, such as WatchDvdOnTV, or WatchSatOnProjector. The Web group is responsible for invoking Macros or Device commands (now via TriggerEvent Lua function calls).

Currently, the only part of the query-string from the HTTPD plugin I care about is where I send the EventString for the TriggerEvent function. That's why I can use a single HTTPD event, rather than having an enormous amount of commands in the web group ... I only need one.

So, if there were some way to do a LUA-scripted "TriggerCommand" by way of the command treePath instead of an EventString, then I'd avoid having to enter several hundred EventStrings (one for each Device function, and Macro). Also, execution would be more efficient, since Girder wouldn't have to spin through the whole tree checking ALL the EventStrings.

Paul

psg

October 13th, 2002, 03:55 PM

Goto is not the same, Goto uses ID's to find the target command, not the name.

Sure ... under the covers it does, but when you create the command, you pick the target command *by name*. The fact that you're using the command ID internally is really just an implementation detail.

I agree with Malversán on this. One thing I do not get, why would TriggerCommand be less work for you then TriggerEvent?

For both commands you'll need exactly as many commands in the tree, and both commands can be dynamically generated in Lua.....

Yes. But the issue is avoiding creating all those EventStrings for all the commands that I wish to trigger, elsewhere in the tree. Since I basically duplicated each device's remote into its group in the Device top-level group, that's a LOT of EventStrings.

Think of it this way: using TriggerEvent() is like an indirect reference to a variable through a pointer (the EventString). All I'm asking for is a way to directly address the variable, to avoid the declaration and initialization of the pointer, and to avoid having to *think* about the pointer, when there is no (user-level) functional reason for an indirect reference.

In any case, this isn't anything that will stop me from doing what I need to do; it just seemed to me to be a natural extension to what you had already done, so if you wish me to drop the subject, that's OK with me.

Regards,
Paul

psg

October 13th, 2002, 03:55 PM

I'm not going to weigh in one way or another on this. I'm just trying to help. :)

Would it help if I made a plugin that would allow you to do one of many gotos based on the value in a variable?

Thanks Mark, but not really. What I'm doing currently is sending the query-string "dvd.cooldog.com?input=*xxxxx" through the HTTPd plugin ... LUA sees the '*', and knows that the rest of the string, "xxxxx" should be passed to TriggerEvent. Since I only want to do one command only, it seemed reasonable to avoid having to set up all the UserEvent EventStrings, and just execute the command I wanted, by name.

I don't know how much programming experience you have

Only a little over 30 years ... OH SHIT! I just realized that makes me a REALLY OLD FOGEY! DAMN! And I swear ... they all used to call me "The Kid" .... ;)

but it could work like a C-language switch() statement:

switch ( Variable ) { SNIP...
case 0:
goto Cmd0;
break;

case 1:
goto Cmd1;
break;

case 2:
goto Cmd2;
break;

case 3:
goto Cmd3;
break;

default:
goto CmdDefault;
break;
}

if Variable == 0 then Cmd0 (chosen using the tree picker dialog in Girder) would execute.

Gack! Using the tree picker is exactly what I'd like to *AVOID*. Better to just finish with typing in all those UserEventStrings. I'm about 2/3 through doing that anyway ....

Regards,
Paul

Malversán

October 13th, 2002, 03:55 PM

The request for TriggerCommand() was something I had in mind too.

But I think the main problem would be for the user having to specify exactly the command he wants to trigger, because I think commands are not exactly specified by a "path in the tree" as you see in the Girder window. They are coded into GML files in XML syntax, with a unique ID code for each. So if you issue a TriggerCommand(commandID [, payload]), that code will NOT be updated in the Lua code if you duplicate or import into another GML file the command that contains the TriggerCommand(), or if you simply delete the triggered command.

Although that, it would be a great feature. I'm also searching for a way to do it.

An evident way (as you say) is issuing unique user events with the TriggerEvent() function, but I think it´s not a good idea when you plan to duplicate or import command groups, as event identifications are global and you´ll get many commands triggered.

At this moment, I've only used another evident solution. It works like a switch statement, but a command needs to be declared for every case, and maybe that's not the idea:

switch: Lua code where you set the variable value.
case1: result = (variable == value1), and then jump to command1 if result.
case2: result = (variable == value2), and then jump to command2 if result.
etc.

Of course you can have only one case, if you just want to trigger one command.

Maybe a switch plugin/command would be useful. Not hard to code, but my C skills are far away from these days (I'm also planning to code a fully configurable "multifunction" command plugin based on repetitions of the same event, that would allow "one key managed" menus and multiply the functions of your remote control, but C++ samples are too confusing for me and I don't know exactly how to easily design a configuration UI and how to manage the OSD device context to simply display text).

Hope this clarifies a little or takes you into another brainstorm (that´s a great source of solutions). ;-)

And sorry for my awful english.

Malversán

October 13th, 2002, 03:55 PM

Would it help if I made a plugin that would allow you to do one of many gotos (chosen using the tree picker dialog in Girder) based on the value in a variable?

I know that's extremely easy to make (specially when having plugin skeleton samples), but my huge limitations in "modern C" keep me off the game by the moment (just handling DC's or making the config UI is more than a pain for me).

So I will love you if you release this simple plugin. And if you release the source code, I will marry you. :-)

And, of course, if Ron (God saves him) releases the source for Girder, I will marry both you. ;-D

(Sorry if this is going a bit "off topic")

Malversán

October 13th, 2002, 03:55 PM

In reply to Mark:

I'll try to update this to LUA before next Monday. I will release the source code as well.

You mean that the "switch" plugin will be coded in Lua? I think I've not understood you.

I meant a DLL usual plugin, that picks many commands (the more commands, the more useful) and executes one of them basing the choice in a Lua variable value ranging 1-N.

I think you were talking about that, but maybe my english isn't enough accurate to get you. The "update to Lua" has confused me.

In reply to Ron:

The unique ID is returned by the tree picker.

One more thing (that isn't important, in fact). Once a command reference is assigned to a conditional command using the tree picker, you can't unassign the command reference. You can change it for another command reference using the tree picker again, but you can't simply erase it.

Wouldn't it be convenient to give the "Cancel" button in the tree picker a command reference eraser behaviour, instead of having to recreate the conditional command if you have put the "then" or the "else" command reference in the wrong place?

I suppose it may not be difficult to include this improvement... unless you have to code that behaviour in every standard conditional command, instead of in just one place. If so, just save your time for more important things. ;-)

I've arrived to this point when thinking about the "switch" plugin explained before, where you will have to pick many command references and a mistake in the command assignments would be usual.

I'm not going to release the source anytime soon

Sorry, Ron, I read in another thread that you were releasing the code, but later I realised that you were talking about the HTTPD plugin only.

By the way, I'm happy to realise that I'm not the only older-than-30 here (not much, just 31). ;-)
That's why no one wants to marry me?

Malversán

October 13th, 2002, 03:55 PM

Reply to Ron:

Thanks a lot. I'm a newbie Girder user, and I still hadn't reached that "Clear links" option. :-)

It's easy to bypass some user options when you deal with an utility that is more interesting for developers than for users. Girder is one of these things that you enjoy more when you put your hands into it, rather than on it. ;-)

Reply to Mark:

I'll update the Switch plugin (.dll) to support both GVMS and GVMS-LUA. I believe this is what you want.

So you meant you will update both plugins to support the "result" Lua variable. Yes, that's what I was talking about. :-)

Sorry I didn't understood you before.

Thanks a lot for both. Marriage offer is still up. ;-D