a_riot42 Posts: 1,619
Just wondering how others do this. If you write a module for a basic switch or other device that doesn't have a UI, what method do you use to trigger commands? The options typically are do_pushed_timed, send_command, send_string and pulse or on, off. For a simple module with simple commands and no levels, parameters etc, which method do you tend to employ?
Yes that seems to be the standard, although I've seen do_pushes on the virtual as well to trigger a button event. Not sure if there are any advantages to using do_push or not.
On the other hand in my UI modules i use the on/off or button types of input.
I'll use on/off with channels with displays for example, so when I do an entire system off, it's as simple as pulse[dv_display,28], and that'll take care of all displays, and no need for an additional send_command dvDisplay1,"'POWER=0'". I'll agree that at first it seemed even redundant, but when I realized I could pulse an entire array's power-off-channel and have everything turn off I was sold.
I look at UI modules as just an extension of the main code, and in fact I definitely stay away from doing any type of page flips. UI modules, in my opinion, are for feedback handling only that's within its own file and not for panel navigation as that should be done in main code. I absolutely detest any UI module that takes the liberty of trying to page flip for me, and most likely that page doesn't exist. In fact, that's the first thing I remove when going through UI modules if I have to use them from AMX.
You can do the same with send_command so I don't see that as a huge advantage in and of itself, but POWER=0 does seem a bit much when pulsing a channel accomplishes the same thing.
Agreed. I don't use AMX UI modules, and write that part myself. Their comm modules tend to be well written though.
Another consideration *might* be that between sending a command and pulsing a channel to a remote master, it could be more advantageous sending one send_command vs. a pulse command because a pulse would send two ICSP messages (one for on, and another for off) to the remote master whereas the send_command would send one ICSP message. A pulse would send two packets totaling 62 bytes, where as a single send_command of 'POWER=0' would only be 39 bytes. Granted, it's only a difference of 23 bytes, but if you really wanted to split hairs, that'd be a difference worth noting.
So - programmatically it might be easier to pulse a channel (let's face it, channel_events are a bit easier than having to parse text), but in terms of message lengths and number of internal messages - send_command would be a better alternative.
Hmm, yes something to consider. I have a feeling pulses are easier on the CPU than send_commands although I have no proof of that so it might end up being a wash. I would consider that less important than the programming ease though. I find writing send_command code tedious and prefer the shortcut of:
but it depends on what the device has to do. Some devices have a different command for each function ie: DOLBYHD, DTSHD, etc, where the above will work and other have a few commands with lots of parameters ie SURR,4 and SURR,5 where it won't as well.
My standard routines are all setup to use
I then use specialized send_commands for proprietary functions (ie setting a route in a switcher, setting surround modes, etc).
It works for me and and 'SP' parsing is really simple and quick to put in a switch..case or select..active that is already in place for parsing the specialized commands.
All feedback is in the form of string vents from the virtual that gets handled in a UI module. The UI modules only handle button events and text feedback events and popup pages for the one specific device. The main code handles all of the other page flips (which accounts for about 95% of the page flips/popup control in the system).