Interactive dialog in protal ...

[bcorwin]

I need to demonstrate one to many functionality. The one will be portal. The many will be six of our led light driver boards attached to six of your rf engines. Each rf engine will talk to a light via the uart (one direction for now). I will likely do something like the transparentMaster/Slave.py example. In my case the master will be portal and the data to transmit will determined from buttons hit in a dialog in portal.

How do I create a dialog with buttons in portal? This dialog does not need to display anything from the many nodes.

Thank you.

Bernie

[kbanks]

I can think of three different ways to approach your problem:

1) Don't use buttons, use function names

Functions in your Portal script will appear in the "tree" of the Node Info pane.
They can be individually invoked by clicking on them. For example:


def buttonA():
# do something here

def buttonB():
# do something here

def buttonC():
# do something here


This will give you the degree of interactivity you requested, but not the "look".

2) Once you start wanting your own GUI (new displays, new dialogs, etc.), you really should be making your own standalone client. This can be written in any language that supports XML-RPC. Your new client uses whatever GUI library you like, and talks XML-RPC to our SNAPconnect "gateway".

You can download a 30-day evaluation copy of the SNAPconnect gateway from this forum. It comes with a Users Guide and example source code that should get you started.

3) Although you cannot fully integrate into the Portal GUI (you cannot make a new "pane" for example), you can bring up custom dialog boxes (etc.) from within Portal scripts.

Portal uses the wxPython GUI library internally, and so that library is also available to your Portal scripts. For more about wxPython, see http://www.wxpython.org/.

You can find an example of this technique in the EK2100
Users Guide, downloadable from the forum but also already included in Portal 2.1 (look under the Help menu).

(Take a look in the vicinity of page 45.)

Note that we did not develop the wxPython library, we just use it from Portal. We are unable to provide extensive support if you choose to go this route, although you can always try asking your question on the forum.

Approaches 2 and 3 are for more advanced users. If you are not in this category you may wish to contact our Custom Solutions group about developing your application for you on a contract basis.

[kbanks]

Separate from the GUI issue, I would like to point out that even if you are talking to your LED boards serially, it does not mean you have to use DATA MODE.

You could be invoking RPCs (like LEDon() and LEDoff()) over the air, and the implementation of those functions could "print" the necessary characters out the serial port.

The difference is now you are allowing the SNAP nodes to "hide" the details of how the LEDs are actually controlled. To understand the advantages of this, consider the following scenario.

You've developed your app as described, but now you want to reduce costs by having the RF Engines drive the LEDs directly (using one or more of the GPIO pins). If you've kept the details of LED control "pushed down" (encapsulated) into the RFEs, only the RFE scripts have to be changed to accomodate this hardware change.

If you let the serial protocol "spread" throughout the system, you will have to make changes both places.