World: r3wp

Give it the widget's face and no matter how deeply embedded the widget 
the "window" it is in will be closed. Avoids having to do unview/only 
face/parent-face/parent-face type operations.

I use this for that

unview-window: func [ face 
][
    unview/only find-window face
]

Henrik, parent-face is managed by the native code, so there's something 
definitely wrong if it does not work for you.

The question is what that would be. But I have noticed way too many 
times that parent-face is NONE for faces that should be set up properly, 
particularly in VID, but apparently also in RebGUI.

parent-face can only be none if the face has never been shown, which 
may happen if you access it during layout and before the face as 
been shown.

ok, that may be it.

I do recall that parent-face doesn't work during INIT in VID.

Gabriele is correct. PARENT-FACE is not set by LAYOUT, it is set 
by SHOW. I wrote some code which needed to know the parent-face before 
SHOW was used, so I did something like initialize the PARENT-FACE 
of every face in the face hierarchy myself.
I wanted LAYOUT to do this by default.

Would it be easy to patch layout to do this?

I've tried, but the problem is that LAYOUT is not necessarily used 
recursively and thus doesn't always have a parent-face to use.

If you have something like this

b: button "text" on-click [ print face/text ]

you can't call the button action like this

b/action/on-click b


because the on-click action refers to 'face, and 'face is not passed 
when called this way.

What's the appropriate workround apart from using named faces ?

eg. on-click [ print b/text ]

Hmm.. perhaps face is passed

How to get the color of a button?


button/color seems to return none always even though it is set with 
set-color ...

button color is controlled via draw block, not face/color.

display "" [ bt: button "Test"  button "Set color" [ set-color/no-show 
bt green probe bt/color ] button "Set Color2" [ set-color bt red 
probe bt/color]] do-events


so we can see that the bt/color is set to the right color, 'show 
is then called and bt/color is then set to none :(

this gets the color


display "" [ bt: button "test" green button "Color?" [ probe pick 
 bt/effect/draw 14  ]] do-events

What's the rationale for preventing windows with duplicate names 
from opening?  It seems to be a cause of a major bug with window 
handling.

Eg. If you have an app, and open a window1, and from that open window2, 
and then close window1, then window2 also closes but can never be 
opened again.  Removing the duplicate window title check seems to 
fix that bug.

Havn't hit that bug before, will try and reproduce. Rationale for 
this behaviour is simple: users click a button multiple times and 
open multiple instances of the same window. Coding this check manually 
is a pain ... but if you want this ability then having unique window 
titles is easy.

I presume that when you close the parent the child is still hanging 
around or something

even though it appears to disappear

It shouldn't. Perhaps it's behind another window?

Nope ..  definitely not.

Following seems to work for me:

display "test" [
	button "W1"  [
		display "w1" [
			button "W2"  [
				display "w2" [text "test"]
			]
		]
	]
]

display "main" [ text "this is some text" button "child" [ display/parent 
"Child" [ text "close this window" button "grandchild" [ display/parent 
"Grandch
ild" [ text "topmost windo"]]]]] do-events

close the window that says "close this window" and then try to open 
all the windows again

The grandchild window will not open again.

http://screencast.com/t/y0PwDD9JBYoshowing this behaviour

so must be the use of display/parent that is different

Can't reproduce using build#117 or 218 on Mac. Perhaps it's a Windows 
(7?) specific issue?

how to add dynamically data to the tree?

face/data or SET-DATA doesn't work for me here...

I don't think you can.

oups!

sure?

can change the data, no rebind,init or whatever to display the new 
data?

what about the accessor functions? BUILT-TREE etc. any change via 
this?

oki, looks like a static piece. thx graham...

Is there a way to monitor all events ?  In vid you can do 'insert-event-func 
but in Rebgui we have this system/view/screen-face/feel: none	; kill 
global events system (used by 'insert-event-func)

You can comment out that line without causing any harm [to RebGUI].

I did and started getting lots of errors!

Odd, I just tested with b117 and ran tour.r without a problem.

We're running different builds I guess

I am using build 117 (public) for creating a reservation application. 
I noticed a tremendous slow down on hovering above buttons created 
at the beginning, but hovering at the buttons created at the end 
is fast. Here is a code sample:

REBOL []

do %rebgui.r
seat-layout: copy []

loop 16 [
	insert tail seat-layout compose/deep [panel 50 data []]
	for row 1 15 1 [
		foreach col [A B - D E] [

   insert tail last seat-layout compose/deep [button 7x5 blue (rejoin 
   [row col]) [alert face/text]]
		]
		insert tail last seat-layout [return]
	]
]

display "test scroll panel" compose/deep [
	calendar 
	scroll-panel 152x100 #HW data [after 4 (seat-layout)]
	calendar
]
do-events

If you move your cursor quickly over the calendar on the left, it 
will leave a trail while focusing, it gets worse when you try to 
select a button in the scroll panel. But the right calendar is not 
affected.

Strangely, when you scroll the panel to bottom right, everything 
is back to normal in that condition, but when you scroll back to 
top left, things are the same again. Any hints how to fix this?

This trailing hover problem is not visible in build 218, but I need 
drop- and edit-list for my app, and these two are broken in b218. 
Thanks for the help!

On a Mac, no problem. On WinXP it appears that the events are being 
generated faster than they can be processed. Good test case, I've 
never seen this before! ;)


I don't have an immediate fix, but this is one more reason for me 
to get the 2.x series released. Are drop- and edit-list the only 
roadblocks for you?

eh?? Is RebGUI alive again?

Depends on how big the roadblocks are. It's easier to fix *-list 
than port the 2.x event handling back to 117! ;)