World: r3wp

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?

word you were checking used to remain high lighted

 ... by virtue of a focal-face bug. I eventually want to do the highlighting 
 with draw.

what to do is easy - at least in Windows (but I would expect mac 
and linux too), you switch tab focus ... ctrl shift tab goes in reverse 
order ....

Shift-tab (i.e. back tab) already does that.

shift tab? for fields etc.

really? ctrl plus tab is trappable in rebol view engine

 ... I think so. I already trap tab (via event/key) and control is 
 just a state (which is trapped elsewhere). No reason they shouldn't 
 work together.

but at OS level, when your dialog has tabs, and you want to navigate 
them using keyboard, you use either accelerator keys (we can have 
them, but unless rich-text is available, we can't underline accelerator 
key (the same goes for menu)), you use ctrl tab, ctrl shift tab, 
to change tabs (talking about tab widget) ....

Ah, you're talking about tab-panel tabs and focus ... I was talking 
about shifting focus with the tab key. Yes, it would be nice if that 
worked.

ctrl+tab is not trappable in Rebol (under Windows) at the moment.

Haven't we had this conversation like, 10 times ?

Anton - yes, and? :-)

ctrl tab was mentioned "by the way". But other hot keys can be fixed/added.

Ok, fair enough.