Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: Girder 3.2.5 pre 6

  1. #31

    Default Reply to psg

    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.
    Just a newbie trying to help.
    Thanks for Girder.

  2. #32
    Join Date
    Sep 2002
    Location
    Kenton, DE, USA
    Posts
    73

    Default

    Quote Originally Posted by RonB
    Quote Originally Posted by psg
    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

  3. #33
    Join Date
    Sep 2002
    Location
    Kenton, DE, USA
    Posts
    73

    Default

    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

  4. #34
    Join Date
    Sep 2002
    Location
    Kenton, DE, USA
    Posts
    73

    Default

    Quote Originally Posted by RonB
    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

  5. #35

    Default "switch case" plugin

    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")
    Just a newbie trying to help.
    Thanks for Girder.

  6. #36
    Join Date
    Sep 2002
    Location
    Kenton, DE, USA
    Posts
    73

    Default

    Quote Originally Posted by Mark F
    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:

    Code:
    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

  7. #37

    Default

    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?
    Just a newbie trying to help.
    Thanks for Girder.

  8. #38

    Default

    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
    Just a newbie trying to help.
    Thanks for Girder.

Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •