World: r3wp

Gosh. Was the old code an attempt at direct pane programming ? Is 
the standard LIST performing ok ?

The standard list has a few problems, notably in that you are forced 
to update the entire listview, when you want to refresh a single 
entry. That makes it slow for mouseovers.


The old code was much faster at scrolling and doing mouse overs as 
I could have full control over which part of the list I wanted to 
show, but everything was done manually, but it was not direct pane 
programming.

but the standard list is very elegantly done and allows you to have 
a simple iteration function. It's a bit too simple, but then again 
I can't find proper docs on doing LIST with SUPPLY

(but I seem to be using the word 'but' a lot)

All, FYI, I found out my "save" problem was not setting my words 
to "[]" before a load. SAving was working...the viewing was not! 
When will I remember that little thing about Rebol.

I'm trying to make a button behave like a text field, but I can't 
make it work.


view layout [b: button "Hello" with [flags: [field input return text]]]

what's missing?

the right feel?

could be...

Try:
layout [f: field "Hello"]
probe f/feel

volker, geomol, thanks! it was correct

I've been playing around with Frank's paint.r in the library.  I 
implemented a free hand draw tool but found that a simple line or 
circle takes about 32k of draw instructions :(

I wonder if there's a more efficient way to do this than combining 
lots of line draws together?

It's a simple problem of polling frequency. Try changing the code 
so that a new point is not placed unless it is more than (say) 4x4 
away from the previous point.

I see. I noticed also that the DRAW function adds
	PEN pen-col FILL-PEN fill-col LINE start offset
for every new point, when what is necessary is only new offsets.

I suggest to add an OLD-TYPE variable, and put something like this 
in the DRAW function:
	either all [type = 'free-hand type <> old-type][
		; add all the initialising stuff (PEN FILL-PEN, LINE start)
	][
		; otherwise compose in nothing
	]

So when you change from circle to free-hand, DRAW adds the initialising 
draw commands, but after that, just adds an offset.

Ooops, I should have checked for type = old-type so we can add the 
single offset. Anyway, you get the idea. Just move that condition 
inside the either true block.

hmm... how do I set the default entry in a CHOICE at layout time? 
I wanted to do something like this:

view layout [choice "1" "2" "3" with [data: next face/data]]

hallo, alls... i have a question regarding view events...  i am testing 
using the following code, which creates two text fields, one of which 
only accepts numerical input...

view/new layout [
    the-field: field feel [
        engage: func [face action event] [
        	if action = 'key [
			if all [ greater? (to-integer event/key) 47
				 lesser? (to-integer event/key) 58 ] [
				 append face/text event/key 
				 show face 
			]
		]    
        ]
    ]
    new-field: field
]
focus the-field
do-events

first question, is how can i get the first text field to accept mouse 
click events?  how then do i get it to recognize the tab key to switch 
focus to the next field?

also, can i update the position of the text curser in the number 
field so that it is the current position being typed at? (bad wording, 
i know... )

robert, what happens in the above code is that you replace the original 
feel functions with one ENGAGE function. that's why you loose normal 
field functionality

is there an alternate way i should be doing this?

you need to copy in the original feel from a generic field face into 
your new field along and then add your code to its existing engage 
function

it's a bit of a hassle...

try:

probe get in new-field/feel 'engage

that's the original code

that's the code you need to alter...

thank you, i will try that

you can copy it out into a separate function, which could be called 
ENGAGE-FUNC and make you alterations.


then you can initialize a normal field with a new ENGAGE function 
in your layout:

the-field: field with [feel/engage: :engage-func]

this will leave the remaining feel functions untouched

Henrik, your choice problem. I think, you have to redefine choice. 
The problem is in the multi/text function. You can do it at layout 
time this way:

view layout/size [choice "1" "2" "3" with [multi/text: func [face 
blk] [if pick blk 1 [face/texts: copy blk]] text: "2"]] 400x400

It's better to make your own choice with your own multi/text function.

using styles for example.

thanks, I'll give it a try...

http://polly.rebol.it/test/test/extend-engage.r

I want to save my draw commands to a text database field.

is this the only way

form compress mold data  ?

the question really is, is there a native way to compress blocks 
as a string value ( for saving into a text field )

by molding them

does molding save space though?

that's what I am doing above, molding and then using using compress

no, but then you have a string. then you can compress. then you can 
write/binary .

text field .. can't save as binary.

i overlooked text-field, only saw saving.

why do you want to do that, compressed in a field?

because the field is varchar(8192)

and data is being transmitted over tcp, so good to compress first

a sql-field, not a face-field?

you can use 'as-string instead of 'form. but i know no better way 
that "compress mold".

sql field