World: r3wp

And click on the Add Attachment button... I keep getting:
** Script Error: font-size has no value
** Where: do-facets
** Near: font-size 11

It (seems) to stop doing that if I remove the To~ line, but I can't 
figure out why - or a workaround..

Try Help To ... To See If It Is A Reserved Word that you are redefining

Okay... If I put this at the beginning, it works.  But I don't see 
why it doesn't work that way in the first place..

req-file/out: do req-file/start-out

ack let's see... (I forgot about that... Bad me, we just went over 
that in C++ class!!)

Aaaand that was it, Mike.  But should Rebol allow it anyway?  <whacks 
forhead>

See http://www.rebol.com/docs/words/wprotect-system.html

Now if you will remind me how to add to easily (View 1.3) add a text 
area vertical scroll, we can be even.  I can't locate a good example.

Ouch to me... Oh well.  I guess I'll have to make a "Do not repeat" 
file from now on. Now I remember, I did the exact same thing with 
the exact same word some time ago...

hehm

tx: area 400x400 para[]
slider [scroll-para ta face] 16x400

; not tx..
ta: area 400x400 para[]
slider [scroll-para ta face] 16x400

Thanks for that Volker.

Izkata: If of any help, there is an emailer based on the Desktop 
one, but that handle attachments.

rebol.org : http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=vt-emailer.r

I've been grumbling over a few observations I did on early versions 
of Canvas and ROAM regarding SHOW on three different machines: A 
slow PC linux laptop, my fast Windows PC with a Radeon 9500 graphics 
card and my mac mini with medium speed Radeon 9200 graphics chip. 
For my tests I used the ROAM object browser available in the desktop 
under Rebol/REBOL Tools.


When I maximize ROAM to full screen on my laptop and mac, they are 
rather slow at redrawing the highlight bar. But if I move the mouse 
quickly to the top/bottom of the list, the highlight skips those 
entries that can't be highlighted in time, and therefore it remains 
fairly responsive even if the frame rate is low.

However on my fastest machine with my powerful Radeon 9500, the highlight 
bar moves at a snails pace behind the mouse pointer, insisting on 
redrawing every highlight. It takes at least a full second to reach 
the current mouse position and the event system is locked and REBOL 
is fully concentrating on SHOWing the list face.


The amount of time SHOW takes to display the list view is dramatically 
dependent on the size of the window. A small 400x400 window is fast 
enough for normal use, but a 1280x1024 window is very slow.


It looks to me like a frame rate problem: Somehow my fast machine 
calculates a specific very high framerate (say 50 fps) that SHOW 
should handle for the list face, but can't keep up at all. Therefore 
50 SHOW operations take 2-3 seconds longer than they should and the 
delay occurs and it drowns out the event handling. This framerate 
is apparently tuned properly on the Linux and the Mac so it never 
becomes a problem there. How is this framerate calculated?


Also when I run the console benchmark program, I get remarkably bad 
performance on text output on my normally fast Windows machine, while 
the mac and linux consoles output text 5-10 times faster. Reports 
from other Windows users say my console is very slow.


I'm really just wondering if others with Radeon graphics cards and 
Catalyst drivers have similar problems.


Not all is bad: This framerate problem can be solved within REBOL. 
I did a simple delay system for Canvas which sped things up quite 
a bit on my machine and I've just done a dynamic method for ROAM. 
The delay system simply implements a DELAY-SHOW function which does 
not invoke SHOW unless a specific amount of time has passed. The 
method I did for ROAM is dynamic in that it measures how long a SHOW 
takes and adjusts the delay accordingly plus a tiny safety margin 
of 0.01 seconds. It works quite well. At the cost of a reduced framerate 
and sometimes missing a redraw at the end of a mouse move, I get 
a much more responsive ROAM, and the framerate adjusts nicely between 
large and small windows.

See if you can tell the difference between:

http://www.rebol.com/view/tools/roam.r
and
http://www.hmkdesign.dk/rebol/roam.r

second link has incorrect functionality though. It somehow skips 
some rows ... e.g. I am able to mouse over some row, but different 
row keeps its hilite ...

as for Windows console being slow - it has nothing to do with your 
gfx card imo :-) Windows console is known having rather slow performance 
:-) IIRC Rebol alpha used windows(dos) console, but we know that 
Windows console really sucks, so RT implemented native one. With 
Linux imo REBOL is usig Linux console, not its own one ...

as for Rebol refresh problem of big faces - ask Cyphre about it. 
I would like Cyphre to comment here. Dunno if it was fixed or we 
are not able to get better performance, but Cyphre showed simple 
example when big rebol face with no content had really painfull refresh 
performance ...

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.) :-)