Dynamic ConfigUI

I need to dynamically generate the ConfigUI for some actions. This has been discussed in several threads, but is there any official guidance on how best to do this? I'm planning to interpose the getWhateverConfigUiXml calls, use minidom to parse the file XML, put in my edits, then reconstitute the XML and pass it to Indigo. Is there a better/more future-proof way to do this?

Why am I doing this? I want to define dynamic default values, morph menus to text fields and back, implement macros like menu-or-other, and such - all cases where I want to pick up the static XML, edit it according to rules, and then pass the result upstream. I'm not (currently) trying to make up ConfigUI from scratch.

This all means I'll add XML elements to your ConfigUI. Do you have any suggestion on how to name mine, so they're less likely to clash with future additions of yours?

Cheers
-- perry

[jay (support)]

I'd suggest naming your elements and attributes as well as any field types you may define with some prefix (CYN_ or something). Since it's unlikely we'll be using prefixes/namespaces in future versions I think that would make sure there are no collisions.

Okay, so I put a custom field type into a field in my Devices.xml, defined getDeviceConfigUiXml in my plugin, and wrote code to translate the custom field into a series of standard fields. Except someone's getting to the XML before my getDeviceConfigUiXml is called and yells:

Error (client) runDialogForDevice() caught exception: PAXDialogControllerError -- Fields must contain a valid 'type' attribute: textfield, menu, checkbox, list, separator, label, button.

Who is it, and how do I shut it up? Whatever check that is (and I can't find that message), shouldn't it be applied to what getDeviceConfigUiXml produces, rather than to its input?

Or (as always), what am I missing here?

Cheers
-- perry

Never mind that. It turns out that Indigo's log reorders messages. The

Error (client) runDialogForDevice() caught exception: PAXDialogControllerError -- Fields must contain a valid 'type' attribute: textfield, menu, checkbox, list, separator, label, button.

message is about the output of getDeviceConfigUiXml (I found that bug in my code), but it performs some miraculous time travel and ends up before the log messages issued from that function. A bit eerie, actually... but harmless.

It reminds me faintly of Einstein, actually. Which event happens first depends on where you are.

Cheers
-- perry

[matt (support)]

We send those error messages on the neutrino display bus, so they travel faster than the normal electrons and get to the display faster.

Seriously though, the (client) in the log means the message is being logged directly by the Indigo client to its own window. The other error messages are coming through the Indigo Server as it broadcasts log packets to all connected clients.