I added those as "nameable color fields" - so when I do another update (maybe tonight, even), you'll be able to do that.

Basically, instead of reading it as a number, it will read it as a string, then check the color names before resorting to a numeric. Thanks for reminding me to use that method.

??

I don't understand.

The dialog, when created, saves a pointer to the XML node (which is why it must "live" for the duration of the dialog). At that point, if I force it to "reconfigure" it will re-read the node for the setup parameters. If you changed anything (and somehow force the reconfigure), the changes will be reflected in the dialog.

For this purpose, I'll have a "RefreshDialog" command, and some commands will also force the reconfiguration (XMLSetValue probably should, since any changes to the XML may likely be reflected in the display). The script won't have to do much.

So you'll create the dialog once. You only need to update the dialog's configuration when something changes. What you see on the screen now doesn't even do this.... checkboxes toggle without the need to even refresh the configuration - however, if you needed to set another control to unchecked, for example, because some control was clicked, you'd need to refresh things, since it's not "automatic"

(I hope that made sense.)

I think I understand. Under normal conditions you don't need to worry about it. But (EntryMaker examle again) if you want to have to radiobuttons become visible after checking a checkbox and visa-versa, then you'd need to worry about the refresh stuff.

While I'm at it. How about a GOTO LABEL1 OnFail GOTO LABEL2 for actionscripts?

Thee's ONERROR and ONTHISERROR support, but it's only rough at the moment. I've got to add fatal error support to it.

As for your control definitions, what's going on here:

??? Top=85 Bottom=240???? That's a pretty tall button. Generall, give 25 or so pixels to the height, so you end up with B="85" T="110" - all of those buttons should look messed up.

Remember "t" is the top, "b" is bottom, "l" is left, "r" is right, all relative to t0,0 being the top left corner of the dialog. The focus rectangle is positioned as a border two pixels OUTSIDE of the control's rectangle, so allow for this as well (only matters for controls that accept input)

The dialog remains, .....UNLESS..... you execute another UI object, as only one is displayed at a time (the "current" dialog, menu or ActionDraw list). I may change this before the release, if it's not too much hassle (i.e. the performance is acceptable). I do admit, it's a bit disconcerting.

I have to admit, though I've done a little work, I spent a little time last night and today playing with a new toy.... an Archos 20GB MP3 Player, the FM Recorder. MediaPlay in my area had several units for 50% off ($134 out the door). There's open source software called "RockBox" to drive it, and it records voice, line in, and from FM radio; it also acts as a USB2.0 HD, meaning I can transport a great deal of data around. I already carry around MXM on a memory key This thing is pretty slick, and the best deal I've seen on something like this was $130 **AFTER** a $50 rebate from Amazon.com for one of the "lesser" models.

Anyway, I have had time to mess with MXM (even on Valentines day), and I will probably post something tonight to make Dialogs a bit cleaner and more useful. Some of the modeless mechanism stuff is in. Maybe I'll whip out the progress control when I get a chance.

Yes, it will.

I'm still working on those issues (unconstrained text, visible and enable).

I might fix some before I update later.

You cheater!

But yeah, I don't know what I was thinking when I posted it. It was unfinished, and had a wip name.

This was from the System UI Screenshot post. Now what I tried to do was make my dialog even simpler by name CtrlID to text and not numbers.

Like CrtlID="Exit"

and then for the case I had

CASE Exit

But nothing happened though. So is this because the CtrlID has to be numeric?

Yes, that won't change, simply because they are used as TriggerIDs for events, which have to be numeric parameters.

It would be nice to find an easy way to determine the node, rather than the way I do it in my example, which is by "place" in the dialog.

I'm prepping an update right now. Dialogs can have a timer now, and there's a tested example in the internal.xml (combined with a new TestDialog.xml file)

Doh..... OK. I'll have to fix that. It's actually the fault of the update caused by the timer event setting values in the dialogs.

OK, it's not setting the text in the XML. I'll have to fix that.

I was fixing overdraw just now...

This is the results when nothing checked

This is the results with everything checked

And the results with everyother one checked

The 7th checkbox is alway coming up true with a capital T. Any other true values are lowercase. And as you can see there seems to be an issue when the checkbox is false cause sometimes the value is false and others it blank.

What does your Dialog XML look like?