World: r3wp

Yes and yes.

Ok.

And before you ask, back-porting just the scroller is not viable.

I erased that response I was about to make!

Back to your request-value prompt wrap issue ... I just tried it 
under WinXP with build#212 and I get 3 wrapped lines of text. Does 
your requestor have a big blue question mark icon in the top-left 
corner?

Yes

Are you on WinXP, Vista or Win7?

Looks like the scroller issue goes back a while .. I tested the version 
where you had the color changes and that is also fast.

Windows 7 RC1

let me check the source ..

Yes, it is request-value

But you must have just changed it ... as it now wraps

let me show you the older version

Ahhh.. can't use 'editor anymore.

Try request-edit instead.

** Access Error: Cannot open /C/Rebol/rebgui/icons/16x16/actions/document-new.png
** Where: load-icon
** Near: icon: load file

Does tour.r work for you (it needs the same icons)?

yes

Different dir?

http://screencast.com/t/BEp7A32PY7

Yes.

the icons are loaded each time from disk?

Ah.. no icon at top left.

Yes, I probably need to inline them (in %rebgui-images.r).

That rebgui was just one build earlier ...

My main screen was ViD based as it used a toggle widget .. and then 
the rest was rebgui

So, the improved scroller code was from quite a while ago.

Loading off disk is bad!

All that for a toggle, you should have said something earlier! ;) 
BTW, the screencast shows a build#1nn widget (pre-gradient buttons).

It was written a few years ago and just recently revamped

Bottom line is the current request-value works the way you requested/expected?

And when I tried to port it to the latest build .. then I discovered 
vid/rebgui were no longer bed mates

Yes, latest is okay.

Hi Ashley, i would like ask you, are you thinking about auto-scroll 
in widget AREA, because of  i can not select text bigger than area 
size.  Cool example in VID has Didier Cadieu, see http://www.rebol.org/view-script.r?script=area-scroll-style.r&sid=ptn126rv

I made small CMS using Rebgui, so sometime i lack this feature :-)

I think it is importent feature in some apps processing text (medical 
notes, cms, blogs etc..)

Many times users use  "copy-paste"  method to carry large text:-)

Ashley - request-edit from RebDOC looks nice, it even scrolls, but 
it somehow misbehaves on my system. 

1) The Window could be smaller - does not even fit my 1280x800

2) When I try to resize it from the top, the window jumps around 
100pixels below

3) editing - only typing works ... e.g. hilighting by mouse does 
not work (strange, as it works for fields)
4) scroller misbehaves too ....

hmm, after RebDOC restart, hilighting works, but resizing still behaves 
strangely ...

I second Bobik's request - when I hilite text by mouse, I expect 
the area to autoscroll, to allow me to select more of text, not just 
the visible part ...

Autoscroll and request-edit issues noted.

Build 213
- layout moved to global context
- renamed request-edit to editor
- renamed set-enable to enable
- renamed set-disable to disable
- added in-widget function
- enable/disable now accept block of faces
- fixed arrow/list bug
- changed popup auto-hide from away to click
- fixed menu
- added toggle widget
- changed hard-coded green/red to use colors/true & false
- updated tour.r and RebDOC.r

Example usage of new in-widget func and toggle widget:

display "Sample" [
	field
	field

 button [set-text second in-widget face/parent-face 'field "Hello"]
	toggle green data ["A" "B"] [print face/data]
	toggle data ["AA" "BB"] options [on] [print face/data]
]

Toggle effect a bit mild.If there would not be 2 buttons on screen, 
I would not easily mean, if it represent pushed status, or let's-pus-me 
status, even if on/off text is available ....

- menu and lists - much better behaviour with auto-hide on click. 
One small note to menu - if you have one branch opened and you move 
to the sibling, it should not require click to have the first one 
closed, and open the one under the mouse pointer. But current behaviour 
is accpetable enough, it is just if we would like to have OS exact 
behaviour ...

- editor (and not only editor) - I can see that when hilighting, 
REBOL is not doing it all that correctly. Try to open editor, type 
in few lines (or just paste some text in there), and then try to 
mouse hilite. It works, but stops to hilite, when you move your mouse 
out of current window region. It should work even outside, at least 
it is what OS does. Open Notepad to compare ... it should not be 
difficult to do, and would improve usability ...

- what happened to the tree-view? I can see I can't collapse it by 
double-clicking parent node in the tour.r, nor can I see arrows in 
there. Is it just not configured, or?

Ashle - changed your code above to allow disable. Try pressing first 
button twice. It crashes RebGUI:

do %rebgui.r

display "Sample" [
	field
	f: field

 button [set-text second in-widget face/parent-face 'field "Hello" 
 disable f]
	toggle green data ["A" "B"] [print face/data]
	toggle data ["AA" "BB"] options [on] [print face/data]
]

do-events

error is near: "set-text second in-widget face/parent-face 'field" 
- maybe disabled face is somehow shifted from parent-face, so that 
it can't be found in subsequent call?

btw - error windows could have some "copy" button, or allow text 
copying by mouse-hilighting, or it is difficult to get the error 
message - you have to write it down somewhere else ...