On 20/02/08 at 07:58 -0600 Len Morgan apparently wrote:
I'm wondering what is the "recommended" way of handling a lot of
dialog boxes in applications. There are a couple of way of handling
this that I've thought of but I don't know what would be considered
"best:"
There is no single best solution. All depends on a number of factors.
1) A separate stack for each dialog.
Pros: Sizing, function (information only, getting user input,
etc) can be implemented without worrying about it's effect
on other dialogs.
Cons: You need the basic "stack overhead" repeated over and over
for each dialog
You can have a common library stack which handles common functions,
so each individual stack has only stuff that is unique to it. In this
approach you indeed keep multiple stacks loaded in memory, but
nowadays this is seldom an issue. If you need to show one dialog on
top of another, this is the only approach.
2) One dialog stack with multiple cards (one for each dialog).
Pros: Single stack overhead (smaller file size)
Cons: Every time a dialog is opened, the correct card has to be
selected and then the stack has to be resized for that
particular
dialog.
Which card to open can be passed through the dialogData property.
Resizing can be done by having size (and possibly location) stored in
a custom property of each card and set in the preopencard handler. If
you need dynamic sizing of dialogs, peek at the scripts in the answer
stack provided with Revolution.
3) Some other approach.
Similar to 2) but instead of cards, you can have controls for each
dialog kept as groups that you show and hide. Since some elements can
be shared, so it makes this a tad more compact than 2 and eliminates
switching cards. Resizing/positioning works same as in 2).
Any advice? I know I could use either one and make it work but I
looking for "best practice" advice.
You can mix and match the approaches. If you have a few similar
dialogs, you can use approach 2 or 3 for them. For dissimilar dialogs
stay with 1. Whatever fits best your programming style and the logic
of your program.
Robert
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
