World: r3wp

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! ;)

Ashley, that would be very cool. But with b217/8 I also experienced 
another strange thing when popping up a window on button click. Sometimes 
some texts in the window are blank, sometimes it's displayed correctly. 
The window consists of several panels, fields and buttons. It's reproducible 
consistently, I'm trying to make a sample code for this.

This don't happen in b117 (the same code, except I had to replace 
'question' to 'confirm' and 'ctx-rebgui/layout/only' to 'layout/only')

After an exhaustive testing, by luck I found out the problem. It 
was the table. The bug is pretty strange tough. Here is the test 
case:

REBOL []

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

for slot 1 16 1[
	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]) [display "test" [text "see me?"]]]
		]
		insert tail last seat-layout [return]
	]
]

display "test scroll panel" compose/deep [

 table options ["id" left .2 "name" right .8] data [1x2 "A to B" 3x4 
 "C to D" 5x5 "E to F"] return 
	calendar 
	scroll-panel 152x100 #HW data [after 4 (seat-layout)]
]
do-events

If you run the code, clicking any button will show a new window with 
the text "see me?". But once you select the first table entry, clicking 
on the button will show you an empty window. The only cure is to 
hover on the second or third entry. Hovering is enough to fix the 
not drawn text problem.

But once you start clicking on the calendar, the text will be hidden 
again. Another hovering on the second or third table entrywill bring 
it back again. This only happens to text and fields. Text in buttons 
are not affected.

I found another problem with b218: when there is a spinner style 
in display, the confirm and alert requestor's button do not works:

display "test scroll panel" [
	myspinner: spinner options [$0 $10 $1] data $5
	button "confirm" [confirm "yes/no works?"]
	button "alert" [alert "OK works?"]
]
do-events

Sorry for reporting only bugs, I like the 2.x series so much, it's 
much faster, no slow scrolling, I do really hope this version gets 
stable and usable. Currently it's the only usable GUI for me with 
nice graphic.

Here I found another bug with the text-list style. When your list 
is longer than the box (means you have to scroll), deleting the item 
at the bottom caused some calculation mismatch in redraw. This don't 
happen when you start deleting from the top. Here is the test case:

do %rebgui.r

display "test scroll panel" [
	tl-rute: text-list data [ "a"  "b"  "c"  "d"  "e"  "f"]
	button  red "-" [
		if tl-rute/selected [
			remove find tl-rute/data tl-rute/selected
			tl-rute/redraw
		]
	]
]
do-events

Delete "f", then delete other items, you will start to see "none" 
displayed in the list. This don't happen if you start by deleting 
other than "f" items.

usually there are methods to do this ..  certainly there is for table/remove-row 
n

RebDOC says nothing about deleting rows in text-list. Yes there is 
add-row and remove-row in table.

But the table in 2.x has the habit to prevent drawing text :-), that's 
why I moved my code to text-list, avoiding tables.