World: r3wp

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.

Yeah, I just got around to testing this and no dice. Ctrl & Shift 
work with function keys though. If you want to see what other combinations 
work then you can use the following script (based on %keycodes.r 
that someone wrote years ago):

	insert-event-func func [f e] [
		all [e/key print [mold e/key e/shift e/control]] e
	]
	print ""
	view layout [text "Start typing"]

So, we can include code to assign the control/shift function keys?

Yes, I'm adding this to the next build.

Build#92 uploaded to SVN. Adds event support to function code handlers 
as follows:

	ctx-rebgui/on-fkey/f3: make function! [face event] [
		prin "f3 "
		if event/control [prin "Ctrl "]
		if event/shift [prin "Shift "]
		print ""
	]

This is going to be tricky.  Have to create some intermediate function 
to then call the appropriate function ( normal control or shifted 
)

is it possible to have progress as a part of the UI, not separate 
window? (as with Calednar)

ah, request-progress uses progress widget, forget it ....

Build#93 released and available. Includes all fixes from builds#83-93 
plus a new on-edit action handler. Release notes available here:

	http://www.dobeash.com/RebGUI/release.html#section-9

on-edit is like a dirty? face  ?

Yes. Technical difference between it and on-key is that on-key is 
called prior to keystroke processing, whereas on-edit is only called 
if the keystroke actually changed the text (including a change in 
capitalization ... i.e. it does a strict-not-equal? comparison).

.

Doesn't seem to be able to highlight text going from right to left 
( it loses it instantly ).  Only works reliably from left to right.

Huh? Are we talking about highlighting in general or a specific widget/case?

I think I see the problem.   If you highlight from right to left 
in a field, where the word you are highlighting is left aligned, 
then if your mouse pointer leaves the widget, the highlight disappears 
immediately.  If you highlight from left to right in a field, where 
the word is left aligned, you are more likely to stay within the 
widget, and the highlight sticks.  if however, your mouse drifts 
outside the field, it will also then lose the highlight.

Also, the caret should move to the beginning of the word you are 
attempting to highlight