World: r3wp

table: We have extended TABLE to allow horizontal scrolling. You 
specify the number of visible columns and the rest can be scrolled.

it should be part of the widget

how about just adding a disable flag to the button and put a disable 
check in the engage event?

I wonder why noone picks-up on cool grid element :-) Pity API changed, 
so it does not probably work ....

but that doesn't change the visuals ...

Graham - it should, but as an interim solution I welcomed even such 
hack. I refuse to visually remove buttons, according to some conditions. 
That sounds scary, when once there is button, next time there is 
not button at certain position :-)

ghosting out the buttons etcs

well, if buttons are not functional in certain states ..

perhaps better to remove them both visually and functionally?

Well, I am going to try it both ways and see what the users say

Graham - http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=disable-face.r


i have not thought about RebGUI integration yet, not sure it is applicable 
...

Maybe Ashley could have quick look into it? It could be functions 
of RebGUI. But I agree that in fact it should be done in consistent 
way = adding such handlers to each style, so not sure Ashley would 
accept such "hack" into RebGUI ....

When you click in to a text area, the caret always appears at the 
end of the text.  Possible to have the caret to appear at the mouse 
pointer?

Otherwise have to double click

its in 'focus,
  if not caret [caret: tail face/text]
somethig with 'offset-to-caret. anyone? ;)

oops, its rebgui. may be diffferent there.

display "" [ p1: panel 20x20 green data [] false do [ show p1]] do-events

Why does this not show the panel ?

It looks like 'show does not work inside a 'do block

if the widget was hidden

This works showing text in a visible widget .. 


display "" [ p1: panel 20x20 green data [] false return f1: field 
do [ show p1 set-text f1 "panel should be the
re!" ]] do-events

Neither the field or box will display


display "" [ p1: box 20x20 green data [] false return f1: field false 
do [show [ p1 f1 ]]] do-events

Trick is to remember that the do block is evaluated prior to the 
display being shown, so you just have to use:

	display "" [
		p: panel green data [] false
		f: field false
		do [p/show?: f/show?: true]
	]
	do-events

Thanks

but isn't the layout constructed first otherwise the variable names 
would not be available?

Yes, but doing a show or hide prior to view doesn't work.

Ok.

in lists and tables, scroll bars appear dynamicallly

Is it feasible to do the same for area widget?

The reason most UI's dont do this is you either have to reserve space 
for the slider, leaving an empty area, or dynamically readjust the 
text to fit ... which annoys users as the number of lines changes 
on them. So, no. ;)

Ashley - well, how often there is the change of text size, so that 
there is, or is not the need for slider? ;-) Once?

How about using Chris' script to support input-patterns: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=filtered-import.r

How do you get a slider to react to the mouse wheel?

move the wheel?

I'm pretty sure mouse wheel support is implemented.

Yeah, it's not reacting.  I've tried forcing focal-face, no effect. 
 ??

I've tried a custom widget with an  action: make default-action [ 
 but I might be missing
something simple but critical...

From what I can understand from other widget code, say area...the 
on-scroll is sent to

the area...I need it to go right to the slider for the scheme I'm 
attempting...  Umm, I think...

You have to do it indirectly, as in:

display "" [
	p: panel data [slider] on-scroll [
		var: face/pane/1
		var/data: var/data + either negative? scroll/y [-.1][.1]
		show var
	]
	do [system/view/focal-face: p]
]

Ashley;  Thanks.

Works nicely.  Need to build the boundary fences, but works nicely. 
 Thanks again.

New error for me ..


An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 501
    type: 'access
    id: 'not-open
    arg1: "Port"
    arg2: none
    arg3: none
    near: [repeat i p/cols [
            line/pane/:i/offset/x: col-offset 
            line/pane/:i/size/x: p/widths/:i - sizes/cell 
            all [
                p/pane/2/show? 
                i = p/cols 

                line/pane/:i/size/x: line/pane/:i/size/x + (p/size/x - p/pane/2/size/x 
                - (line/pane/:i/offset/x + line/pane/:i/size/x))
            ] 

            line/pane/:i/text: replace/all form pick p/data index - 1 * cols 
            + i "^/" "¶" 

            line/pane/:i/font/color: either find p/options 'no-action [
                black
            ] [
                either find picked index [white] [black]
            ] 
            col-offset: col-offset + pick widths i
        ]]
    where: 'confirm
]

Well, that looks like the face-iterator logic (used by table and 
text-list) ... any idea what was being done at the time (i.e. table 
just about to be displayed, row double-clicked on, etc)?

None of those as I recall.

Build#95 uploaded to SVN. Contains new 'on keyword and request-char 
function. 'on is used to specify multiple action handlers at once, 
as in:

	display "" [
		field
		field on [
			scroll [print scroll/y]
			focus [print "Got here!"]
		]
	]

%tour.r updated to demonstrate new request-char function.

Ashley;  How hard would it be to allow set-path! for widget variables? 
 Or am I missing

something that would allow widget variables to be held in an object!? 
 I'm fairly prone
to missing things  :)

You mean something like:

	b: "Bob"
	display "" [a: field b]

which is already supported, or something else?

No I mean something like

fields: make object! [
   a: b: c: none
]

display "Test" [fields/a: field  fields/b: field  fields/c: field]

No [to supporting that]. The preferred approach would be:

	obj: make object! [
		a: "Bob"
		f: does [display "" [field b]]
	]
	obj/f

typo "field b" -> "field a"

Thanks Ashley.

Would pathes help? I think the change to support that could be small.