Print

[Kthulu]

QUOTE (flattspott @ Feb 12 2004, 12:48 AM)

CODE Because dialogs are created using XML, it should be trivial to either use a prebuilt dialog or dynamically create your own dialogs as needed from the UI Spec White Paper

Yesss...we're gonna hold you to that BJ

[BenJeremy]

QUOTE (flattspott @ Feb 11 2004, 11:46 PM)

How do we go about using the Dialog elements: like the test button for example. What needs to be done to get it to to do some something? Are we spose to use something like IF CrtlID{101} == "1" GOTO Oh, yeah the dialog looks pretty great for being newborn and all

In the event handler, you can use a switch statement:

CODE

:EVentHandler SWITCH %UIObjectHandle% CASE MyDialog ; Now look at the control id (UITriggerID)  SWITCH %UITriggerID%   CASE 1    SWITCH %UIEventID%     CASE 1      ...SOMECODEHERE...     ENDCASE    ENDSWITCH   ENDCASE  ENDSWITCH ENDCASE ENDSWITCH

It doesn't have to be that complicated, depending on how you number your controls (if you number them all uniquely, even among different dialogs, you could skip the UIObjectHandle stuff.)

Another technique might be to put a LABEL in the XML of the dialog controls to handle specific control's events, and extract that.

[BenJeremy]

QUOTE (Kthulu @ Feb 12 2004, 02:25 AM)

QUOTE (flattspott @ Feb 12 2004, 12:48 AM) CODE Because dialogs are created using XML, it should be trivial to either use a prebuilt dialog or dynamically create your own dialogs as needed from the UI Spec White Paper Yesss...we're gonna hold you to that BJ

Yes, I fully intend on expanding the methods for submitting dialogs. The CreateDialog method will be set up to use the node location given with an XML handle.


Likewise, I was thinking last night of adding the ability to create an XML handle from a UI Object handle, or even making them interchangable.

[flattspott]

Let me see if I am getting this.

The SWITCH stuff is sort of like the IF stuff only instead if having just 2 IFs (ELSLIF) you can use however many CASEs you need. So basically the SWITCH will go through all the CASEs until it finds the appropriate one to use based on the current variable?

[BenJeremy]

CODE

SWITCH %SomeVar% CASE 1  MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 2  MsgBox "This is displayed when SomeVar == 2" ENDCASE CASE 3 CASE 5  MsgBox "This is displayed when SomeVar == 3 and SomeVar == 5" ENDCASE DEFAULT  MsgBox "This is displayed when SomeVar equals something else not covered above" ENDCASE ENDSWITCH MsgBox "Code continues here after the ENDCASE statements!"

They can be nested, too.

[flattspott]

QUOTE

SWITCH %SomeVar% CASE 1 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 2 MsgBox "This is displayed when SomeVar == 2" ENDCASE

Ok but what about in dialog use. Cause in your TestDialog, you have CtrlID="101"

Should we then do it this way

CASE 101
MsgBox "This is displayed when SomeVar == 1"
ENDCASE
CASE 102
MsgBox "This is displayed when SomeVar == 2"
ENDCASE

[BenJeremy]

QUOTE (flattspott @ Feb 12 2004, 10:04 AM)

QUOTE SWITCH %SomeVar% CASE 1 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 2 MsgBox "This is displayed when SomeVar == 2" ENDCASE Ok but what about in dialog use. Cause in your TestDialog, you have CtrlID="101" Should we then do it this way CASE 101 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 102 MsgBox "This is displayed when SomeVar == 2" ENDCASE

Yes, whatever values you use in CASE are intended to match up to the value following the SWITCH statement.

The value following a CASE can be anything, even text. There's also a numeric comparison version.

I added it specifically to handle events from the dialogs, though it has many more uses.

[flattspott]

Ok cool, I think I'm getting it now.

Another thing (TestDialog) you have

<rect t="10" l="10" b="30" r="100" />
<Text>Test</Text>

<rect t="50" l="10" b="70" r="100" />
<Text>Exit</Text>

Onscreen they both look the same size but the B values are different. How's that work. Is it like B is the bottom edge of the Box in relation to the top of the screen?

[BenJeremy]

QUOTE (flattspott @ Feb 12 2004, 10:30 AM)

Ok cool, I think I'm getting it now. Another thing (TestDialog) you have <rect t="10" l="10" b="30" r="100" /> <Text>Test</Text> <rect t="50" l="10" b="70" r="100" /> <Text>Exit</Text> Onscreen they both look the same size but the B values are different. How's that work. Is it like B is the bottom edge of the Box in relation to the top of the screen?

rect
l = left
r = right
t = top
b = bottom

In relation to the dialog window...

I'm restricting the methods for setting position because I figured ActionScripters won't be as sloppy as other users  otherwise, I'd have included width and height.

What we need is a handy-dandy dialog designer.

[Yuyu]

QUOTE (BenJeremy @ Feb 12 2004, 09:52 AM)

What we need is a handy-dandy dialog designer.

Hey Geniusalz, please, get your a$$ over here and get us a dialog designer...

Well after your mid-terms are over of course (mine start next week)

[geniusalz]

Cool, next week is off for me (reading week, it's called)

[flattspott]

Don't know if you were already planning it geniusalz but may I suggest that you incorporate the dialog designer into MXM Skinner rather than making a whole new progam.

[geniusalz]

Or rather, a branh off from skinner.