World: r3wp

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.

It is like VID list style - the worst ever - you work with exposed 
variables you don't have normally the chance to know about (from 
the VID style perspective pov) - I consider it being very bad design, 
wrong ecapsulation.

I don't understand what is 'dirty's purpose, but imo clicking Quit 
button, which clearly maps to native 'quit function, should simply 
quit, nothing else whatever else you have set. The only case would 
be, if I would put some sensor transparent face upon button to catch 
events, or something like that.

Can RT please release RebCmdView for 1.3 ... Thanks.

my observation is, that even if I change my design to view/new, I 
still have to use the dirty-flag trick ...

and dialog box system seems to be still rather messy. I changed my 
design to view/new. I have two layouts, plus insert-event-func, which 
can show another dialog box (help screen) after F1 is pressed, from 
both windows I use. But - once there is my help displayed, and I 
alt-tab to the window 2, unview/only that window does not work ...

I have found very shortened example - simply the case, when you redefine 
layout several times - maybe it is wrong aproach, but because of 
grid I always called layout once again, to fill-in list value by 
data:


view lay1: center-face layout [btn "lay2" [view/new lay2: layout 
[btn "Return" [unview/only lay2]]] btn "close" [unview]]


now run above line, press lay2 button, go back to first screen, press 
lay2 button. It gets re-rendered. Try to press "Return" button on 
lay2 - it does not work anymore ...

is that because of nested layout? Is that becuse I re-define lay2 
in memory for the second time and it confuses rebol?

I think that I redefine lay2 for the second time, so that rebol looses 
reference to the first one, and so unview is not able to unview first 
instance of window ...., so maybe actually my bug, not rebol's? :-)

in this case, move lay2 a bit ;) it gets not re-rendered, its a new 
window. lay2 now points to second lay2. you close that. you see the 
first window (but looks the same.. you unview lay2, but thats now 
the second, closed lay2, not the first you are really viewing.

ah, you typed while i typed, yes, correct.

hey guys, we have some gfx gurus. What about some splash screen content? 
Today I made small util using rebol and my friends in office were 
really happy about it - I exported telephone list from Lotus Notes 
client monster and put it into View 1.3, rebDB plus Cyphre's my-list. 
They suggested me to add some nice splash screen and to send it to 
Lotus Notes team to show them we don't need LN for such tasks :-)

I know that sometimes very little is needed to produce nice effects 
...

cross-fade in tests? fade ln-logo to rebols :)

I can find some nice demos in section of Desktop, but I am not sure 
I would succeed to adapt e.g. Imagination for my help screen - besides 
that, it is longer than my whole tool :-)

fading demo seems to be short. maybe create images with imagination 
and fade between them?

what do you mean by fading?

two images before each other, the first turning into the second by 
alpha-effect.

its in desktops test-folder

Pekr>Try to press "Return" button on lay2 - it does not work anymore 
...


It still works back in View 1.2.47... (I'm sticking with this version 
for a short time longer.. )

as Cyphre suggested to me privately - first instance of lay2 looses 
reference to the window, as it is regenerated during second button 
press. But that "face" remember its parent face. Try to replace unview/only 
lay2 with unview/only face/parent-face .... the question is, if that 
is a bug or not - should we be able to create such wrong code using 
VID?

I am starting to think, that it can't be considered a rebol bug, 
but a programmer bug. In such case though, ppl have have knowledge 
about windowing system, how it is organised in pane, etc., so View 
internals - knowing just VID will not be enough ...

... that setting "f/dirty?: no" in my complaint above is another 
example, that something is wrong here ...

button press should work no matter what other UI element state is. 
The only case where I can understand button not working would be 
if you would put some transparent face upon it to catch events ...

later

I guess you produce something like that by switching layout. usually 
both is called, the text-action because of dirty, then the button-action. 
but somehow view forgets to call the button when you switch layout 
and call focus. maybe because the layout with the button is not visible 
after the text-action? its a bug for me, but i guess it could be 
tricky to fix, lots of special case-code.

petr: it's not a trick. dirty? is there by "design", and it is handled 
by a event func. you need to handle it manually in cases like that. 
so, not a bug, just lack of proper documentation.

How do you make a shadow effect for a face, like Cyphre does in its 
menu style ?

So ignoring the button press in this special case is not a bug?