World: r3wp

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 ...

Just tried it again with the rebgui.r on the rebol desktop

same bug

says build #93 though

tried again with build #95 - and problem still is present.

this is a fresh checkout

I took a screen video of what I am seeing http://compkarori.no-ip.biz:8010/index.php?title=Unrelated_Software_Resources&token=1184580090#attachForm

http://compkarori.no-ip.biz:8010/Unrelated_Software_Resources

If you couldn't see it, the server got reassigned another IP address 
and so port forwarding failed :(

I downloaded it (476Kb) but under both Quicktime and VLC it appears 
as a large gray rectangular area for about 11 seconds!?

Hmm.  Works find under Vista for me.  I'll see if I can convert it 
to another format then.

I don't have anything to convert it .. but it plays fine on Vista. 
 I've uploaded it again in case it got corrupted.

No dice. Anyone else able to download and view it?

It worked with Totem Movie Player on my Debian box

and Brian, are you able to reproduce the bug demonstrated?

Yes I can.  Moving down from inside "combination" to the period, 
then pressing return does NOT insert a newline.  I'm using build 
93.

Thank god someone else sees this bug!

Ah, got it! I tried it again but without inserting a return after 
each copy and I see the problem (finally). It's actually inserting 
a return at the tail of the text then repositioning the caret to 
the start of the next line. The 2nd half of that operation is correct. 
Will debug this soon.

it onl happens if the scroller is not at the bottom of the scroller 
widget

Got a simple test case for this now:

	area 20x14 "a^/b^/c^/d"


Position the caret after the letter "c" or "d" then press Enter. 
The caret is repositioned incorrectly.

easier than my video !

Any progress?

Hoping to look at it over the weekend.

Great.

Anyone any experience with dual monitor setups?  user tells me that 
this happened after  he moved app from one monitor to next

make object! [
   code: 316
   type: 'script
   id: 'no-memory
   arg1: none
   arg2: none
   arg3: none
   near: [show face
       orig-size: face/size
       exit
   ]
   where: 'wake-event
]

Looks like a View error to me.

I have some experience here, but View apps simply worked. Multimonitor 
set-up means, that you basically have one big area, where axis x= 
axis x(1) + axis x(2), axis y = max (axis y(1), axis y(2))

in the past, there was bug in View (not sure it was fixed, but someone 
told me so), than once you changed resolution in OS, View app crashed 
...

I used nVidia cards exclusively, hating ATI. So, I had defined accelerator 
keys for moving windows from one monitor to other, typicall ctrl 
alt num1 (or num2). That worked with AltME and other View based apps. 
I have also some Win32 wrappers to do so - resizing, window z-axis 
positioning, setting window position, etc.

Uploaded area caret positioning fix to SVN. "Fix" was to comment 
out Anton's code in the area widget that kept the caret inside the 
visible part of the area. This changes the behavior of area and may 
have other unforeseen consequences (i.e. fixing one issue may have 
created another).

my dual monitors are on dual nVidia cards, i.e., 2 identical cards: 
is there something I can help test?

apparently there is no problem with shifting an encapped app from 
one screen to another.