Home› AMX User Forum› NetLinx Studio

Modules with GUI included

jjamesjjames Posts: 2,908
in NetLinx Studio
I know it's not standard practice, but what are you feelings on modules that have the GUI interface already included? I'm writing some modules, and I'm thinking about taking this approach, of course having one module not include the GUI and another will. These modules will be released for public use which is why I'm asking.

Thoughts?

Comments

  • Spire_JeffSpire_Jeff Posts: 1,917
    If you are planning on releasing the modules for public use, I would recommend releasing a touchpanel file and gui code with it in most cases. This allows the user of the module a little more insight into your train of thought while programming the module and also provides a known to work implementation that can help troubleshoot.

    This is just my opinion of course :)

    Jeff
  • jjamesjjames Posts: 2,908
    Indeed - there would be a TP file. I'm not sure if I follow on what you're exactly saying, or vice versa.

    What I'm saying is, instead of there being two DEFINE_MODULEs (one for GUI and one for COMM), there would only be one DEFINE_MODULE. Instead of the standard: 
    DEFINE_MODULE 'PRODUCT_COMM'(vdvDEVICE, dvDEVICE)
DEFINE_MODULE 'PRODUCT_GUI'(vdvDEVICE,dvTP,BTN_ARRAY)

    it would be: 
    DEFINE_MODULE 'PRODUCT_COMM_GUI' (vdvDEVICE,dvDEVICE,dv_TP,BTN_ARRAY)

or . . .

DEFINE_MODULE 'PRODUCT_COMM' (vdvDEVICE,dvDEVICE)
  • DHawthorneDHawthorne Posts: 4,584
    The AMX pardigm is to have separate modules, but I have done it both ways.

    One reason to separate them is to protect your code. The UI module will almost certainly need to be modified somewhere by someone eventually, so you have to supply it as an AXS or that can't be done. The comm shouldn't ever change, so you can just supply that compiled, and your work is protected.

    The other reason to separate them is if your program requires a distinct instance for each touch panel (another AMX paradigm). You are courting disaster to have multiple instance of the comm module; it just needs one. But to make it flexible enough for 1 panel or ten, a separate UI module for each does the job. I prefer, usually, to make the panels an array, in which case it matters not - but that approach can become unwieldy if there is a lot of independant feedback to track and maintain.
  • jjamesjjames Posts: 2,908
    David,

    Thanks for the feedback. I do understand where you're coming from, but here's how I set it up. You can use multiple panels controlling the same device, and all you need to do is assign the button numbers in an array, the variable text addresses in an array, and touch panels in an array, and assign some other settings. All of the feedback and comm is handled in the TKO. All these arrays would be in the main program file.

    What I'm trying to accomplish is eliminate the need for a second module, and simplify things on the programmer's part. If you had more than two of the devices, you would need to obviously define a second module, and a second set of touch panels . . . which gets me thinking. If that's the case, I'll need to allow the programmer to add the ability of switching devices. Opened up a can of worms perhaps?
  • GasHedGasHed Posts: 31
    In response to your last comment about multiple copies of the same device... I don't see much wrong with a second DEFINE_MODULE for multiple devices... it's the multiple DEFINES for multiple touch panels thats more of a problem.

    Using a switch command to switch between multiple devices is fine for one zone and one touchpanel, but once you get multiple input devices, you might want to control one of the devices from one zone and simultaneously the other from another zone.

    Pat
  • jjamesjjames Posts: 2,908
    Well, my approach would be to have the devices and the touch panels (real ones) all in DEV arrays. And then the user could switch which device he wants to control. It seems pretty simple logically, it's only a numbers game.

    My real concern is that if I release a module that works fine but is set to allow the programer to only have one DEFINE_MODULE that handles multiple touch panels, multiple devices and all the GUI . . . is it going to freak them out? I don't care about "standards" as long as my way works better. :)
  • Spire_JeffSpire_Jeff Posts: 1,917
    The only problem with combining the GUI code with the device code arises when the programmer is using a different GUI philosophy or implementation than you. If you are trying to force a specific GUI philosophy on the programmer, or your GUI implementation is always completely seperate from the rest of the interface, then it shouldn't be a problem.

    Just IMHO,

    Jeff
  • DHawthorneDHawthorne Posts: 4,584
    The other factor is how the device itself works. How about an Escient Fireball, or a Marantz Sirius tuner that allow database lookups before committing to a selection? Or even a MAX server, where you have one device, but it can be doing something different in every room? You can't send the same feedback to all the panels, because different rooms ought to have the capacity to lookup different things - to say nothing of page flips that vary with what you are doing, etc.
  • frthomasfrthomas Posts: 176
    Well, there is really 4 things to cover:

    -Multiple controlled devices (i.e. multiple modules)
    -Multiple controlled subdevices (i.e. one module and device but that controls multiple players like MAX)
    -Mutliple controllers (TPs)
    -Combinations of the above, with the case of multiple controllers for the same device/subdevice, one controller for multiple devices/subdevices and the full monty, multiple controllers and multiple devices/subdevices...

    Remember the module parameters are variables. If you handle it correctly in the module, the caller could UPDATE the variable during execution. So the caller could change the module arrays to target a different panel. If you handle variable text and the like, you'd probably want to refresh if this happened...

    The problem stems for the lack of proper text support in the module concept, but there is the issue with var text to internationalize the module in another language. Impossible to do if the text is hardcoded in the binary only module.

    Also remember as well making it simple may limit the "power programmer". The guy having to handle the multi/multi case above isn't probably going to have a problem understanding a complex module API.

    I think the two module approach of AMX is sensible as you can use it as it is for simple things, but you have the full comm module API should you need to do things a bit differently. By releasing the GUI part as souce, language translation is possible.

    Now, except for handling languages, nothing prevents you from putting BOTH a COMM API and a (maybe simple) GUI API in the same module.

    Fred
Sign In or Register to comment.