World: r3wp

if you highlight some of the text, and press the button, the alert 
works, but if you type in the 'area and press the button, it doesn't

I think part of the problem is that the index is not moving for the 
highlight, when you insert text into the string, so you would have 
to manually move the index for highlight start/end.

and of course when you start typing, there is no highlight anymore.

right, but if you type and then highlight

if you click and hold the drop down, so that focus isn't lost, does 
it work?

the 'choice isn't what I was focusing on, but if you highlight part 
of the area, then use the choice, and press the button, the alert 
works, but if anything is typed, then highlighted, the system/view/highlight-start 
and end are set to none

in the choice, you are copying a new string into the textfield. that 
destroys the relation to highlight-start and highlight-end

but what effect does typing have?   I type something, I highlight 
it, I would expect that highlight-start and highlight-end would be 
set when I actually do the action with the mouse

oh! interesting.

sorry, but you are giving me a lot of ideas for the VID Extension 
Kit :-)

but I notice that the field is unfocused, before it crashes. that 
would be why.

how does it get unfocused?

investigating

That's good! :)  Things need more extension.   I just hope that there 
is a easy enough solution so I don't scare my friend away from REBOL

unfortunately, text editing is deeply broken and too simple in VID. 
I'm hoping to fix this.

ok, try this:

view layout [area button [probe system/view/highlight-start]]

and try typing and highlighting and click the button

it should show the same thing.

I don't have a fix for now, but I'll keep this in mind.

when you say the same thing, what do you mean?

The first time (when the console pops up) it is set to none, but 
after that it will work alright

Thanks for looking into it

when I type and then highlight without changing the focus, and then 
click the button, the field is unfocused and the highlight is none. 
this actually seems like correct behavior, although you would want 
to retain the highlight.

try it more than once

yes, I did. there is clearly a pattern there.

I didn't even know about  'local-request-file

Doesn't work everywhere, though - 2.7.6 on Ubuntu Hardy:
>> local-request-file []
** Script Error: Feature not available in this REBOL
** Near: local-request-file []

read this link:       http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg12381.html
but in my REBOL, 2.7.7.3.1

'local-request-file always returns 'true and 'false,   what does 
this mean.

local-request-file is only available for Windows and Mac ... and 
the Mac version supports a subset of the functionality available 
on Windows (e.g. no multi-item selection). Two simple examples of 
usuage:

	open-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Open" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false false]
			join third path first fourth path
		]
	]

	save-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Save" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false true]
			join third path first fourth path
		]
	]

Floyd-Steinberg dithering:
do http://box.lebeda.ws/~rebolek/rebol/dither-fs.r
Not the fastest thing around, I know.

R3? It complains about map!

>> do http://box.lebeda.ws/~rebolek/rebol/dither-fs.r

Script: "Floyd-Steinberg dithering" Version: 0.0.1 Date: 30-Jan-2010

** Script error: invalid argument: [0.0.0 63.63.63 127.127.127 191.191.191 
255.2
55.255]
** Where: make catch either either applier do

** Near: make map! [0.0.0 63.63.63 127.127.127 191.191.191 255.255.25...

Ah, I'm testing it under 2.7.7

I'll change it to hash! that should be OK then.

ah, ok. I don't use 2.7.7 as I have a big project that relies on 
2.7.6 and don't want to mess it up.

Reuploaded and tested under 2.7.6

cool it works. what do you mean by "slow"? :-) well, it was done 
when I came back to the desk.

I think you should post it on rebol.org as an educational script.

Good idea, I'll improve it a bit and post it.

the BW version is quite fast... good enough for print preprocessing 
 :-)

facet question http://synapse-ehr.com/forums/showthread.php?15-REBOL-DOCUMENTAION-suggestions-for-improvement/page2#post133

Posted a response.

This "with	The with block allows you to specify any other type of 
face characteristic using standard REBOL object format."


is therefore incorrect as it does not allow one to set the offset.

http://www.rebol.com/docs/view-guide.html#section-78

it's not incorrect. it's specifying offset alright. it's just being 
overridden later in the face setup during layout. :-)

one could imagine an additional layout mode, where the cursor doesn't 
move, and therefore the offset from 'with would be applied correctly, 
but really, 'at is the shortest option to type of all.

I would have thought the layout engine sets the offset before it 
sees the 'with ...

it does so internally for the cursor, but the cursor position is 
not applied to the face until after the specs are in place.

VID was a revolution at the time of its invention .. but we hope 
that it will be soon superceded by R3 GUI  and we won't have to worry 
anymore :)

yes, true

Few languages can lay claim to inventing new ways of doing things 
..  we just still need to prove it's viable :)