World: r3wp

Hmm.

I guess it depends upon whether the updating of the display grabs 
focus or not.

what triggers the data? somebody else like with altme, or more like 
a browser?

well, the data will be sent if there is a chat like aspect to it.

and also if the user requests it.

overlooked your second post. its about relayouting and keeping focus?

maybe I can do it like Altme.

change the colour of the tab for the panel that is updated.

MikeL, I think the problem is as you suspect. Whenever you WAIT for 
something (in your case MySQL), you are also waiting for view events. 
Your view events are arriving faster than the results are in the 
mysql port. Put a simple lock in your code:

 button "next" [if not working? [ working?: yes  next-page  working?: 
 no ]  ; where next-page sends and waits for my-sql port.

James, you can test what happens by sending mail to yourself. If 
you have two accounts then you can test the multiple addresses functionality.

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