AltME groups: search

i guess, you just want a filled circle?

But I want it to be pixel-correct, so if I extend that dot (filled 
circle) to a line, it should look correct.

That might be a good way to do it. Let's see...

Yes, looking good. Just a bit irritating with the need of translate. 
A dot command at the same position as the start of a line would be 
desireable.

Generic newbie-like question: I was spying on source request-dir 
and am baffled as to how it works? There are many function names, 
I can't seem to access directly, such as F-LIST and DIROUT. Where 
do they come from?

request-dir: func [
    "Requests a directory using a popup list."
    /title "Change heading on request." title-line
    /dir "Set starting directory" where [file!]
    /keep "Keep previous directory path"
    /offset xy
][
    if block? dirout [
        dirout: layout dirout
        max-dirs: to-integer f-list/size/y - 4 / f-txt/size/y
        center-face dirout
    ]
    set-face f-title any [title-line "Select a directory:"]
    if not all [keep path] [
        path: copy either where [clean-path where] [what-dir]
    ]

    if all [not empty? path slash = last path] [remove back tail path]
    last-path: path
    result: none
    show-dir
    either offset [inform/offset dirout xy] [inform dirout]
    result
]

crude prototype, but it helped me find the file I had been looking 
for :-) I don't know how  to do actual multi columns with the internal 
text-list. the plan was to allow scrolling (I can't get that working) 
and when you click on a search result, the file pops up in the viewtop 
editor. feel free to perfect it...

It's interesting, that a translate 0.5 0.5 will give a more 'even' 
result:

Yes, normally you think of a pixel offset (say, 0x0) is at the centre 
of the pixel. But it's not, it's at the top left of the pixel. If 
you zoom in, logically 0x0 should be at the top left of the square 
that represents the zoomed-in pixel.

Even easier to see with a line-width of 2:
(Maybe I should report it to RAMBO? Is it a bug?)

I agree, that seems to be an inconsistency. Cyphre is probably aware 
of it, but worth a bug report. If you have some time maybe compare 
with other commands, too.

Bug report sent.


I'm spending the day making a DPaint kind of program in REBOL. Will 
release the work so far later today.

One step at a time! :-)

My DPaint clone "Canvas" version 0.1. It's a few hours of work, around 
150 lines of code. Only REBOL makes it possible! :-) There's some 
way to a full DPaint clone, but it's a good start.


Instructions here: http://home.tiscali.dk/john.niclasen/canvas/canvas.html
Canvas here: http://home.tiscali.dk/john.niclasen/canvas/canvas.r

great stuff! but drawing is a bit slow here. would it be an idea 
to limit mouse input to a certain amount per second?

Yes, that could be a solution.
Is it also slow, if you turn anti-alias off? Hit 'a'!

Good to know, Cyphre. And thanks guys! Preciate it. I hope, this 
'little' project will turn out well. I need a DPaint program to do 
the graphics for a phone-game, I'm involved in.

There seem to be a small anomaly, when doing thick circles and ellipses, 
in the right side, where the circle/ellipse starts and ends. It may 
have something to do with "line-cap round", but if that is left out, 
there will be a tiny gap, when drawing really thick circles/ellipses.

Maybe Cyphre should check it out!?

it could be a graphics driver problem, but I also tried it on my 
linux laptop and it's also very slow there.

Henrik, it must be something special with your setup, and you get 
slow console output on the
do http://www.rebol.com/speed.r

speed-test, as we talked about. You could post your speed output 
here somewhere and specify your setup. Maybe others have a solution!

I have an ATI Radeon 9500 graphics card with the latest Catalyst 
drivers and the test is run on a Celeron 2.6 Ghz PC with 640 MB of 
PC133 memory

adding a framerate limiter in your code helps nothing

but I've always had this problem that painting large surfaces in 
REBOL takes a long time on my machine and it doesn't really matter 
what drivers I use

I get:
Console:   0:00:01.703 - 297 KC/S
Processor: 0:00:00.406 - 2128 RHz (REBOL-Hertz)
Memory:    0:00:01.344 - 35 MB/S
Disk/File: 0:00:00.203 - 150 MB/S

on a 2.4GHz Pentium 4, 512 MB ram (not sure about speed, it's an 
ASUS P4P800 board), ATi Radeon 9600, not the newest drivers.

Well, it's a work-around, if you have slow graphics.

I've put a limiter on SHOW so that it only shows every interval, 
but doesn't miss as many position samples. so even though the framerate 
appears slow, it's actually very responsive. it's SHOW that's the 
killer.

We have to see, when there is more stuff in the program, if I should 
put in such a mechanism.

:-) Just fixed a bug with line tool, if start and end point is the 
same. Well, that's progress! ;-P

So it's possible to have a functionality, where you first press the 
mouse, then shift, then move the mouse.

I don't think shift first, then mouse button, then mouse move can 
be handled like in DPaint. :-/

Because you might move the mouse a bit after shift, before mouse 
button.

Speaking of shift, wasn't the cirlce tool actually an elipse, and 
holding shift created the same x-y offset, same with rectangle tool. 
Shift made a square?

Geomol, I don't see why you can't wait for the mouse down before 
deciding on the axis direction. If shift happens to be pressed when 
you get the down event, then you enter "shift-down" mode, and on 
subsequent move events, either shift is pressed, so decide and "quantize" 
to a horizontal/veritcal direction, or not, so allow any direction 
as usual.

Anton, yes, that is a solution, but

being able to have sticky coords at all time is good. Let's say, 
you want to draw a line aligned to another element, but at the other 
side of the screen. Then you first move the pointer to the element, 
press SHIFT, move to other side of screen and start the line. I've 
implemented it via the "detect" function. New version uploaded at 
http://home.tiscali.dk/john.niclasen/canvas/canvas.r

Instructions at: http://home.tiscali.dk/john.niclasen/canvas/canvas.html

1.8 Ghz 512MB and I haven't rebooted Xp in a while.

you could probably force a show canvas every time you receive an 
'up event

I think the feel is pretty good now. It's not silky smooth, but it's 
very responsive. It has a lot of potential.

hmm.... I think there needs to be a limiter as well on keypresses. 
try moving the mouse around while not drawing and press and hold 
+. The movements are slow.

is it possible to detect a key release? you could force a show there

someone I talked to, really wanted a Brilliance interface rather 
than a DPaint one. With redefinable hotkeys and a separate interface 
layer, this should be possible, shouldn't it?

Problem in "Canvas" is, that I do lots of things depending on tool, 
when the mouse is pressed. That now also has to be done, when a key 
is being pressed. Not good. I'll make sure, you can't change tool 
while drawing. Will solve problem.

with the polygon tool, when using a large brush, the polygon is drawn 
with sharp edges. is this correct behaviour?

ups, a bug. Yes, got it too in second go.

ok, is it also intentional that the first line in a poly must be 
drawn by dragging the line with the mouse button down while the rest 
don't require this?

Yes, that's the behaviour in DPaint. Think of it, as a line is fixed, 
when you release the button. Then it is same behaviour with all points. 
You can also drag the rest of the lines, as the first.

definitely not. proper flood filling is a per pixel operation and 
is doomed to be slow here...

I suppose a "Save" feature is getting close to the top of the list.

well, some parts can be done separately, can't they? I did the button 
menu, so I would suspect a thing like a real palette requester could 
be done separately.

Why not just "Canvas"? That's what it is (when it's more complete), 
a canvas, where you can use different tools to put paint on. I searched 
Google, and found a program called "Canvas Paint", which is based 
on the canvas widget of Tcl/Tk. That's not a problem, I think. There's 
another called "3D Canvas", also different. "Canvas" it is.

I don't have much time today, but next thing, I'll do, is to reimplement 
the brush, so different shapes are possible. And so you can select 
an area of the image as a brush.

I've got a flood algorithm:
http://www.lexicon.net/antonr/rebol/library/flood-recurse.r
do http://www.lexicon.net/antonr/rebol/demo/demo-flood.r

That's one of the groups, I'm 'monitoring'. You made me look, so 
now you earn me a beer in Italy! ;-P

connecting to: 66.136.133.209

** User Error: Error.  Target url: http://66.136.133.209/could not 
be retrieved.  Server response: HTTP/1.0 401 Unauthorized
** Near: cont: read http://66.136.133.209


Firefox: {Enter username and password for "level_15_or_view_access" 
at http://66.136.133.209}
(a security requester prompting for username and password).

What is a good way to check for certain values in an input field?

Let's say, I want to do an integer field, I've tried this as the 
action function:

if error? try [to-integer value] [set-face face 0]


It works first time, but if I try enter an integer afterwards, it 
just get settet to zero again. Any ideas?

You can enter integers at first, but if you enter a letter, it stops 
working.

I had the same problem and did not find a solution

Mike, a bit here: http://home.tiscali.dk/john.niclasen/vid-styles.html#section-5
If you do e.g.: 
layout [mycheck: radio-check "something"]

then mycheck/data will be true or false. Is that, what you needed?

view layout [radio-line "one" radio-line "two" radio-line "a" with 
[related: 'my-alphabet-radios] radio-line "b" with [relate
d: 'my-alphabet-radios]]

I put a VID screen on some mySQL data (using the Doc's protocol) 
and allowed paging through it using the left and right arrows. Worked 
fine for a small database; very fast refresh of the page. 

When I used the same approach on a larger DB with some TEXT fields, 
it started to hang at the same record when going '"right".   


After much trial and error and guessing, I think it is because the 
database is not quite fast enough to refresh the screen to keep up 
with holding the key down.   


I put it sub-second wait in before the screen reshows its values 
and the problem went away.   	ie wait 00:00:00.005   


I don't think it is a database problem because it could happen with 
slower devices such as files. 


Is this consistent with what others have seen or am I 'fixing' the 
wrong problem?

now SQLs are different kind of beasts -  there is NO live connection 
to sql database (on cursors later :-), you simply send a query, SQL 
server prepares results for you and sends it back to you. So, I wonder, 
how could actually SQL server slow your recordset browsing? And IF 
you were sending new requests after a key-press and wanted to stay 
real-time, then it is quite heroic aproach :-) Within our SAP system, 
you are glad if you receive your query result in few secs.

So, mostly, if you work with SQL, you try to find the right context 
of data, limiting your query as much as possible. Then you do a query, 
receive result and browse it. In that case, you already have all 
your data in rebol block already (unless you are reading them from 
port continuously), and it has nothing to do with SQL database anymore 
...

Not using a cursor. Right key action  increments current-record-key. 
Retrieves single row for current-record-key, Displays page with data 
for row retrieved.  The database is local and only has (so far) 120 
rows but I have another with three hundred shorter records (no BLOBs) 
on it and it works well without any wait.  i.e. I can hold down the 
right key and it will flash each page by.  MySQL protocol has always 
seemed very fast to me.  Is it possible that View is stacking up 
the key actions and hanging after it gets too many?  p.s. I don't 
want to read the whole database content into memory because then 
I have to worry about locking when I allow HTML updates to it by 
others.  Single row updates with the last update 'winning' in the 
unlikely event of a collision works well for what I need to do.

Hello, anyone have any ideas how I might improve on the integrity 
of a program that sends email to a list of people. I just realized 
I should be using '/only' but I have to check its behavior as I don't 
want each person to get a list of the other recipients. My problem 
is I often get a time out and I want to trap that. Yesterday during 
my first test it got halfway through the list and errored out which 
then caused the program to exit. I figured I should at least keep 
a running log so I can go back.

I guess it has to be a generic address in the header. It doesn't 
change it. Oh, well, that'll work as well.

Pekr, it actually didn't do a list. Instead it sent individual emails. 
Also I probed send and there is a '/show'' option that will replace 
the to: address. checking...

Just wondering how one matches a GUI like VID to an asynchronous 
data source. I am thinking of building a mulit tab panel application 
with an asynchronous backend.  If the user requests some data on 
one screen, and then changes their mind by switching to another screen, 
what does one do with the data when it arrives?  Does one refresh 
the original screen request and move focus from where the user switched 
to ?

Or,  say there is a chat window as part of the application.  How 
does one refresh the chat window without losing the focus on whatever 
the user is currently doing?

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.

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.

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.

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

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

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

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

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

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

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

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.

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

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

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.

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.

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"

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

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

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?

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

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

ok, thanks ... that is a good info ...

As a side-note, requesters in Canvas are using INFORM, thus are modal.

woah, did I say that? :-) meanwhile I do have a different example 
that could be useful: http://hmkdesign.dk/rebol/clock.zip

a face with a rate that grabs some data from an array

Just more to provide a snapshot over time.