World: r3wp

however main goal of rebGUI was to provide a cool widget enhancement 
library for VID propose a "example" set of widget people want to 
use the most in their software ( well that list of widgets can be 
found in any advanced graphical library such as GTK+ winap32 aqua 
QT WxWindows Tcl/tk etc...)

REbgui has in a background to show to that VID has many lacks (because 
no one really focus his attention only to design it. at least on 
teh VID2 version)  widget and event system could be simplier and 
provide more efficiency (less memory use more widget set ). REbgui 
was done in waste that's my own opinion

REGui wasn't done in waste that's my own opinion (damn i missed the 
n't ...on my previous lines)

>> display "" [ tree 45x10 options [resize] data [ "one" [ "4" "5" 
"6" ] ]] do-events
** Script Error: Cannot use path on none! value
** Where: show-tree

** Near: all [parent-face parent-face/action/on-resize/child parent-face]

Looks like resize does work if the tree is enclosed in a scroll panel.

This isn't strictly a Rebgui question ... but here goes.  I want 
to double click on a word and perform an action.  That action involves 
interacting with some gui elements on the current screen.  Now, there 
is a function 'hilight-text inside the rebgui 'edit object which 
is inside the rebgui-ctx context.  So, I can hook in there with my 
dbl-click function.  But how to make it call my function which is 
defined for each window?

I can create a global dbl-click-edit function, but since the widgets 
have names all made local, I can't effect the changes I want unless 
I make the widget names global as well.

Ashley, how about a refinement for display that opens a window relative 
to the current face ... so like /position

Define "current face". We could certainly do sometjhing like:

	display/relative-to face 20x20

yeah ... that would be good

That would allow popup menus where the mouse is.

Anyone done a request-calculator requester ?

You mean like the basic one in View/Desktop?

forgot about that one ... but yes.

Actually I was just thinking of allowing users to use a gui to enter 
numbers into fields ...but why not use a calculator requester for 
that?

You could make it a special field so if someone enters a literal 
("12") it doesn't do anything, otherwise ("10+2") it parses and evaluates 
it (perhaps putting "ERR!" in the field if the expression couldn't 
be evaluated).

The main thing I wanted was a way to input numbers using the mouse 
which is easy enough using a calculator layout.

Puzzle time .... I have this


add2script: has [ t1 ] [
    display/parent "test" [

        t1: table 40x40 options [ "item" left .99 ] data [ "one" ]
        on-click [
            either value? 't1 [
                alert first t1/selected
            ][
                alert "t1 has no value!"
            ]
        ]
    ]
]


Now if this is invoked by single-click on an element in a table, 
it's fine.  If I invoke by double-click on the table to invoke, it 
 gives the error.   If I remove the single click action, and allow 
it to be invoked on double click, then it is also fine.

however, I can't reproduce it outside my app yet.  
Now if I replace the above with 

add2script: has [ tl ][
    view/new layout [
        t1: text-list 100x100 data [ "one" ] [ print t1/text ]
    ]
]

then double click always produces two windows ...

but I don't get the error where the t1 variable becomes none!

Ok, I seem to have fixed the issue.  Changed my add2script to a closure 
from a function and no more errors.

Must be something to do with double click somehow ...

Anyway, this looks very promising at solving a lot of Rebgui issues 
I've had over the last few years... where I've clicked on a table 
row and the on-click function has collapsed because the face/selected 
path is not present.

I'd still like to understand and fix the base problem ... what do 
you mean by changing a function to a closure?

R2 has closures?

changing the above to
 
add2script: closure  [ /local t1 ] [
    display/parent "test" [

        t1: table 40x40 options [ "item" left .99 ] data [ "one" ]
        on-click [
            either value? 't1 [
                alert first t1/selected
            ][
                alert "t1 has no value!"
            ]
        ]
    ]
]

fixes it.

I use Ladislav's closure http://www.fm.tul.cz/~ladislav/rebol/closure.r

I got the idea to try this since somehow the local context was being 
clobbered.  So, creating a new context each time does solve the problem.

As I mentioned above, it is something to do with rebgui's double 
click handler.

Just did some checking on other functions that are invoked normally 
with a single click on a table row ... and so far they all have the 
same problem.  double click corrupts their local context.

But you can't reproduce this outside of your app?

Not at present.

I take it you've never seen this issue where locally named widgets 
lose their values?

Ashley, why is double click here producing two windows?

do %/c/rebgui9/rebgui/rebgui.r

nw: func [ ][

 view/new/offset layout compose [ label text (form now/precise) ] 
 to-pair reduce [ random 400 random 400 ]
]

display "Double Click Test" [
	table 40x40 options [ "Dbl Click me" left .9 ] data [ "one" ] 
	on-click [ nw ]
	on-dbl-click [ ]
]

do-events

this illustrates the problem.


do %/c/rebgui9/rebgui/rebgui.r
do http://www.fm.tul.cz/~ladislav/rebol/default.r
do http://www.fm.tul.cz/~ladislav/rebol/closure.r

nw: func [ /local lab ][
	view/new/offset layout compose [
		below 
		lab: text (form now/precise)
		button "show" [ probe lab/text ]  
	] to-pair reduce [ random 400 random 400 ]
]

nw2: closure [ /local lab ][
	view/new/offset layout compose [
		below 
		lab: text (form now/precise)
		button "show" [ probe lab/text ]  
	] to-pair reduce [ random 400 random 400 ]
] 

display "Double Click Test" [

 table 40x40 options [ "Func Dbl Click me" left .9 ] data [ "one" 
 ] 
	on-click [ nw ]
	on-dbl-click [ ]

 table 40x40 options [ "Closure Dbl Click me" left .9 ] data [ "two" 
 ] 
	on-click [ nw2 ]
	on-dbl-click [ ]
]

do-events

If you use the left hand table, and do a double click, then the "show" 
button will produce the same output in both windows.  Change it to 
a closure on the right hand table, and the "show" button now works 
correctly.

ie the local variable assumes the value from the second window, and 
loses it's own original value.

Rebgui's 'display function prevents the second window opening ... 
so I don't understand why the problem is still occuring.

foreach window view*/screen-face/pane [all [title = window/text exit]]

so 'display exits before it calls the 'layout function

Whereabouts is the color information for a button stored?  face/color 
is none so it gets set to none after the button is drawn.

Hmm.  Maybe the first window is not created before the second one 
is as the window creation is async. So, it does not find the window 
title in the pane, and so the layout function is called again.

You don't see this is in smaller apps because of the timing issues.

I see I have altered the display.r a little


foreach window view*/screen-face/pane [if title = window/text [return 
none]] ;; GC - always return a value

instead of using 'exit

Looks like this is the case... a print statement after this confirms 
the layout function is called twice on a double click.

Question about the table widget:
Can the label in column header be two rows ?
Like this:
Date
of purchase

no

Well, not unless you want to modify it.

:)

a print statement after this confirms the layout function is called 
twice on a double click

 ... as per documentation ( http://www.dobeash.com/RebGUI/user-guide.html#section-3.2.3
 ) "Every on-dbl-click event is preceded by an on-click event, as 
 shown in the following example: ..." But, the real problem here (as 
 you've discovered) is that the method for checking window uniqueness 
 relies upon a [title] string that only manifests *after* a layout 
 is substantiated. I suppose RebGUI could manage its own window title 
 cache, but then you introduce another point of failure (if the cache 
 gets out of sync with view*/screen-face/pane). I wonder if putting 
 a small wait value *before* the current title string test would "fix" 
 the problem (i.e. give the preceeding layout sufficient time to substantiate)?

I understand that a dbl-click always produces a single click action, 
but why do we get two windows popping up on  double click?