World: r3wp

A bit more about my guesses about VID and mySQL. I wasn't sure it 
was not the number of rows that was causing the lockup so I loaded 
100,000 rows into the MySQL table and VID seems to be able to page 
through them based on right arrow (meaning get the next, display 
it, repeat until last row) i.e. hold it down and the row information 
will flash on the screen and eventually catch up.   The hanging seems 
to be a combination of stacked UI events and hitting a mySQL row 
that has a large BLOB in it.   Small text values in the BLOB are 
handled.   I can page past a large BLOB provided that there is not 
an accumulation of UI events.  If there is not a large BLOB in the 
rows being read, then it does not hang when VID is asked to page 
through at a rate it can not quite keep up with.

Mmm. Interesting. Can you identify the precise size of the BLOB needed 
to cause the lockup ?

It is the largest BLOB on this table but is only 13410 bytes.

In request-color a function "setc" is used. I can see it in system/words, 
but I can't see source. I seem to remember a way, or am I wrong?

it's probably in a context with an object. I ran into the same problem 
with request-dir, which someone magically found the context for me, 
for :-)

Found it: system/words/req-funcs/req-color/setc
Thanks for the hint!

how?

I used anamonitor.r found in the library.

probe req-funcs/req-color

Is there still people developing with Rebol/view without using Anamonitor 
??!!

Shame on you

does it work with rebgui ?

I've never used it :-)

It was a time (not so far) where view doc was pretty inexistent.

Anamonitor was (is!) the way to correct partially this "state of 
fact".

Graham: as long as you use View to test Rebgui scripts it should 
works. But with SDK script without View sources include, it must 
not.

Anamonitor is not a View debugging tools only: it's an object!  explorer.

So you can use it to explore any object! and "see" any rebol values 
inside.

can you search an object and see the item path in relation to the 
object? that would be nice...

Try it, it's in the REBOL Desktop under: REBOL.com/Public/Library/Scripts/A-Z/a/anamonitor.r

argghh

This isn't making sense to me..

view center-face layout compose [
   across origin 0x0 space 0x0 backdrop black
   style btn btn gray black
   btn {Close} [quit]
   btn {Send} []

   btn {Add Attachment} [append Attachments/text join mold request-file 
   newline show Attachments]
   return

   Attachments: area 300x100 do [Attachments/feel: make Attachments/feel 
   [engage: none]]
   return
   txt 100 {To:}
   To: field 200 {[Izkata-:-GMail-:-com]}
]

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.