World: r3wp

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.

Oh this is just too funny. Found where it's "solved" in VID. %view-vid.r 
and the 'insert-event-func with the following comment:


;	!!! This next line is a hack, because we really need to know what 
face the event

 ;	is directed toward.  We need a way to get that info, but it's not 
 available here.

Anyway, try the following in VID:

	view layout [at 0x0 field at 0x0 btn]

Start typing, click the button, and then continue typing!

So, the conclusion is ?

Borrow the same hack from VID and hope http://www.rebol.net/cgi-bin/rambo.r?id=3867&
is fixed!

View-face is now gone from display.r

now called 'spec ...

It now reuses the spec word.

Build#90 uploaded to SVN with mouse focus hack borrowed from VID. 
Run this script:

	display "" [

  field on-unfocus [either (length? face/text) > 3 [true] [false]]
		button [print "click"]
		calendar
	]


Click in the field and type a character, then try clicking the button 
or calendar, continue typing and then click the button and calendar 
again.

can't keep up :(

with what?

all these changes!  :)

I'm hoping today's builds fix *all* outstanding focus/caret problems, 
many of which have been around for a long time now. ;) If that's 
the case then I'll do a public build and the pace of changes will 
slow.

I need an automated merge utility!

Anyway, whatever happened to release early, release often!

What do you need to merge, I thought I'd inlined all your changes 
by now?

custom widgets

error trapping in area.r for caret errors

extra ( redundant ) options in 'display

don't mind me .. just carry on :)

is it feasible to allow one to pick a symbol on the fly rather than 
defining in symbol.r ?

%create-distribution.r should make the widget merge pretty easy.

Recent changes hopefully make the %area.r caret error trap redundant 
(if not, I'll add that in with the next build)
What extra refinements do you have for display?

I wasn't clear on how to create borderless windows, so I added an 
options refinement to allow for that.

as in Vid

What do you set your options to?

let me have a look

[no-border]

It's just so i can create a clean screen capture with out the borders

re: symbol. You acn do that easily with:

	symbol "&" font [name: "Wingdings"]
	symbol 20x20 "&" font [name: "Wingdings"]

easy enough then

Isn't no-title what you're after then?

is no-title the same as no-border ?

The following works well enough:

	display "" [
		button [unview]
		do [face/options: [no-title no-border]]
	]

On windows, no-title replaces the windows title-bar and blue 3 pixel 
border with a 1 pixel black border. no-border in conjunction with 
no-title removes the black 1 pixel border. no-border does nothing 
by itself (at least on my WindowsXP box).

Except I was displaying a user's template ...

so, this way I guess I'll have to add to the user's form the do block

before I display it.

not a biggie.

Was there a no-hide refinement in the past ?

Yes, required by the old [rather dysfunctional] modal system.

I need to clean up my old source then!

About the only display refinement that's still specific to dialogs 
is, well, the /dialog!

The /scroll refinement has also gone as on-scroll lets you trap this 
at the widget level now.

I see that I had an alert based upon your old code but allowing for 
much more text ...hence the no-hide

So that leaves good, sensible refinements (I'd calss the ones that 
were dropped as "hacks" to get some other functionality working).

Is there a way I can make it so that escape always closes the current 
window?  Or, do I have to put a widget with escape as the key ?

Build#91 uploaded to SVN with inbuilt ESC handling. The processing 
 logic is:


1) If a widget has focus (e.g. an area or field) let it handle the 
ESC
2) If it's assigned to a widget then do the associated action

3) If a popup (including choose: drop-list, edit-list, menu) is active 
close it

4) Otherwise, treat the ESC as a close event (i.e. invoke close handler, 
check for app exit, etc)

Nice

Any chance of capturing control and shift Function keys?