Dialog Stack Design Questions
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: 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 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. 3) Some other approach. Any advice? I know I could use either one and make it work but I looking for best practice advice. Thanks! Len Morgan ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dialog Stack Design Questions
What kind of dialog boxes do you needing to show? My personal take is that dialog boxes should be kept as simple as possible, and therefore the built-in answer and ask commands cover about 90% of my needs plus a small number of separate stacks for the remaining more complex ones. Ian On 20 Feb 2008, at 13:58, Len Morgan 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: 1) A separate stack for each dialog. 2) One dialog stack with multiple cards (one for each dialog). 3) Some other approach. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dialog Stack Design Questions
Hi Len, First I have to say that I try to minimize dialogs use. In many cases, I use a group on the current card but with a darker background because, as a user, I hate to have hundreds windows, all different, that show up and have to be closed as you can see them in MS Word for instance. I reserve 'external' dialogs for alerts only. And I never use 'Ask' because I want to master the kind of data I let the user enter in any entry box. All my users seem pleased with this way of doing that is based, before everything else, on a deep ergonomic study. Now if you want to make many dialogs showing up, I would recommend to pay attention at each window layout to make them a 'real family'. About using a single stack or several, I don't think that file size is now a problem and, above all, different stacks make reuse later easier in any project. Le 20 févr. 08 à 14:58, Len Morgan a écrit : 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: 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 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. 3) Some other approach. Any advice? I know I could use either one and make it work but I looking for best practice advice. Thanks! Len Morgan Best regards from Paris, Eric Chatonet. Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/ Email: [EMAIL PROTECTED]/ ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dialog Stack Design Questions
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 use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dialog Stack Design Questions
Len and Robert: Another solution is to designate one card in your stack as the dialog card, title it Information, and place a field, a Cancel button, and an OK button on it. Then place the dialog information into the field by script as shown below. This method is very flexible and conserving of resources. global theOK on linkClicked -- linked text in this particular case put 2 into theOK put into field Info of card Information go card Information wait while theOK = 2 with messages if theOK = 1 then go recent card -- occurs when the user clicks on the OK button on card Information end linkClicked In the OK button on card Information include the handler: global theOK on mouseUp put 1 into theOK end mouseUp --- On Feb 20, 2008, at 7:32 AM, Robert Brenstein wrote: 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. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dialog Stack Design Questions
Thanks to everyone for their responses. It appears that: 1) There are MANY ways to handle dialog boxes (I knew that before) 2) The is NO best way to do it. I guess Rev's blessing of flexibility can also be a curse! :-) len ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
