World: r3wp

Then run the following:

	display "" [
		f: field
		field
		button [set-text/caret f "X"]
	]


Click in f, type some text, click or arrow to the middle of the text 
and press the button. Text is inserted at caret.

not for me

still requires a tab to set the caret position correctly

Hmm, maybe there are other changes at play here. Let me upload latest 
build ...

Build uploaded.

So, running the text above I click into f, type "ab", press the left 
arrow key once and then the button. What I see is an "X" inserted 
between letters "a" and "b" (i.e. "aXb") with the cursor positioned 
between the "a" and "X". Is this what you see? Is this "correct"?

Or do you expect the cursor to be positioned between the letters 
"X" and "b"?

doesn't matter

Huh?

but if you now move the cursor to the head of the text, and click 
button, it still inserts as before.

I guess the caret should be at the end of the inserted text

and this mirrors what happens when you type

the face/caret is not being updated when you click inside the text

OK, Mk III

	unless string? face/text [exit]
	either caret [
		if all [
			face = view*/focal-face
			view*/caret
		] [face/caret: index? view*/caret]
		either face/caret [
			insert at face/text face/caret form text
			view*/caret: at face/text face/caret + length? form text
			face/caret: index? view*/caret
		] [insert tail face/text form text]
	] [insert clear face/text form text]

sorry ...

no better

I type "ab" ArLeft and press button to get "aX|b"
the ArLeft, ArLeft and press button to get "X|aXb"

Is this what you get?

No

let me resync a new directory

I get aXXb

|aXXa

a|Xb

|aXXb

Ah, my fault. I didn't sync the above change.

I did

I put mark III in

>> checksum read %rebgui.r
== 14063079

Uploaded. I still get the same, working, result.

PeterD, you win tie breaks it seems ;)

Rebol isn't indeterminate

I get 16618006 for checksum ??

Same here.

not me .. and that was a fresh checkout :(

and create-distribution.r

I still get aXXb

ok, same checksum, let's try again

Do a search on "build: " on %rebgui.r ... it should come back with 
"build: 87"

REBOL[version: 87]

Hmm.  Now works as Ashley's does :)

We have a winner!

:)

Looks very good!!

passed all my tests so far

Works OK, I forgot to reload rebgui

in the excitement :)

time to take a break .. later.

Just got this error from an area widget:

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'max
    arg2: 'value1
    arg3: [number! pair! char! money! date! time! tuple! series!]
    near: [view*/caret: offset-to-caret parent-face min max]
    where: 'on-click
]

I'm putting a  gui-error/continue around the caret handling in area

Build#88 uploaded to SVN with major caret/focus fix. This fixes numerous 
problems related to clicking out of a field/area with focus. To be 
on the safe side, I've left the caret and current-word traps in place 
for the moment. Please delete your %rebgui.log files and report any 
further occurrence of these types of errors (after upgrading to build#88 
that is). Lucky build number to solve this with too! ;)

Couple of deep design questions. Run the following code:

display "A" [
	button [
		display "B" [
			f: field on-unfocus [false]
			button [print "Click"]
			do [set-focus f]
		]
	]
]


1) Click the button to open display "B" ... type some text, then 
click the OS close button ... then try the same thing again.


What you should see is that you can't enter any text the 2nd time. 
This is due to the fact that the 2nd time set-focus is called it 
fails to unfocus so is left in limbo. Not sure what to do about this 
case.


2) Run the sample again. Click button to open display "B" and click 
the button.


Note that the button's action fired as clicking a button does not 
shift focus (i.e. you can click a button and continue typing in a 
field). The question is: even though we are not tabbing out of the 
field, should the button's action have fired. This question becomes 
even more relevant when the button action does something like open 
a new display (or close the existing one) ... should this action 
be allowed to proceed even though there is a failed unfocus action 
pending?