World: r3wp

ok, thanks

Henrik, you use feel/engage to catch mouse events. You can use the 
VID style KEY to catch key events. No need to put focus on box and 
remove cursor.

I tried that and it only works when you focus the box on purpose

view layout [box red feel [engage: func [face action event] [print 
action]] key #"k" [print ["Key 'k' pressed!"]]]

Try click the box and press key 'k'.

yes... by clicking the box, you focus it :-)

ehh, not as the function 'focus' does. There's no cursor visible.

but I needed to set the focus from within the code and before volkers 
solution I couldn't do that with turning on the cursor

:-) Why do you need to set focus on box in code? It'll get the events, 
when the user press the box.

but the user doesn't press the box, because it's layered below other 
faces

And you make it get events by setting focus on it? I didn't know 
that.

I would have thought, that it was something about feeding a new event 
into the system with the face as a target. That is: creating a entirely 
new event and feed it into the event system.

I have multiple buttons in my layout, but need to catch keyboard 
events at all times for global keyboard shortcuts. that's why I wanted 
to focus the box from within the code.

Why not just use the VID KEY style for global keyboard events?

(Sorry if I ask too much.) ;-)

because I don't know how to use that...

it's mostly a matter of stumbling onto things that work and not the 
best or most efficient way of doing things

Ok, I've found, that using key #"<some key>" is a fine, clean way 
of catching keyboard shortcuts. A key style get the keyboard event, 
no matter what other style is in focus (unless it's a field of some 
kind of course). The key style can get small, LARGE, <ctrl>-keys, 
arrows and F-keys.

Just a hint, if you can use it.

It was a bit wrong saying: "no matter what other style is in focus". 
Most styles are not in focus like that. They get events. Putting 
a style in focus mean, it's ready for some text input. Using VID's 
key style puts an event filter high up in the event system, so keyboard 
shortcut events can be filtered, before the styles further down the 
event-system get the events.

Geomol: actually, there is a reason to focus a face without having 
a caret in it; for example, if you have two styles that can be controlled 
by the arrow keys in the same layout. VID's keycodes are global and 
detected at the window level, which isn't always a good idea.

Aha! I've never used focus this way, but I see the point.
(Then I learned something today too.) :-)

view layout [b: box red feel [engage: func [face action event] [print 
["box" action event/key]]] key #"k" [print ["Key 'k' pressed!"]] 
do [focus b]]

A couple of questions: Is there a switch to start view in the console 
mode (CLI)? I know I can do something in the user.r but I'd like 
to do it from a prompt on demand. And also, anyone have any idea 
why my emails sent via a rebol program take so long to arrive. Any 
special settings in the header or hints. I 've created a program 
that sends emails to a list but I notice that it takes a long time 
(30 minutes or more) to receive the email. I checked by sending from 
Outlook and through the command line in rebol and it  was instantaneous. 
There's something happening and I wonder if any on you  have seen 
this.

james ... on the view desktop see menu User. The dialogue User Settings 
opens. On it there is a line "open desktop on startup"

Thanks Mike. Can this be done programatically? I mean when I start 
rebol, I use I call it from the command line. What I'd like is to 
be able do something like "view.exe -console" for example.

How about a script for that? only containing halt. then "rebol con.r".

Hmm. That's an idea. Thanks.

does View 1.3 allow modal windows? I mean - you want user to confirm 
something and you want him/her to block from access to backrgound 
windows of your app ....

view layout [ title "Modal Test" button "Alert" [ alert "Modal test" 
]]

main window can get focus, but at least it does seem to not being 
active event-wise ...

that's a bug .. that appeared in the betas.  Before that, the main 
window did not get focus.

ah, now I see - it is based upon 'inform and show-popup ...

so did anyone anything to focus/event system in betas?

huh?

You really are trying to make us read twice!

why? what did I say?

exactly. who knows?

I don't understand your logic then ... you said there is a bug, probably 
somewhere around focusing ... I asked, if someone did any changes 
in View for beta release?

well, that wasn't what you wrote.

However, I did file a RAMBO report on this issue.

second - you provided me with example .... using 'alert .... so I 
looked into alert (as I don't want just alert window, but my own 
window with some other elements, which will deny leaving focus to 
any of background windows), to see what is it based upon and so I 
just remarked that "the trick" is based upon 'inform function, which 
is based upon show-popup ....

http://www.rebol.net/cgi-bin/rambo.r?id=3801&

OK, then my english is twisted or I do post too many thoughts in 
parallel .... if there would be some ability to attach particular 
message as an reaction to another one, it would be clearer, but I 
am not sure there is any kind of "thread based" IM client around 
:-)

view a: layout [btn 200x200 [view/new/options layout [btn 100x100] 
reduce ['parent a]]]

you sure show-popup really blocked background windows in the past?

This is what you wrote "so did anyone anything to focus/event system 
in betas?"

I don't understand the question.

and yes, it used to stay infront of parent windows.

From memory, it changed behaviour around about March betas.

ok, I thought so, once you told me that it is not what I wrote. It 
is because of wrong translation into english, it should probably 
be - "so did anyone any changes in (for?, into?) focus system for 
(in) recent betas?" How should I write it correctly in english?