World: r3wp

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?

does Alt work? (for menu)

and I buy a beer to person, who makes ctrl tab, and ctrl shift tab 
working (tab widget) :-)

Also, cursor key to change focus on buttons

yes ....

In the spell checker, the word you were checking used to remain high 
lighted even if you clicked on one of the suggestions ( I think ). 
 Now it doesn't;

Any chance of capturing control and shift Function keys?

 I certainly don't want to have 36 function key handlers, but enhancing 
 the function key handler spec to support refinements should be easy 
 enough; so:

	make function! [face] spec

becomes:

	make function! [face /control /shift] spec

does Alt work? (for menu)
 ... see http://www.rebol.com/docs/view-system.html#section-5.9

Short answer, no. But if R3 supports it I will.

the same goes probably for ctrl plus tab, no? IIRC it is not captured 
by Rebol at all ...

who makes ctrl tab, and ctrl shift tab working

 ... easy enough to trap these keystrokes. Figuring out what to do 
 with them then is the tough part!

Also, cursor key to change focus on buttons

 ... yep, keyboard focus control is one of those long-standing issues 
 I'd like resolved. But mouse issues come first for me (i.e. until 
 the focus/caret/mouse system is 100% I'm not interested in enhancing 
 the keyboard focus system beyond basic tab support.

Ashley - really? ctrl plus tab is trappable in rebol view engine?