World: r3wp

Unfortunatelly, before it was fully finished, RebGUI got some api 
changes, and I am not sure how long would it take to adapt.

It was RebGUI only ....

and you can find it in the widgets folder. It is just not included 
in the demo.

that helps bigtme! thanks!

I hope it should not be a problem to adapt. IMO Cyphre would do it 
in one day, but let him work on R3 :-)

Robert also said, he has extended table widget. Don't remember exactly 
what was added, maybe horizontal scrolling ...

easy to have hidden fields in the table widget

I normally put all my hidden columns in at the front of the table 
options definition

and assign them a width of .001 which does the trick.

where is the widgets folder? On the website?

http://trac.geekisp.com/rebgui/browser/widgets

I tried the .001 trick..That might surfice. Thanks Graham!

I found grid.r on trac.geekisp. How do I download the script from 
here? I've tried to cut and paste but hte line numbers come along 
with it. And how do I use it with rebgui?

download - we all use TortoiseSVN, which you can install as an Explorer 
extension to Windows. Then via right mouse button context menu you 
choose -update, and point it to svn archive - you can find link somewhere 
on rebgui site.

thanks

and as I said - grid.r will not work imo. There were some changes 
in rebgui and someone would have to adapt it.

I can eventually send you a source, if you want.

It is a pity, as it it light-years more powerfull than table, which 
is just - plain vid list, with column resizing, nothing really more.

what is the last version of rebgui that it works on?

I will check if I have such one, and send you email eventually. I 
switched jobs inbetween, so dunno if I have it here.

but I sent it to Graham, maybe he might to send it to you ...

OK, I've got it .... checking your email ...

sent to your email I found here in your altme profile ...

Pekr, I got your email, thanks. I'm unable to get the tests to run. 
getting an error.

what version of View are you running? I run 1.3.2.

also note - you have to have rebgui.r in your app directory, as it 
is used by grid.r

the rebgui file does no seem to be formatted properly. Its all one 
long line.

it is ok, that is how ti was distributed in the past - packed

I'm using view 1.3.2.3.1

I'm running he test app with grid.r and rebgui in same directory. 
Do  I need to "Do" grid.r?

yes ...

ah, no ...

I just looked, it only does rebgui.r, because grid.r is part of the 
package ...

I will try to send it to you in .zip archvie ...

maybe mailer did something to it

sent ...

Bingo! it works. Thanks for all your trouble!

ah, super! Now how to get it working with latest version of RebGUI 
:-) Also note, that docs are very brief, so most of the functionality/features 
are hidden in source code ...

Looks like trac.geekisp.com/rebgui is down ...

as is www.geekisp.com

Regarding my boundary issues with rebgui and the area widget, this 
is what happens


If I am typing at the bottom of the screen and the scroller bar is 
shorter than the scroller height, and the bar is placed up against 
the top, then entering a return places the caret at the head of the 
current line instead of at a new line.

If I move the scroll bar to the bottom of the scroller widget, <return> 
then it does move to a new line.

There are no problems if the scroll bar occupies the whole of the 
scroller widget.

make object! [
    code: 902
    type: 'internal
    id: 'stack-overflow
    arg1: none
    arg2: none
    arg3: none
    near: [unless find [object! block!] type?/word get]
    where: 'into-widget
]

re: boundary issue. Is this the same "issue" as:

	display " [
		area "a^/b^/c^/d^/e^/f^/g^/h^/i^/j^/k"
	]


Then click on the first line to position the caret next to the "a". 
Now drag the scroller down and observe how the caret position changes 
to remain visible. Is this behaviour correct? (BTW, an answer of 
"No" raises a whole bunch of other issues).

well, it's not the behaviour I'm observing.

Any resolution ?

I can only reproduce the behaviour you describe (boundary scrolling) 
with the test case posted above ... and in that case it's a "feature" 
not a bug. But the situation you describe is different in one important 
respect ... it doesn't insert a newline. Do you have a simple test 
case which demonstrates this? (It might be a combination of a certain 
area size, font-size and number of lines).

rebol []

do %rebgui.r

display "" [
	a: area 100x150

]

do-events

Now paste the sentence you wrote above 7 x into the area box ...the 
caret stays between the n and a in combination.  The scroll is not 
at the bottom.  Move the caret down one by using the arrow keys, 
and hit enter.  The caret moves to the beginning of the line instead 
of creating a new line.

After I arrow down and hit enter I get a newline as follows:

demonstrates ...
|area ...
area ...


RebGUI build#95 with default ctx-rebgui/behaviors (I deleted %ui.dat 
first to be sure).

oh well ...