World: r3wp

pekr: The highlight problem is because it only wants to refresh if 
it's not the same row as at the last read of the mouse position and 
if the delay time has been exceeded. sometimes this is not the case 
if you move the mouse too fast.

as for my console being slow, it's much slower than other windows 
users report...

Henrik: it's not that there is a framerate calculation. it's that 
Windows just send too many mouse events, while other platforms don't. 
that's why event filtering is very useful: you just throw away the 
extra events you don't need anyway and just make you slow down.

DideC - I'm making mine from scratch, though, so I can easily understand 
all of it  ^.-

gabriele, thanks

how do I put focus on a box without displaying the cursor?

What do you need the focus for? To enter text or to catch something 
else?

I ask, because if you wanna enter text, the question is, how to get 
rid or the cursor in general. If you wanna catch other events, you 
do it with the FEEL functions.

to catch keys and mouse events

system/view/caret: none. but focus will put a string there, so you 
have to none it each time.

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.