World: r3wp

I remember using insert-event-func to catch it on global level ... 
I have to find it - It was somewhere on rebolforces iirc ...

sensor #"^[" [unview]

should basically work loke closing on close-button - ah, i to late 
:)

what, ESC? :-) cool!

(you'll use unview/only, or unview/all ... whatever you need)

^(esc) works too

mroe readable maybe

*more

hmm, when I call quit from lay1, I get back to lay2, instead of quitting 
:-)

Hu? And you did not redefine quit?

no ....

I will try to shorten my example ....

Volker, it playing images wasn't my idea at the time. It's cool though.

try following?

lay1: layout [f: field [view lay2] btn "Quit" [quit]]
lay2: layout [text "just a try" btn "Return" [view lay1 focus f]]

view lay1

probe :quit  ; == native

enter something in the field, press enter ... press Return on second 
dialog, press Quit on first one - instead of quitting rebol, you 
will be brought once again to lay2

you are right...

so is that a bug or what?

interesting.

its the first time i see quit not quit. IMHO a bug.

Gabriele is guru of modal system ... hey Gab, what's happening here? 
Can I twist even so short code or is that a bug? :-)

I will RAMBO it ....

looks like a bug to me. try to make the example smaller first.

smaller? :-)

ok, will remove text ;-)

wanted to ask that too.. ;) removing focus?

maybe focus is the cause? :-)

They are not modal windows. But the modal handling has changed in 
wake-event, so maybe the problem is there.

focus does that ...

in RAMBO ...

going home, later ...

cu Pekr

Type something in the box, press enter, click return - and unfocus 
the field (like clicking on the window) and it shows lay2 again - 
looks like it's just viewing lay2 when the field is unfocused - which 
is before the button is clicked, right?

good observation. when i add a 'print in the quit-button, it shows 
that action is never called. so no quit too.

When a field is dirty? and you click on another button the action 
of the field is done. This is a side effect of system/view/screen-face/feel/event-funcs/1

I did not know View 1.3 will not work with W95??? I noticed change 
of filesystem accessor function calls, but I thought those will be 
somehow called on newer systems only. Lotsa of W95 machines still 
around. I wonder if W98 is affected too?

I have found Win95 machines to be kinda rare, but 98 and 98se to 
be pretty common - 95 seems to only be used on machines without Internet 
access in my experience.

I think RT could afford to drop support for Win95

or, leave 1.2 for Win95

A lot ot other companies have. Support for Adobe Reader left off 
at 5.0.5, Java at 1.3.1_11, etc. Even 98 is losing support, although 
98se still seems to be there for now.

Petr: romano's right, see also my answer to ticket.

i think Carl tested 1.3 on 98. i haven't though, so i'm just guessing 
it still works there :)

the interesting thing with Pekrs snippet is: yes, that action is 
done. but usually the dirty-action is done and then the button-action. 
in this case its not. due to the switching in the layout.

lay1: layout [f: field [
		probe "Dirty!"
		;view lay2
	] btn "Quit" [probe "Bye?"]]
lay2: layout [text "just a try" btn "Return" [view lay1 focus f]]
view lay1

enable the 'view and the quit-button is not called. Not sure if thats 
buggy enough to be a bug thought.

shouldn't the 'run function be part of /view.  Looks like it requires 
a license to be used.

Gabriele: I don't understand what Romano says. As a average scripter, 
I really don't care about some dirty fields or other dependencies. 
From code provided, it is clearly a bug, so - fix it.

'Run is not enabled in View.  It only works in IOS.

Gabriele - just looked at your fix - I can't consider it being a 
fix. It is like suggesting HTML coder to change something in DOM 
level.