r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!RebGUI] A lightweight alternative to VID

Graham
23-Apr-2009
[7998x3]
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.
Ashley
23-Apr-2009
[8001]
I'd still like to understand and fix the base problem ... what do 
you mean by changing a function to a closure?
Pekr
23-Apr-2009
[8002]
R2 has closures?
Graham
23-Apr-2009
[8003x5]
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.
Ashley
24-Apr-2009
[8008]
But you can't reproduce this outside of your app?
Graham
24-Apr-2009
[8009x8]
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
Graham
25-Apr-2009
[8017x5]
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.
Vladimir
26-Apr-2009
[8022]
Question about the table widget:
Can the label in column header be two rows ?
Like this:
Date
of purchase
Graham
26-Apr-2009
[8023x2]
no
Well, not unless you want to modify it.
Vladimir
27-Apr-2009
[8025]
:)
Ashley
27-Apr-2009
[8026]
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)?
Graham
27-Apr-2009
[8027x8]
I understand that a dbl-click always produces a single click action, 
but why do we get two windows popping up on  double click?
That seems to me to suggest that the single click action is firing 
twice and not just once.
I'll try the wait thing and see if that works.
How about the display function not returning until it finds it's 
own window in the view*/screen-face/pane ?
Perhaps view needs a way to call a callback after it has substantiated 
the new window ...
puting a wait  0.1 before the window title check seems to fix it 
for me.
Except my application no longer works ... even with a wait as small 
as 0.001
can't see why that should happen.
Pekr
10-May-2009
[8035]
I am trying to adapt Cyphre's old grid to recent RebGUI requirements. 
I got myself past color adaptation, so actually I can get it displayed, 
internally it returns correctly API function results, but I need 
to adapt to event handling. I am facing two problems:

- editing, double-click etc do not work
- during some actions as resizing I get following error:

** Script Error: action has no refinement called on-click
** Where: set-data
** Near: face/action/on-click face


I looked into: help ctx-rebgui/widgets/grid/action, but those funcs 
are not set. Is there any need to set those function for particular 
widget? I looked at some other styles as e.g. button, but button 
is not using its face/action/on-click either, so I am a bit confused 
....
Graham
10-May-2009
[8036x2]
http://trac.geekisp.com/rebgui/browser/widgets/button.r
engage function seems to handle the click on the 'up event
Pekr
10-May-2009
[8038]
yes, but there is no code in grid, which calls on-click. My asumption 
is, that it is being called by rebgui internally for my widget. So 
I have to probably define it. Dunno. Most probably I am not able 
to proceed further. There is not clear description of that functionality.
Graham
10-May-2009
[8039]
which grid?
Pekr
10-May-2009
[8040]
Cyphre's grid. After Henrik's grid it is simply the most advanced 
REBOL grid and it is really stupid it was not adopted to new standard, 
waste of functionality and money ...
Graham
10-May-2009
[8041x2]
I seem to have a grid.r in my distro.
there's on on-key handler there.
Pekr
10-May-2009
[8043]
yes, but you use probably old Rebgui distro, no?
Graham
10-May-2009
[8044]
not the latest version
Pekr
10-May-2009
[8045]
I downloaded 118 and there is no grid. Grid was not adopted to new 
API IIRC.
Graham
10-May-2009
[8046]
I never saw the grid ever working.
Pekr
10-May-2009
[8047]
well, there is 'on-key, but it is not what is needed imo. Widgets 
do use abstracted widget/action principle ...