Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Weirdness with Request boxes

 [1/7] from: sunandadh:aol at: 4-Feb-2002 20:59


I'd assumed that the various Request-xxx View words were modal. But they aren't -- or at least not intuitively. Try the following for some odd results. unview/all view layout [ text white "Date" [print ["date" request-date]] text white "File" [print ["file" request-file]] text white "Color" [print ["color" request-color]] text white "List" [print ["list" request-list "title" ["A" "B"]]] button "clear boxes" [Print "code to clear the boxes"] ] Experiment 1. Click once each on Date, File and Color. Although you can get all three boxes up, you can only action or dismiss them in the order you invoked them. And you can only get one of each. Experiment 2. Try clicking three times on List. You've now got three separate list boxes on the screen (you need to move the top one to uncover the others). None of them returns a result until all three have been clicked. Then you get all three at once. Other combinations give equally unsettling results. This has some obvious downsides for a user interface. Normally, if I put up a request box of this sort, I'd expect it to be modal. Or, given that it isn't modal, I need some way of telling that its time has passed and clearing it from the screen. That leaves me with two questions I can't answer: 1. Is there any easy way to ensure the Request boxes *are* modal? 2. Is there any way I can check if any Request boxes are active and then cancel them and the thread that was waiting on them? (i.e. code to go into the "clear boxes" button -- and code that should go after a Request to flush out any multiple instances) Any ideas? Thanks, Sunanda.

 [2/7] from: rotenca:telvia:it at: 5-Feb-2002 12:00


Hi Sunanda, - Are not modal for other modal panels. - Someone said some time ago they are buggy. - Open modal faces are listed in system/view/pop-list which is a block - The active modal face is in system/view/pop-face The RT code which use them at every event: system/view/wake-event: func [port /local event no-btn][ event: pick port 1 if none? event [ if debug [print "Event port awoke, but no event was present."] return false ] either not pop-face [ do event empty? screen-face/pane ] [ either any [pop-face = event/face within? event/offset win-offset? pop-face pop-face/size] [ no-btn: false if block? get in pop-face 'pane [ no-btn: foreach item pop-face/pane [if get in item 'action [break/return false] true] ] if any [all [event/type = 'up no-btn] event/type = 'close] [hide-popup] do event ] [ if pop-face/action [ if not find [move time] event/type [hide-popup] do event ] ] none? find pop-list pop-face ] ] --- Ciao Romano

 [3/7] from: g:santilli:tiscalinet:it at: 5-Feb-2002 13:18


Hello [SunandaDH--aol--com]! On 05-Feb-02, you wrote: S> I'd assumed that the various Request-xxx View words were S> modal. I think that was the intention, but /View (or maybe it's just VID?) seems to have problems handling modal windows. IMHO, it's best to avoid modal UI at all; when that is not possible, you should "disable" (or close) the "parent" window while showing the "child" (modal) one. A simple way to disable a window is to put a tansparent face that covers it at the tail of its pane. (I usually apply an effect such as GRAYSCALE to show to the user that the window is disabled.) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [4/7] from: rotenca:telvia:it at: 5-Feb-2002 14:43


Hi Sunanda,
> That leaves me with two questions I can't answer: > > 1. Is there any easy way to ensure the Request boxes *are* modal? > > 2. Is there any way I can check if any Request boxes are active and then > cancel them and the thread that was waiting on them? (i.e. code to go into > the "clear boxes" button -- and code that should go after a Request to flush > out any multiple instances)
I forgot to say what is my strategy for this problem: i use view/unview wrappers which check the pop-list pop-face fields and then do what i want, like to hide-popup all popup before opening the new window or open a popup window instead of a normal window or deny any new window until any popup is open. Up to date I have not problems with this. --- Ciao Romano

 [5/7] from: rotenca:telvia:it at: 5-Feb-2002 14:55


Hi, Gabriele,
> I think that was the intention, but /View (or maybe it's just VID?) > seems to have problems handling modal windows.
The problem, if it is a problem, is in View and event handling.
> IMHO, it's best to avoid modal UI at all; when that is not > possible, you should "disable" (or close) the "parent" window while > showing the "child" (modal) one. A simple way to disable a window > is to put a tansparent face that covers it at the tail of its > pane. (I usually apply an effect such as GRAYSCALE to show to the > user that the window is disabled.)
I' d not be so drastic. I use it extensively without problems with already open windows. I'd say that RT does not give us all the logic we need, we are free to make some strange things, but we can also not to make them. It is to us to check things before doing. I'm speaking of using directly show-popup/hide-popup, not of request-xxx (which i do not know well, because i do not use). --- Ciao Romano

 [6/7] from: sunandadh::aol::com at: 5-Feb-2002 12:22


Hi all, thanks for the various replies. Gabrielle, I'm with you on modal operations: I want as few of them as possible. Romano: thanks for the pointers. I guess I'll be exploring show and hide popups next. Sunanda.

 [7/7] from: g:santilli:tiscalinet:it at: 7-Feb-2002 21:05


Hello Romano! On 05-Feb-02, you wrote: RT> I' d not be so drastic. I use it extensively without problems RT> with already open windows. I think that non-modal designs offer interesting advantages, both for the user and the programmer. But that's just IMHO! :) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/