Post by: BenJeremy on February 06, 2004, 06:16:00 PM
This is a very rough first pass, and far from complete. How about helping me out with suggestions and notes?
Post by: geniusalz on February 06, 2004, 09:47:00 PM
Will it behave pretty much like notepad? I guess it will need horizontal and vertical scrollbars (unless text wrapping is implemented).
An easy way to navigate the text is required (shift+up/down/left/right). When switching lines, the cursor should maintain it's horizontal position (you can probably figure out how to do this; I couldn't)
Copy paste can also come in handy, introducing the issue of selecting text (other shift button, possibly)
I'm saying this all because the multiline control can serve as the basis for a very useful text editor.
As for the tree control, I assume the internal workings will be similar to XML structures. Could serve for an XML editor (of course it won't be needed anymore, but that's another story
)I guess listboxes can also work as menus within scripts (possible option to hide the scrollbar)
'Visible' is one of the more useful attributes of controls IMO, and should be accessible from scripts.
Other enhancements (like captions for checkboxes) can probably wait.
I don't really know how menus would work, but I'm assuming they will be similar to the system menu. Nothing much to say about that.
I was thinking of a download manager too, that can do preview videos, savegames (haven't looked into too much detail for that), skins, etc
And the installer is useful as well (can check on startup for archives present in the installs folder, or have the user select 'install' from the actions menu)
I guess we need dialogs for selecting files/folders, as well as some predefined messageboxes (yes/no, ok/cancel, etc)
That's about it for now
*long post, but relatively non-rambling
Post by: ub312g0d on February 06, 2004, 10:01:00 PM
Post by: BenJeremy on February 07, 2004, 03:43:00 AM
| QUOTE (geniusalz @ Feb 7 2004, 02:47 AM) |
| A few things about the multiline text control: Will it behave pretty much like notepad? I guess it will need horizontal and vertical scrollbars (unless text wrapping is implemented). An easy way to navigate the text is required (shift+up/down/left/right). When switching lines, the cursor should maintain it's horizontal position (you can probably figure out how to do this; I couldn't) Copy paste can also come in handy, introducing the issue of selecting text (other shift button, possibly) I'm saying this all because the multiline control can serve as the basis for a very useful text editor. |
Well, some of the logic is in place for the multi-line control - the key part is the "carat" - the cursor seen in the Sinle line edit control (and what you see currently when using StringEdit in AS.
I get locational information of where the Carat is from the text drawing routines and can draw the carat as well (since the font drawing routines know exactly where to put it).
The big question is how much work it will be to add scroll bars, position the text, etc...
| QUOTE |
As for the tree control, I assume the internal workings will be similar to XML structures. Could serve for an XML editor (of course it won't be needed anymore, but that's another story ) |
Yes... I might be able to create a derivitive control that looks at an XML node and provides click-access to the specific node or element.
| QUOTE |
I guess listboxes can also work as menus within scripts (possible option to hide the scrollbar) |
Well, that's what the menu will be for. The main thing for pick lists will be things like a skin picker (I plan on supporting the ability to pick which skins will be displayed, and if more than one, you will be able to see them randomly appear on each startup (only the ones you chose, though).
| QUOTE |
'Visible' is one of the more useful attributes of controls IMO, and should be accessible from scripts. |
Yes, there are, of course, generic attributes that I left off the document.
| QUOTE |
Other enhancements (like captions for checkboxes) can probably wait. |
Hmmmm... actually, it's probably a good idea to include that now. It shouldn't be that hard to throw in there.
| QUOTE |
I don't really know how menus would work, but I'm assuming they will be similar to the system menu. Nothing much to say about that. |
You can see how the menus will be set up by looking in the internal.xml - I hope to switch over to that soon.
| QUOTE |
I was thinking of a download manager too, that can do preview videos, savegames (haven't looked into too much detail for that), skins, etc And the installer is useful as well (can check on startup for archives present in the installs folder, or have the user select 'install' from the actions menu) |
Good ideas.
| QUOTE |
I guess we need dialogs for selecting files/folders, as well as some predefined messageboxes (yes/no, ok/cancel, etc) That's about it for now *long post, but relatively non-rambling |
MsgeBox will have support for buttons and icons... there will also be some other 'common' dialogs like OpenFile, SelectPath, etc...
Post by: BenJeremy on February 07, 2004, 03:45:00 AM
| QUOTE (ub312g0d @ Feb 7 2004, 03:01 AM) |
| wow, this reminds me soo much of vb its insane, but for a good reason I suppose. How about adding a picture box so that icons and the such can be used as well. I assume that the radio buttons would be able to be put in a control array as well. |
Yes, I will have to include an Image control.
Also, you'll notice the GROUP attribute on radio buttons. This will be a unique identifier for each button.
Since the data will be maintained in an XML node, you'll be able to associate just about any data with an individual item, too... should be handy to avoid complicated switch statements when a radio button or listbox item is selected.
Post by: BenJeremy on February 07, 2004, 05:39:00 AM
I will try to continue updating it. As I am working on these controls now, please add your concerns and ideas here "ASAP"
Post by: geniusalz on February 07, 2004, 09:58:00 AM
Is it possible to refer to them (and get the selected values) through names?
e.g.
MenuGetValue variable !.Configure.Localization."Date Separator"
Or just specify non-numeric ID's?
Post by: flattspott on February 07, 2004, 10:06:00 AM
Post by: BenJeremy on February 07, 2004, 10:32:00 AM
| QUOTE (geniusalz @ Feb 7 2004, 02:58 PM) |
| Had a look at the menu. All the ID's are confusing me to no end (are they repeatable in different submenus?) Is it possible to refer to them (and get the selected values) through names? e.g. MenuGetValue variable !.Configure.Localization."Date Separator" Or just specify non-numeric ID's? |
Well, I haven't started using it yet, but I may change the "ID" (as M$ considers this a special attribute for XML) to something like MenuID and MenuItemID.
Actually, while menu IDs should be unique, individual item IDs don't have to be. The Item IDs correlate to menu IDs when the type is SUBMENU, as this is the ID it looks for to bring up the submenu.
I may still have unique menu item IDs for many items in the config menu, just because I can centralize the handler and then I can re-arrange the menus as I need to (much like Windows' command IDs)
Just now, I moved the msgbox logic into the new ActionScript UI logic. I'm now adding support for handler, which I would prefer be handled through ONE location in a given ActionScript. The interaction is unbelievably complex to make everything work smoothly, and I don't want to hose anything up. My first run with MsgBox hung the system
but after a bit of head scratching, I figured out what was messing things up.I may document the internal goings-ons for those that care.... let's just say the key word is "synchronization" - UI objects live in the main app thread, but actionscripts get their own thread.
Post by: BenJeremy on February 07, 2004, 01:35:00 PM
ActionScripts will have a single entry point for all UI objects "OnEvent <Label>" as anything else just gets very complicated.
Nothing is final on the document, either... so expect changes.
Post by: geniusalz on February 07, 2004, 02:17:00 PM
| CODE |
| |
Is the 'Config' node necessary? (Otherwise, the contents could be moved into the Control node)
Again, are non-numeric ID's acceptable?
Post by: BenJeremy on February 07, 2004, 02:39:00 PM
| QUOTE (geniusalz @ Feb 7 2004, 07:17 PM) | ||
The xml's seem a little 'clunky'
Is the 'Config' node necessary? (Otherwise, the contents could be moved into the Control node) Again, are non-numeric ID's acceptable? |
Yes, they do seem clunky, don't they. Feel free to take a stab at a decent dialog definiton and how it should look; I'll examine it and see if it fits what's goingto happen with ActionScripts and in use with internal MXM code.
As for non-numeric IDs, well, hmmmm... let me think about that. It's not a simple matter, and not efficient (though that may not be that much of an issue with UI objects)
Post by: geniusalz on February 07, 2004, 02:51:00 PM
| CODE |
| |
Alternatively, the type could go as the node name (might require some work to implement, though)
| CODE |
| |
Edit: On another note, isn't ENDCASE redundant? It could use the already-present CASE/ENDSWITCH commands to 'end case'.
Post by: BenJeremy on February 07, 2004, 03:11:00 PM
I'd prefer to at least keep the CONTROL node, because it's easier to parse them in proper order that way.
Post by: geniusalz on February 07, 2004, 03:18:00 PM
Switch 5
CASE 1
blah
ENDCASE
CASE 2
blah
ENDCASE
CASE 3
blah
ENDCASE
ENDSWITCH
What I'm saying here is that instead of looking for an ENDCASE to end the 'block', look for a CASE or ENDSWITCH statement, like this:
Switch 5
CASE 1
blah
CASE 2
blah
CASE 3
blah
ENDSWITCH
Post by: geniusalz on February 07, 2004, 03:20:00 PM
| QUOTE (BenJeremy @ Feb 7 2004, 08:11 PM) |
| I'd prefer to at least keep the CONTROL node, because it's easier to parse them in proper order that way. |
You do know that excessive typing is not good for health
Well, if it can't be done without major rework, then let the Config node stay.
Post by: BenJeremy on February 07, 2004, 03:47:00 PM
| QUOTE (geniusalz @ Feb 7 2004, 08:18 PM) |
| It's even redundant (sort of, not from a technical perspective, but logically) in the other case 'blocks'. Switch 5 CASE 1 blah ENDCASE CASE 2 blah ENDCASE CASE 3 blah ENDCASE ENDSWITCH What I'm saying here is that instead of looking for an ENDCASE to end the 'block', look for a CASE or ENDSWITCH statement, like this: Switch 5 CASE 1 blah CASE 2 blah CASE 3 blah ENDSWITCH |
Oh no.... that's not right.
ENDCASE forces execution to jump to the ENDSWITCH statement.
If you leave out the ones in your example, execution will proceed through the other case statements. This is on purpose, as you can provide multiple cases for a single block of code.
| CODE |
SWITCH %something% CASE 1 CASE 2 blahRed ENDCASE CASE 3 DEFAULT blahBlue ENDCASE CASE 4 blahGreen ENDSWITCH |
Even the above example has a problem... can you guess what it is? But the example is also to show that in the case of 1 and 2, blahRed will get executed. 3 and everything else, blahBlue will get executed.
Post by: BenJeremy on February 07, 2004, 03:50:00 PM
| QUOTE (geniusalz @ Feb 7 2004, 08:20 PM) | ||
You do know that excessive typing is not good for health Well, if it can't be done without major rework, then let the Config node stay. |
Oh, the config node can go, but naming the nodes after the control type is a bit of work.
I parse out nodes, in code, by calling something like this most of the time:
pXmlNode = pParentNode->GetNode("control", iIndex++);
It gives me a pointer to the "nth" node named "control", depending on the value of index - unless there are no more left, in which case it gives me a null pointer.
Post by: geniusalz on February 07, 2004, 08:07:00 PM
)Sorry about that
And I think the problem is that default should go at the end, otherwise even %something% being 4 will cause it to go into default.
Post by: BenJeremy on February 08, 2004, 04:05:00 AM
| QUOTE (geniusalz @ Feb 8 2004, 01:07 AM) |
| Right. It's just me thinking in terms of VB again (no break required; multiple cases can be done like so: Case 1,3,5,7) And I was reading CONFIG instead of CONTROL (even though it was capitalized )Sorry about that And I think the problem is that default should go at the end, otherwise even %something% being 4 will cause it to go into default. |
Correct on the default issue (though I hinted that in the message
).I updated the plug-and-play spec as well as the UI late last night. Things are still evolving as I put more pieces in place.