World: r3wp

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?

pass ...

Ah, you fix one problem only to discover a bigger one! Anyway I've 
uploaded build#89 which addresses the two specific issues above:


1) Clicking the close button on a window now forces an unfocus but 
*without* triggering the on-unfocus action (or a show).


The /close refinement of display must now return true or false to 
proceed or not with the close operation.


2) Clicking a button only fires its action if it is not the current 
focal face and the focal face's on-unfocus action returns true


Try these with the test code posted above. You should see that it 
now behaves as you would expect. But now try the following code:

	display "" [
		field
		calendar
	]


Click on the field and start to type, then click on the calendar 
and continue typing! Why does this happen? It happens because when 
we detect the 'down event we have no way of knowing whether it originated 
from the field or the calendar. %display.r *should* be able to have 
a detect function that (among other things) does a:

	if all [
		find [down up alt-down alt-up] event/type
		face <> view*/focal-face
	][
		code to check on-unfocus
		code to do an unfocus
	]


but this will not work because of a view bug that causes face to 
be the window face *not* the face that originated the event. Urrgh. 
At this time I can't see how to trap and process mouse click focal 
changes. Might have to delve into the VID sources again to see how 
(if) it was solved there.