AltME groups: search

II was sure I'd posted this just after Oldes' message.....But it 
ain't there now.....Maybe it's in the wrong group)
Andrew has a nice starter set:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=common-parse-values.r

And I know he has extended that list extensively to include things 
like email address and URL

so, basically you created a single parse rule from the macro list 
and then parsed the text in one go.

should probably build the rule outside the function as well since 
it only should be rebuilt when the macro list changes

most probably he didn't leave as soon as we think :) i think i remember 
him on the list in 2.0 times too.

Such a thing has been on my todo list for a while, but I've been 
a little busy lately with non-REBOL projects :(

you make a function that taken a list of rules generates all the 
permutations.

No, that is not the reason. Maybe you accidentally denied it access. 
So it should be in ZoneAlarm's list of programs. Go to the list and 
remove your program. Then try running it again. Otherwise, I would 
check if ZoneAlarm has any rules which block ftp. Does another ftp 
client work ?

My program doesn't show up in the ZA program list, even after I add 
it.

Maybe you should add it to the list of programs allowed to contact 
te internet.
I

hum strange... the DOS prompt returns, yet I still have my encapped 
app running in the task list (at 100%)! my god, how is this possible?

about fixing cpu busy look :-)  found a working solution.

; wherever you insert the asynch call  to system wait list... you 
also add 0.1 (or any other appropriate value for your app)
; this will obviously quit the event loop immediately.
append system/ports/wait-list clist
append system/ports/wait-list 0.1


then, where you normally call do-events OR at the end of your app, 
if not using do-events manually... you put the following:
forever [
	do-events 
]

and you have a 0% CPU consuming multiple asynch call loop.  I tried 
with the ping demo provided with async-call and it works perfectly 
on all the tests I did.

here is a new procedure (very effective)

append ports: system/ports/wait-list call-ports-list
append system/ports/wait-list 0.001
forever [
	system/ports/wait-list: []
	wait 0.1
	system/ports/wait-list: ports
	do-events
	if empty? system/view/screen-face/pane [quit]
]

More to the point, there is no published list of incompatibilties 
between diffeent versions of REBOL (not that I know of anyway).

Old scripts break in newer versions of REBOL. Some say that is an 
advantage of the language. For the rest of us, it's (at best) an 
annoyance.

Sunanda, that is what I was afraid of.  Without such a list I doubt 
that I could convert.  I'll just have keep and use my old version 
of the SDKI for encapping this script.

I guess it would be possible to do a checksum and correlate that 
against a version list.

Before adding new function to the list widget I'm actually tryaing 
to improve de yet existing things in order to not have to work on 
it any more later. So I work on order symbolisation (thank you ashley 
for the inspiration) and on column resizing algorithm and visuability 
:)

So how to best handle data now? For example I want to handle a todo 
list, where I need to change position of the todos in the list. Does 
the widget works with copy of the data best, or can I link it directly 
with the data block that the other functions work with too?

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

What about a single column text-list? IMO this one is needed too.

another trick is to focus on the headers, and let the list-part be 
build by the user. where the header keeps some info for the list, 
like the column-width/resizing.

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.

Luisc: It's on the ToDo list. From the release notes above:

	Known issues
		...
		- edit-list needs auto-fill logic added

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.
 I think he is really talking about drop-list not edit-list ...

Hi Ashley and Shadwolf  sorry if i didn't answer before i was out 
of town ( mother's day =P ) let me explained to you why the auto-fill 
on a drop-list ...

If you have a big drop-list ( non editable ) with 60 salesman ( big 
store ) and you shadwolf because of your name are close to the 50th. 
position the way to select your name frome that drop list would be 
with the mouse

wouldn't be easier if you typed sh on the drop-list to select your 
name instead ?

and no i am not talking about an edit-list. And is not an auto-fill 
per se routine. More like a keystroke capture routine so that it 
would do a search on the list  = )

Luisc: usually, drop-lists don't work well with big lists - it's 
quite hard on long lists to select something without mistakely closing 
the list. A classic text-list is far more suited for anything longer 
than 10 elements. A 60 items drop-list will raise a lot of problems: 
if the widget is too low on screen, most of the choices will be hidden.

Yes about usability. It's a all-in-one widget: one can use it to 
replace menu, lists, simple requesters (like the fonts and colors 
selection in MSWord), toolbars, auto-complete fields, etc. So it's 
mostly a shortcut to put more widgets (or compact them) in a window 
and can be confusing for users: what will happen if I select something, 
write in the field, click outside the list, click inside on the left, 
on the right, hit enter? It's a full requester in one widget: you 
can do the same with a request-list -like requester with ok/cancel 
buttons.

Luisc we have 2 item in fact edit-list to handle large data with 
some useful stuf like list vertical scroller and auto-fill field 
This is what you want. And the drop -list widget that is for handle 
tinny list of data :)

Luisc so what you need is yet planned and it's called editor-list 
not drop-list ;)

as shown is the example programmer hav only to give to list-viewdata: 
field the new list content then make a show listview to see the chages 
made on the listview.

list of what are missing for porting MDP-Viewer to RebGU:

http://shadwolf.free.fr/list-reszing.jpg

seems like the list content is not resized only the countainer ;)

try http://shadwolf.free.fr/list-resizing.jpg

mixing vid with rebgui has also some api-problems. some i found:

 /action: has in vid this args: [face value]. value is something usefull, 
 like area/text, slider/tdata, first text-list/picked etc. maybe its 
 not needed, "value" saves not much to "face/text". but supporting 
 that arg would be compatible

 /init: in vid this is a block and 'done. in rebgui it is a function. 
 vid has the advantage that init can be easily extended in substyles, 
 just add to it. rebgui has locals because it uses a function.
 /init2: not called by vid. 

resizing: not in vid, but one could write a /resize and plug it in 
the vid-face.

also there are some global changes which may break other things (removing 
event-func and changing global face IIRC).


If there is interest in making such small changes, i would help with 
making the rest compatible. adding #xh - parsing to 'layout and such. 
for "keep small" rebgui could have a "load-time-flag" to decide about 
using vid-stuff or all own.

What i would really like is rebgui for complex style-building (area 
with slider etc). this is closer to raw faces. and vid for quickly 
writing "pages", IMHO it has a rest of advantages there. (maybe not, 
i am a rebgui-beginner).

Anton

 1) Design decisions: thanks; if you think any of them were *bad* 
 then let me know, that's the reason it's still alpha ;)

 2) I like the edit-pair demo, I'll look at adding a cut-down version 
 of it to %tour.r

 3) Versioning / caching was something I was going to look at once 
 RebGUI goes beta and / or we have more of a handle on how REBOL/Services 
 works.
	4) "local" face definition: good point, added to next build.

 5) Extending widgets object: Yes, RebGUI doesn't have a "stylize" 
 system so you have to extend the widgets object when you need to 
 add your own. My hope is that with a functionally rich set of widgets 
 this will be the exception rather than the rule!

Robert

 Action handler not yet added to table widget. I'll add odd/even coloring 
 to the ToDo list.

Volker

 [face value] - less important for RebGUI as face/text or face/data 
 covers almost all cases; but I'll think on it a bit more as the compatibility 
 aspect is worth considering.
	/init - I'll look at making this a block in the next build.

 event-func removal - I'm considering a "load-time-flag" as you suggested
	system/standard/face - as per comments to Anton above
	"If there is ..." - agree fully with everything stated here ;)


RebGUI development is taking a slight pause until View 1.3 is released, 
as I want to baseline against that and remove all the pre-1.3 exceptions 
that have crept in.

drop-list

** Script Error: in expected object argument of type: object port
** Where: wake-event

** Near: if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
pop-face event]
>>

AS I propose to orgenise the devs we need as we are in stage one 
to have the overall list of the widgets that ashley wants to have 
in rebgui. We can make it on dokuiki rebolfrance.info a little table 
with widgets name | widget description | author that takes in charge 
the dev of this widget | dev stage % | integrated to rebgui |

Ashley if you want you post me here the list of remaining list you 
want to see in rebgui then I build a dedicated editable page in the 
dokuwiki rebolfrance.info  :)

dokuwiki  can collect the codes too ;) like I made for list-view 
 :)

what about lists, and clicking anywhere else - it should close opened 
list, but it does not, only escape works ...

list/menu imo has to disappear that way ....

but it simply is not correct, but you probably know it. I think that 
once ppl are used to close menu branch, or list by clicking outside 
of it, it can become pretty annoying, as the only chance to leave 
such menu is to select some item, or press escape.

I agree on 'drop-list / 'edit-list usability problem : the list should 
be at least closeable when clicking on the arrow button again - escape 
key isn't enough, as it's a mouse driven GUI.

Graham: RebGUI encap needs:
	#include %gfx-colors.r
	#include %gfx-funcs.r
I've added these to the next build.


Pekr: I've updated the choose func (used by drop-list / edit-list) 
to issue a hide-popup when the mouse leaves it. Feels pretty intuitive 
to me, but I'll see what folks think once the next build is out. 
;)

Vincent: Agree, I'll see about adding that for 0.3.0 as well.

I've also added a simple text-list widget (Robert) and fixed the 
strange table render problem (which you can see be increasing the 
horizontal width of the window *before* going to the "Table" tab 
for the first time).

is the text-list selectable yet?

Excellent! Just tried it with RebGUI and it works beautifully; even 
with global events killed. I think the edit-list / drop-list problem 
is solved. ;)

Latest build available at: http://www.dobeash.com/files/RebGUI-030.zip


*** Note that this version requires View 1.2.124 or later, and that 
the zip file is unusually large (346Kb) as it includes a dictionary 
file (future builds wont). ***

Highlights include:

	- New language, dictionary and spellcheck functionality added

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html#section-4
	- All objects merged into one context
	- Major code reorganization / restructure
	- Reduced number of global words to 11
	- Pre-0.3.0 comments removed
	- Pre View 1.2.124 code removed
	- New text-list widget added
	- Added show-color accessor function

 - rebface and rebfocus synonyms to avoid collision with face / focus
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/roadmap.htmlupdated

Known issues:


 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)
	- focus

 - edit-list / drop-list should use show-popup/away (some compatibility 
 problems)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- menu widget
	- better keyboard navigation / focus

Couldn't behavior of list be changed a bit? Maybe we are near? Menu/list 
should not definitely automatically hide, when you move mouse away, 
but it should hid, once you click outside. That is default and imo 
cross-platform. I wonder if we can achieve that?

text-list - it would be probably good if selected item would stay 
hilighted?

If you drop down the edit list, and then edit the field,  the list 
won't collapse again.

1) menu / list behaviour - will change once I iron out a few popup/away 
compatibility issues; it will then work as expected and the quirks 
it has now (as Graham discovered) should finally be fixed.
2) text-list highlight - noted

3) table - needs further work, but getting row selection working 
is a priority

4) leds - thanks to Pascal Lefevre for the original concept and Christian 
Ensel for the latest change
5) password - agreed

6) spinner - agreed. Before I spend any time on this one, how relevant 
 are spinners to today's UIs? I can't recall *ever* seeing one used 
in any project I've been in. Any strong objections if it's ditched?

list-view has been updated to comply rebgui 0.30 can be found here 
http://www.rebolfrance.info/articles/regui-cooking-widgs

(click on list-view in the table)

Can the list-view be resized as well when the window is resized?

About spinner, why not introducing a drop-scroller style.

It looks like a drop-list (right arrow), but while clicking, an horizontal 
scroller appear under the field. You can use arrows to up/down or 
scroll bar to go fast or to the top/bottom limit.

... which I thought should speed it up and make it easier to iterate 
in a list.

; définition du style de l'objet et intégration dans le context de 
RebGUI :
ctx-rebgui/widgets: make ctx-rebgui/widgets [ 
	;; Object' Style definition :
	object: make ctx-rebgui/rebface [
		size: 20x20
		title: ""
		pane: []
		; gestion des évènements :
		feel: ctx-rebgui/widgets/default-feel
		
		; Initialisation :
		init: has [tmp-sze] [
			tmp-sze:  size
			; list countainer
			insert tail pane make ctx-rebgui/rebface compose [
				size: tmp-sze   offset: 0x0 pane: [image img-barre]
			]
			; Insert TitleBar :

   insert tail pane titlebar: make  ctx-rebgui/widgets/image compose 
   [

     image: img-barre size: (as-pair tmp-sze/x 30) offset: 0x0 edge: ctx-rebgui/widgets/default-edge
			] titlebar/init
			; insert scrollers 

   insert tail pane v-scroll: make  ctx-rebgui/widgets/scroller compose 
   [
			 	size: (as-pair 15 tmp-sze/y) offset: (as-pair tmp-sze/x 0)

     ;action: does [scroll-table/y parent-face/pane/1 self] ; put here 
     scrolller function calls
			] v-scroll/init

   insert tail pane h-scroll: make  ctx-rebgui/widgets/scroller compose 
   [
			 	size: (as-pair tmp-sze/x 15) offset: (as-pair 0 tmp-sze/y )

     ;action: does [scroll-table/x parent-face/pane/1 self ]; put here 
     scrolller function calls
			] h-scroll/init
			; insertion  scrollable countainer 
			insert tail pane/1/pane make ctx-rebgui/widgets/box compose [

     size: (as-pair pane/1/size/x (pane/1/size/y - 15))  offset: 0x0 pane: 
     []
 			] 
		]
	]
]

Latest build available at: http://www.dobeash.com/files/RebGUI-031.zip


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3. ***

Highlights include:


 - Replaced scroller & slider widgets with Anton's new combined slider
	- Updated widgets to use same and set dragger size
	- Tab-panel now accepts actions (to enable dynamic tab displays)
	- Improved text-list selection logic
	- Prototype request-dir function added (needs a lot more work)
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/display.htmlupdated

Known issues:

	Unchanged.

On the drawing board

	Unchanged.

I get now this error message when I start the list ...

see the rebgui list code in the rebolfrance.org page ;)

Anton

 1) Code size. What it loses in code size it gains in aesthetics and 
 simplified behaviour (check out the request-color and request-date 
 actions in %tour.r to see the extra "state" code required by the 
 original implementation). I like Brian's base64 solution.

 2) Tab-panel color: I've based this on the WinXP color scheme. Try 
 changing it to colors/window, it just doesn't look right. But slider 
 can be used on a colors/widget or colors/window background. WinXP 
 solves this by using a gradient / edge so that it is distinguishable 
 on either. So for RebGUI, a number of solutions are possible:

  - add a new colors/slider background that "works" with both widget 
  and windows background colors

  - add a new colors/tab-panel background that "works" with both widget 
  and windows background colors

  - use an effect like gradient to distinguish the slider background 
  color
		- or edge
		- or?
	I'm open to suggestions on this one. ;)

Brian
	1) I like the in-line image solution

 2) I like the base 64 solution even better! One problem, the button-down 
 image renders the same as button-up (i.e. 1st and 2nd images render 
 the same ... even though a quick glance at the data suggests they 
 are different?)

Graham
	Any examples where the desired behaviour is used?

shadwolf

 I did the same (replaced scroller call with "slider data [arrows]") 
 for text-list / table and it worked fine for me. Check for code that 
 tried to reference sub-faces in the old scroller widget (as Anton 
 refactored slider to use just one face).

I think the default behaviour for a tab within an edit-list should 
be to leave the list, and not insert a tab.

a bit off topic: iTunes has a widget for rating of songs with stars 
one to five. Basically it's a widget that has 5 different states, 
depending on where you click on it. Would that be on the todo list 
for RebGUI? I'm planning to have such a thing in my next rewrite 
of my listview, I showed you some time ago.

Any chance to get the multi-column list to work in the next release? 
So that it's possible to select, add, delete entries. How about in-cell 
editing?

Yes, the list works to show stuff, but I can't select an entry and 
get a feedback into my code. Or is it possible?

Possible with text-list (see %tour.r) but not table [yet].

picked var is used to store in my multi column list widget the selected 
line content

I hope mine will be able to do that when I get something more meaningful 
done. selected columns for viewing is already now something you don't 
need to worry about in my list, but I still have much work to do...

Place the text cursor in the edit-list widget, and then press tab.

Latest build available at: http://www.dobeash.com/files/RebGUI-034.zip


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:

	- request-dir requestor updated
	- alert and question requestors added

 - Tab focus expanded to include edit-list handling (see %focus-demo.r 
 for details)
	- Button image now resizes correctly

 - text-list widget totally rewritten to use [newly documented] View 
 1.3.1 iterated faces
	- text-list now supports Ctrl+click, Shift+click, Ctrl+A

 - text-list scrollbar now reacts to current display state (eg. disappears 
 if not required, alters dragger ratio as rows are added, etc) 
	- check and radio widget aesthetics improved

 - added options support to layout function and text-list and check 
 widgets

 - changed base-size from 4x5pixels to 5x4 pixels (better granularity)
	- reworked all widget sizes to account for above
	- fixed scaling problems with many widgets
	- updated focus-demo.r

 - greatly enhanced and expanded %tour.r to demonstrate more variations 
 and usage cases
	- added "live" unit-size and font-size drop-lists to %tour.r
	- numerous other minor bug fixes and coding improvements

In the works


 - table widget being rewritten along the same lines as the new improved 
 text-list widget
	- aiming for a 0.4.0 beta release prior to DevCon2005

With the text in an edit list highlited, click on the drop down arrow, 
click on a new item, then tab .. and the above occurs.

When a window containing a text-list is maximised, the scrollers 
disappear.

from the text-list.

Hi, just few notes .... 


1) why new versions are not released as complete ones? The download 
is small already. I tried to point out my friend to it, and he missed 
0.3 version or so, which is required ...


2) box definitely does not resize properly. Still, so far, Romano's 
system was the most complete and the least errorless version I saw. 
Try to move resizing window here or there and you will get even cases 
as three lines of color boxes, no spacing, mixed together ...


3) lists - are we ready to overcome rebol limitation here? It works 
better, but still not flawlessly and not in system friendly manner: 
a) when moving "too fast" with mouse, it stays open b) in above and 
and other cases, ESC shoudl close it c) I understand we have use 
some "excuses" and workaraound for now, but that is not the way to 
go in future d) when moving away, it should stay open, last hilited 
item should stay hilited, close on esc, close on click-away, should 
be foxusable, ability to be driven by keyboard  - that is the only 
system friendly way


4) text-list multi mode - ctrl works, shift too, ctrl A too, but 
not in a system friendly way once again. Maybe I should check first, 
but IIRC, it should work following way - ctrl selects particular 
items. BUT - it should also deselect them - try ctrl A and then, 
holding Ctrl, press some item - it does not deselects them - that 
is imo wrong. Also - shift should mark all items between point of 
last press and active mouse position, deselecting all the rest, even 
if previsously selected ...

... e.g. with text-list, resizing up and down few times, and you 
get buttons over text-list, the same way bar over text-list, text-list 
not fully visible even if maximising window ....

Graham,

	display "" [field [show-text face "" rebfocus face]]


but wrapping this in a 'clear-face func is the way to go. Thanks, 
added to the list.

Depends. Take the following code:

display "" [
	a: field "A"
	b: field "B"
	c: field "C"
	button "Clear" [
		show-text a ""
		show-text b ""
		show-text c ""
	]
]


Clicking "Clear" first behaves as we expect, but clicking in a field 
then "Clear" is problematic. The solution, as in VID, is to unfocus 
whenever soemthing else is clicked on. Added to the list.

Go here for a list of all other issues: http://www.dobeash.com/it/rebgui/issues.html

Graham, are you sure the disappearing text-list slider problem wasn't 
just the fact that all rows fit? Try the following code:

b: copy []
repeat i 1000 [insert tail b i]

display "Test" compose/deep [
	text-list #H data [1 2 3 4 5 6 7 8 9 10]
	text-list #H data [(b)]
]


When you maximize the window you'll see that the sliders only appear 
if needed.

Yep, my demo has 6 or so items in the text-list, and when you max 
the window, only 3 show with loss of the sliders.

And in your example, the right hand text list demonstrates this point 
for me losing it's sliders as well as another problem - a tiny square 
widget.

In this example I can't get vertical positioning working 

display "" [  
    at 0x150
    

    text-list 30x15 #YH data [ "Joe" "Adam" "Bill" "Artur" "Phil" "Simone" 
    ] [ show-text chattofld pick face/data first face/picked ]

        chatarea: area 150x10 #YWH "Intra office chat appears here" slider 
        5x10 #YXH data [arrows]
 
    at 32x160
    chattofld: field 15 #Y chatfld: field 140 #YW [ 

            show-text chatarea rejoin [ chatarea/text newline chattofld/text 
            ": " chatfld/text] 
            show-text chatfld "" rebfocus chatfld
    ]

    ] do-events

The area widget, like text-list, should have a slider that appears 
as needed. Hope to have that in the next build.

Latest build available at: http://www.dobeash.com/files/RebGUI-035.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:


 - generic face-iterator function shared by all lists (text-list, 
 table, edit-list & drop-list)

 - new improved table widget finally supporting row (including multiple) 
 selection

 - updated drop-list & edit-list widgets (defocusing support still 
 limited though)
	- area widget now sports a slider by default

 - resizing code (supporting negative sizes) reverted to pre-0.3.4

 - IMPORTANT: resizeable windows that don't have min-size specified 
 are automatically assigned one the same as the original window size
	- Various multi-row text selection issues resolved
	- Various focus issues resolved
	- numerous other minor bug fixes and coding improvements

In the works

	- basic menu widget
	- revamped documentation 
	- stabilize existing code-base for 0.4.0 beta release

Latest build available at: http://www.dobeash.com/files/RebGUI-036.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:

	- All widgets now support alt-action & dbl-action blocks

 - Table & Text-list widgets now have a selected function to access 
 selected data directly

 - New clear-widget accessor function to handle setting values within 
 iterated faces
	- Added a clear-text accessor function
	- Documentation updated to reflect above changes
	- Number of minor bug fixes

In the works

	- revamped focus system
	- basic menu widget
	- context menu widget
	- stabilize existing code-base for 0.4.0 beta release

clear-text doesn't reset the line-list for an area widget.

this might be usefull to users of sqlite.. I yesterday encountered 
the "db is locked" error and it got me a little worried, but with 
this (simple) aproach it seems to solve that http://itsystementwicklung.de/pipermail/list-pysqlite/2009-April/000380.html

Here is Gabriele's response to my bug report (RAMBO ticket # 4411)


This is not really a REBOL bug. The SQLite driver is doing a WAIT 
1 in the DO-STEP function; calling WAIT inside an event handler (such 
as a face's timer event) is not really supported by REBOL and should 
be avoided. If you can't avoid it, you must be prepared to handle 
other events happening during that WAIT call, and you need to be 
very careful with blocking requesters (SHOW-POPUP, INFORM etc.) as 
they're likely to mess things up (they call WAIT as well).

My suggestions are:


1) File a bug report with the SQLite driver. There needs to be a 
way to avoid the WAIT, though I guess this is going to be complicated 
in R2.


2) Disable other events while you're using the SQLite driver, eg. 
clear SYSTEM/PORTS/WAIT-LIST and restore it afterwards.

3) Use a "global" flag like you're doing.

-Gabriele

Gabriele, when you say "clear SYSTEM/PORTS/WAIT-LIST", do you mean 
setting it to NONE temporarily?

most likely, you'll only have the event port in the wait list, so 
it's just a matter of removing it and adding it back later. I can't 
guarantee this works 100% because I haven't tested it.

another alternative could be:


4) don't use face timers, but rather replace do-events with something 
like:

    forever [
        wait 1
        do-your-sql-calls
    ]


You'll still have other events happening while you're doing your 
sql calls in this case though, not sure if that can be a problem. 
The cleanest solution would be to change the driver so it does not 
wait, but I don't know SQLite so I can't say how easy that would 
be.

In the modules body you have to implement callbacks (HTTPd phases) 
if you want your module to react on requests. The order is just the 
position of your module's callback for a give phase, among the list 
of other modules.

UniServe is based on the classic request/response model. You have 
to implement a specific UniServe' service for your specific need 
(like sending a response to another client than the one who sent 
the request). I guess you'll have to maintain in the service's context 
a list of the (browser, flash) connections couples, so there's some 
probabilities that you'll end up write a full custom HTTPd service.

parse/all request/headers/Content-type [
			thru "boundary=" opt dquote copy bound [to dquote | to end]
		]
		if not bound [return ""]	 ;-- add proper error handler
		insert bound "--"	
		list: make block! 2
		parse/all data [
...

Sorry, no diff file list. You can update just the files having a 
more recent timestamp.

although it does list the run command

I'm not sure to understand the issue with Cheyenne CGI ? For RSP, 
there's a list of global words that MUST not be modified like : request, 
session, response... If you want to use, in RSP code, a framework 
that will conflict with RSP words in global space, you'd better wait 
for R3 to cleanly handle those issues, R2 namespace managment is 
just too limited.