AltME groups: search

And my philosophi lies between Ashley and Petr. I'm in more favour 
to spend time designing simple widgets that have a hughe feature 
set. Because than, my app development times are reduced radically. 
Hence, thinking once at the widget level, saves you factors of time 
on the  application level.

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

I spent a lot of time working on that kind of thing for VB, and also 
used some commercial VBX/OCX packages that included them. Our target 
audience was data entry operators in call centers and, while this 
is what the internal analysts and user contacts said was what they 
wanted, the actual users hated it; it just got in their way. Asking 
around informally, I found that most users didn't care for them, 
while techies thought it was a great idea.

Pekr; If this is an open question, and not just to Ashley,


I use what I'm given.  In that I build apps (not many so far) using 
the toolkits I see in front of me.  I'll definitely retrofit my existing 
Fire and Rescue Management app with a Menu once the flurry of RebGUI 
development slows down a bit (and please don't slow down, love the 
flurry).


Unless my systems crash, I spend zero time optimizing, wait I take 
that back, I try and follow my own style guides while I'm writing. 
 There is the odd backtrack to get a tab panel to line up nicely 
inside another.  Other than fixing glaring visual ugliness, no optimizing.


I design with a 'small town business model'.  I hand deliver applications.


If I go and snag a feature that goes quirky during my initial testing, 
I dump the widget and look for another.  My 0.4.0 build of RebGUI 
had sticky persistent drop-list's so I used labels and a special 
requestor.  I'm not sure I'll retrofit these.


The easier things are out of the box for me, the happier.  Give me 
the tool, describe how it works and I'm satisfied (when it's as elegant 
as REBOL, RebGUI and RebDB).

isn't it possible to do some automated builds to .zip file? PeterD 
- I can sedn you new version from time to time ....

the first 'sort in your train function consume a lot of time

Wonder how easy it would be to do real time spell checking?

how easy it would be to do real time spell checking

 ... with a cut-down version of Ladislav's code (mainly limiting edits 
 to one char distance) speed is no longer an issue. I'm looking at 
 using draw to red underline all spelling errors in a text face and 
 then only popping up the spellcheck box on right-clicking a misspelled 
 word.


Problem is synchronizing red underlines with scrolling. R3's rich 
text support would make this trivia [by comparison] to implement.

It would make it easier for me each time I have to merge my sources 
with yours ;-)

Does the data structure meet your needs? Note that, like AltME, if 
the date is today then the time component is shown instead. You can 
insert abbreviated date/time's with:

	to date! reform [now/date now/time]

Otherwise , if you try and refer to a particular message .. you can't.. 
except by pointing to a datestamp which may be different depending 
upon which time zone you're in.

Pekr, it's called doing what one can in the time available.

BTW, what changes are you having to add back in every time you do 
an SVN sync? I'll look at incorporating the more generic ones.

Ashley, View system has broken highlighting and caret positioning 
with center and right aligned text. It's been a problem for a long 
time.

The dictionary files are just a collection of sorted unique space 
separated words (all on one line, no carriage returns). I extracted 
them from the latest Abiword dictionary files. No utility as such, 
but the trick to generating them in REBOL is to get a block of strings 
then do a:

	write %my-dict.dat form sort unique my-block-of-strings


As for the button disabling question, I thought it was specifically 
related to the spellcheck taking 5 seconds. But, more generally, 
I'm against that type of thing. Far better to pop up an alert or 
progress bar for actions that will take time. Pressing a button should 
provide *immediate* feedback or results.

as for request-progress - I propose the same usage as with Calendar! 
Not every time you want a dialog box, which is stupidly blocking 
your UI.

set-disable, set-enable - I welcome it. Some time ago I wrote disable-face, 
enable-face, which simply put transparent face with whatever effect 
block in front of widget you wanted to "disable". It did not block 
the keyboard, but Anton fixed it IIRC, and those two small functions 
are on rebol.org.

some time ago I posted two screenshots of possible widget additions, 
which could allow more robust app design - UI wise. I wonder what 
ppl miss in general ...

I have an async routine that displays all the chat messages in table 
on a panel.  This triggers in the action field of the panel, but 
even though it is async, it takes a finite time, and so slows down 
the display of the panel.

yep, refresh is paramout, always... often, the time the user focuses 
on the display changes, is enough time for the action to occur... 
so from the user's point of view, everything seems instantaneous 
 :-)

I suspect it would not be particularly overkill to track the caret 
on every keystroke ... editors do it all the time.

time to take a break .. later.

Couple of deep design questions. Run the following code:

display "A" [
	button [
		display "B" [
			f: field on-unfocus [false]
			button [print "Click"]
			do [set-focus f]
		]
	]
]


1) Click the button to open display "B" ... type some text, then 
click the OS close button ... then try the same thing again.


What you should see is that you can't enter any text the 2nd time. 
This is due to the fact that the 2nd time set-focus is called it 
fails to unfocus so is left in limbo. Not sure what to do about this 
case.


2) Run the sample again. Click button to open display "B" and click 
the button.


Note that the button's action fired as clicking a button does not 
shift focus (i.e. you can click a button and continue typing in a 
field). The question is: even though we are not tabbing out of the 
field, should the button's action have fired. This question becomes 
even more relevant when the button action does something like open 
a new display (or close the existing one) ... should this action 
be allowed to proceed even though there is a failed unfocus action 
pending?

Ah, you fix one problem only to discover a bigger one! Anyway I've 
uploaded build#89 which addresses the two specific issues above:


1) Clicking the close button on a window now forces an unfocus but 
*without* triggering the on-unfocus action (or a show).


The /close refinement of display must now return true or false to 
proceed or not with the close operation.


2) Clicking a button only fires its action if it is not the current 
focal face and the focal face's on-unfocus action returns true


Try these with the test code posted above. You should see that it 
now behaves as you would expect. But now try the following code:

	display "" [
		field
		calendar
	]


Click on the field and start to type, then click on the calendar 
and continue typing! Why does this happen? It happens because when 
we detect the 'down event we have no way of knowing whether it originated 
from the field or the calendar. %display.r *should* be able to have 
a detect function that (among other things) does a:

	if all [
		find [down up alt-down alt-up] event/type
		face <> view*/focal-face
	][
		code to check on-unfocus
		code to do an unfocus
	]


but this will not work because of a view bug that causes face to 
be the window face *not* the face that originated the event. Urrgh. 
At this time I can't see how to trap and process mouse click focal 
changes. Might have to delve into the VID sources again to see how 
(if) it was solved there.

I'm hoping today's builds fix *all* outstanding focus/caret problems, 
many of which have been around for a long time now. ;) If that's 
the case then I'll do a public build and the pace of changes will 
slow.

As last time, my radio-group change wasn't liked. We will derive 
a special kind of drop-list.

Ashley, for tables I have always a hidden column with a record ID. 
This ID is used through all the program.


For drop-lists I "store" the text of drop-list/picked at the moment. 
Hence if you have several languages, at one time you store the DE 
version at an other one the EN version. So, one solution is, I have 
to translate to the "master" language that's used in the database.


But what if syntex changes? Than I have to update all old entries. 
Using IDs frees me from this but adds an other level of indirection. 
The common way would be to normalize my database model and use other 
tables to get IDs, and than store those etc. IMO that's the way to 
make apps complex and slow.

directory selector that can access directories across the network

 We're limited to what "read %/" can pick up. Real solution is to 
 have a native request-dir func (and request-color, request-font).

background colour to an info field
 ... how about making it the same color as tooltips?

	field ctx-rebgui/colors/tooltip-fill

Any ideas
 ... looks like a RebGUI bug as I can reproduce it with:

	display "" [
		box tip "Some text"
		button [alert "Text"]
	]


Hmm, also noticed that tooltip and tooltip-time are dynamically escaping 
to the global context. Will look at this later today.

Yes, all the big structural/naming changes were done some time ago.

 the fact that Konfabulator-like dialect that uses View to its full 
 potential is another issue.


did you look at (short on time, cause everyone else was late ;-) 
 elixir devcon session ?


that just what it is...  100% AGG gui engine... with full AGG element 
based interaction and per stroke feel.

graham... darn... should be putting time on elixir and liquid next 
week *I think*  but with all the things going on in my life right 
now I can't be sure.

Graham - it should, but as an interim solution I welcomed even such 
hack. I refuse to visually remove buttons, according to some conditions. 
That sounds scary, when once there is button, next time there is 
not button at certain position :-)

Well, that looks like the face-iterator logic (used by table and 
text-list) ... any idea what was being done at the time (i.e. table 
just about to be displayed, row double-clicked on, etc)?

RobertS - just don't try to suggest we are REBOL zealots. Maybe I 
was Amiga zealot, but that time is long gone. OTOH I strictly refuse 
to be shy of REBOL anymore? What does Curl gives me? It is just another 
technology. I was open about Curl, or was it other technology? And 
it was Robert who suggested that the thing is slow, and that his 
fried had to restart the project because of that.

We should focus on REBOL here. Half a year is no time imo. I don't 
know how much time it takes to master other technology, but Robert 
could as well contract some guy to port R3 to plug-in version in 
that time ...

Then there are the slow-as-molasses industries that replaced 3270 
with PC's just in time to discover 'thin client' as the 'new terminal'.

Diskless-Network-PC? Give me 6 months of high fashion and the 'new 
black' any day.  Client app? Pass the X-server wlll ya ....  ;-)

Graham;  I'm being facetious; but who, other than you, writes apps 
that need that many tabs.  You're adding too many features.  :)  
More seriously.  I've hacked an overlay widget by pulling the tab 
pane out of  Ashley's tab-panel (build 95)  that uses the same layout 
model and his select-tab action.  Put up a couple of arrows and you 
can stack as many tabs in an overlay space as you'd like (they would 
not scroll one at a time; it'd function as banks of tabs; one tab-panel 
per overlay "tab" but it'll save a fair amount of screen real estate). 
 I could post the code somewhere if you'd like.

multi-select fails the second time round.

well, it came at the time when Ashley was doing some changes to API. 
And it was not adapted ......

wish I had time to port LIST-VIEW to RebGUI. would seem useful there.

Robert emailed me his code, I just have to find some time to go through 
it and merge the grid-specific stuff.

It's a problem as tabbable and focus usually go hand-in-hand. Button 
had the same issue, and required quite a bit of hacking to get it 
working. Other non-focusable widgets have the same issue (e.g. check 
and radio-group). Keyboard navigation has been an issue for RebGUI 
(and VID) for quite some time ... just ask Pekr ;)

Huh? button is a widget, it's been around for a long time ;)

I believe he's referring to the second time button is called to change 
button b's action.

Only works with:

	area
	field
	edit-list
	button

widgets at this time.

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

I see your point and I totally agree. On the other hand doing a real-life 
full-fledged application requires most of the time more than just 
a basic widget.


What I found out is, that most simple widgets are ok from a GUI POV 
but not in these areas:
- storing / saving widget state and user-data

- be programmatically controlable (like setting a tree to a specific 
state, hiding stuff, setting sort-oder etc.)

- implement always returning usage patterns in a more programmer 
convinient way

- using a common approach for specification (nested blocks, key/value 
pairs etc.)

Yep, a lot of that code is app / context specific; although the widget 
should allow you to extend its functionality via APIs rather than 
having to "roll your own" every time you need a bit of extra functionality. 
scroll-panel is a move in that direction; "I'd like a spreadsheet 
here, and I'll put that in a scroll-panel because I want to scroll 
a large sheet; and I'll add left-click and right-click handlers to 
handle load and save; and assign a screen dump routine to F3, etc". 
All that is currently possible. "I'd like to move this cell from 
here to here" is not currently possible, and I doubt anyone could 
create an API that could let you do *everything*. (take something 
simple like alternating row colors; I had someone ask if the *number* 
of alternating colors could also be specified!)

Ashley - by your aproach though, RebGUI will be first class REBOL 
gui toolkit for some time, but always second league to any normal 
toolkit. I can't agree to ANY kind of simplification, it is just 
does not deliver what normal OS user is used to. It is surely fine 
to keep simplicity and maintainability in mind, but we should be 
real - who cares if widget has 1 or 100KB? I don't, and what end 
users will judge is only comfort of usage.

Agreed, and it seems time (and a good move) to simply offer RebGUI 
Core, and RebGUI Robust, no?

OK, a couple of items of business first.


New logo - I like the new logo Reichart proposed (including the X-Internet 
text) and given I've heard nothing to the contrary I'd ask Reichart 
to prepare a few different color samples and we can vote for the 
one we like best ... and then I'll choose the one I like best anyway. 
;)


UI Look - The RebGUI look is too Windozy and is starting to show 
its age. I've decided to try for a simpler, whiter web look with 
fewer colors (I experimented with a B&W look but that's too harsh). 
My first thoughts are, with Reichart's permission, to revisit Quilt 
and mimic its look; but if someone has a link to an extensive set 
of online widgets (with a unified look) that they feel is appropriate 
then post away.


Radio-group - And now a minor implementation question (mostly for 
Graham I suspect). After looking at http://www.useit.com/alertbox/20040927.html
I note their comments in point 9:


Always offer a default selection for radio button lists. By definition, 
radio buttons always have exactly one option selected, and you therefore 
shouldn't display them without a default selection. (Checkboxes, 
in contrast, often default to having none of the options selected.)

If 
users might need to refrain from making a selection, you should provide 
a radio button for this choice, such as one labeled 

None." Offering users an explicit, neutral option to click is better 
than requiring the implicit act of not selecting from the list, especially 
because doing the latter violates the rule of always having exactly 
one option chosen."


Is it time to disallow null radio-group selections? (at present radio-group 
allows a 0 or none! selection)

This sounds similar to the way I implemented check-box; a tri-state 
widget (unselected, tick and cross mapping to none!, true and false) 
... which also raises the question whether it's time for check-box 
to go bi-state (unselected and selected mapping to false and true).

Providing keyboard support for inherently graphical controls (e.g. 
radio-group, spinner, etc) is IMHO a waste of time. All the main 
input widgets (field, edit-list, area, sheet, etc) should and do 
have proper keyboard support. If you're designing an application 
for fast data entry then you should confine your widgets to those 
that accept keyboard input (i.e. data entry forms). If you want a 
rich GUI with a full set of graphical widgets then I don't think 
it's too much to ask that users have a pointing device. I mean, you 
don't expect users to use Windows without a mouse? Or Office type 
applications?


But, list away as I'm currently doing major code fixes (better scroll-wheel 
support for one) anyway; if it's relatively straight-forward to do 
I'll do it.

For example, radio buttons are the core of:

Radio buttons - O Apple  | O Pear | O Banana


Tabs - Are just radio buttons where the selection IS the card /Apple\ 
/Pear\ /Banana\

Combo-box - [_Apple_[^v]


Then there was a button on the Amiga which was really cool (spinner?), 
but never caught on.  Every time you clicked on it cycled to the 
next option in the list.

Spinner - [_Apple_[O] 


This widget is very useful for toggles, and perhaps even up to three 
states, but after that is loses its value.

Jakob Nielsen does write many interesting things, like this about 
web functionality, he wrote in 2000: http://www.useit.com/alertbox/20000625.html

Read it in general (and not so much about .NET, that's just one technology). 
It takes time to move the technology and people's behaviour, but 
I think, he has many valid points.

Defaults to auto now, and has for some time.

Any chance we'll be able to use a 'set-state/info with checks, spinners, 
drop-lists any time soon?

Any chance we'll be able to use a 'set-state/info with checks, spinners, 
drop-lists any time soon?

I've got a value of .004 that is being displayed in scientific notation, 
and so I want to use Gabriele's form-decimal on it at display time.

I'm having some trouble that I was hoping you could help me with.. 
again :)


I want to have a tab in a tab-panel that contains some kind of group 
block and a button. Every time the button is pressed the group block's 
contents should change to a new, dynamically generated, GUI block.


It works up to the part where the button is pressed, but the group 
block is never changed.

I've managed to screw up my program somehow :( hehe. Problem is I 
can't remember when the tips worked last time. Adding them dynamically, 
so it's not quite straight forward to debug

Graham - nice interface - what widget is used for the scheduler displaying 
time slots?

Well ! There seems to be !! It took a very long time to display any 
messaged when I visited the group, so I though there wern't any :-) 
Cheers.

Can RebGUI table or sheet style contain check boxes? I need small 
util, which will allow ppl to choose multiple items from the catalog 
at the same time.

Where can I find more info about API changes of RebGUI, which happened 
some time ago? I would like to get Cyphre's grid working, as it is 
many times better than table available, even without column resizing 
....

it was designed to be a rebgui widget  that was the prototype for 
table widget long time ago and a play for me on an amazing and very 
VID Topic " widget auto compositing subwidgets" widgetwriting widgets 
that's so neat  ^^

Ok so sorry for the time lost

can this be fixed easily?
 ... I'll try and grab some time to look at it later tonight.

Kinda ... maybe ... it might be a start; check out http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebdbgui.r


It's a sample I wrote for someone a long time ago.  It links the 
GUI fields to a RebDB database.  One way of doing it anyway.

Found it, and fixed in build #114. Basic rule in RebGUI is to fire 
actions on 'up and 'alt-up (to ensure they occur after unfocus) ... 
face-iterator was firing actions on 'down and 'alt-down. A nasty 
bug that's been there for a long time (and explains why I had trouble 
getting some requestors working in the past!).

This works:

>> SQL "select * from projects"                  

== ["1" "Critical Links" "9000" "Better project management." "Critical 
Links, Critical Time" "2" "Funda" "" "To get control of our ...
>> 

and this works:


current-projects: table (tab-size + 80x35) #HW options ["Priority" 
right .03 "ProjectName" left .2 "ExchangeRate" left .2 "Objectives" 
left .3 "Deliverables" left .0] data (1 2 3 4 5)

But the line in my post above doesn't work.

Robert and Graham, thanks, but I'm still not able to get this to 
work. Here is the data in the database (2 records):

>> probe (SQL "select * from projects")

["1" "Critical Links" "9000" "Better project management." {Critical 
Links project management software, Critical Time time management 
software.} "2" "RebDar" "9000" {Automatic full-metal backup to multiple 
hard drives.} "One REBOL script."]

Why am I getting:

** User Error: Table has an invalid data block
** Near: make error! error
>> 

What is wrong with the data block?

Graham, many thanks. I finally got it working. I believed you the 
first time. The problem was I was putting the compose/deep before/after 
"data" instead of after display.  I finally noticed where to put 
it in Ashley's docs after reading them about 50 times.  :>)

which means you can't access two sheets at the same time if they 
are using the same address range.

With one of my apps, I used win32 wrapper to get-window-text function, 
and I set window's text title. Not sure you can change title when 
you select different tab? What about setting one global variable 
for such purpose, which you would set each time when entering new 
screen? Maybe lot's of work to do it now, as you have 300 screens 
already, but :-)

Pekr/Graham (re group-box resize overlap convo from 13-Jan) ... it's 
a limitation not a bug. The #H and #W directives assume they are 
by themselves in a given row/column.


Instead of ... unview/only face/parent-face/parent-face ... why not 
unview/ony find-window face
 ... performance over coding efficiency.  


Ashley hasn't been on line here since xmas eve ... is he on a rather 
extended holiday

 ... the GFC has forced me to allocate considerable resources elsewhere, 
 but I'm back for the time being.


button is blue. But with over effect, going to green (default?), 
and with press, going pink

 ... the over (theme light) and press (state light) colors are global. 
 118 fixes the problem whereby these states lost your original color 
 override.


We have arrow key navigation of tables.  How can we get the enter 
key to do the action?
 ... add 'table to behaviors/action-on-enter

Both is good. That's a fairly simple change to tree.r ... if I find 
some time over the week I'll do it.

Hi Giuseppe, I'll respond in full to your questions here as I've 
had quite a few emails recently asking similar questions about the 
future of R3 and RebGUI.

As you have created the best GUI solution for REBOL2

 ... Thanks, remember that "best" is in the eye of the beholder though 
 ;) ... RebGUI was created only because VID wasn't up to the task.

I ask to myself why your still not involved in REBOL3 GUI.

 ... Apart from the fact that I cannot give the project the time it 
 requires, the R3 GUI is in far more capable hands than mine. I'm 
 looking forward to it making RebGUI obsolete! ;)


Are you waiting the final VID version to port your great experience 
in this area ?

 ... When the R3 GUI is stable I'll look at how best to port apps 
 from RebGUI to it. I'm thinking either a compatibility layer or an 
 outright script conversion utility. But while we wait for that glorious 
 future (stable R3/GUI SDKs on Windows, Mac and Linux) RebGUI is still 
 the only R2/GUI game in town (IMHO).

Puzzle time .... I have this


add2script: has [ t1 ] [
    display/parent "test" [

        t1: table 40x40 options [ "item" left .99 ] data [ "one" ]
        on-click [
            either value? 't1 [
                alert first t1/selected
            ][
                alert "t1 has no value!"
            ]
        ]
    ]
]


Now if this is invoked by single-click on an element in a table, 
it's fine.  If I invoke by double-click on the table to invoke, it 
 gives the error.   If I remove the single click action, and allow 
it to be invoked on double click, then it is also fine.

I got the idea to try this since somehow the local context was being 
clobbered.  So, creating a new context each time does solve the problem.

a print statement after this confirms the layout function is called 
twice on a double click

 ... as per documentation ( http://www.dobeash.com/RebGUI/user-guide.html#section-3.2.3
 ) "Every on-dbl-click event is preceded by an on-click event, as 
 shown in the following example: ..." But, the real problem here (as 
 you've discovered) is that the method for checking window uniqueness 
 relies upon a [title] string that only manifests *after* a layout 
 is substantiated. I suppose RebGUI could manage its own window title 
 cache, but then you introduce another point of failure (if the cache 
 gets out of sync with view*/screen-face/pane). I wonder if putting 
 a small wait value *before* the current title string test would "fix" 
 the problem (i.e. give the preceeding layout sufficient time to substantiate)?

Graham - it is not true. IIRc I prepared package which I sent to 
you, with primitive initial doc, with included rebgui version, and 
it was working. The bad thing is, that it is some early version I 
paid for, but at that time there were some API changes to RebGUI, 
and I was not able to further contract Cyphre to adapt it ...

feel: make object! [
		redraw: detect: over: none
		engage: func [face act event /local txt] [
			probe act
			
		]; fin engage
	]


then i create the distrubution then i run my "demo" app in the widget 
area-tc (custom) I see time and mouse related events but i never 
see keyboard related event

i tried on-key too  the key events can't reach the wdget for some 
unknown reason 

Well anyway i won't loose more time with that issue.

Graham and Izkata, thanks for the help.  But I must be misunderstanding 
something, as it is still not working. Here is what I have:

CONNECT/create/flat %cl.db

if error? err: try [
	SQL "select * from projects"
][
	er: disarm err
	if find er/arg1 "no such table" [

  SQL "create table projects (Priority, ProjectName, ExchangeRate, 
  Objectives, Deliverables)"
	]
]

do show-cc: make function! [] [
	display "CRITICAL LINKS Version 1.0.0" compose/only/deep [
		;image %chain.jpg
		return

  group-box "Critical Chain and Theory of Constraints principles" #W 
  data [

   text "1. REMEMBER YOUR PURPOSE" font [color: blue size: 26 shadow: 
   1x1]
			return
			;bar
			;return

   text "2. Free Up Your Major Constraint" font [color: red size: 20 
   shadow: none]
			return

   text "3, Focus on one project at a time---don't multi-task." font 
   [color: black size: 12 shadow: none]
		]
		at 103x14
		image %critical-chain.jpg 30x6
		at 133x2
		group-box "Redeem the Time" #W data [
			after 2
			label "   System Clock Time:" my-time:    text 28x7 "0:00:00"
			return
			bar
			return
			label "Average session time:" my-session: text 28x7 "0:00:00" 
		]
		return


  ;******************************************************************
		tab-panel #HWLV data [

                           ;******************************************************************
			"Projects" [
				label "Project Name:" ProjectName: field  141x5 

    label "Priority:" Priority: drop-list 30 #W "1" data ["1" "2" "3" 
    "4" "5" "6" "7" "8" "9" "10"] 10x5
				return
				label "Objectives:" 
				pad 131
				label "Exchange Rate" ExchangeRate: field 20x5
				return
				Objectives: area 200x10 
				return
				label "Deliverables:" 
				return
				Deliverables: area 200x10
				return
				label "Current Projects:"
				return

    current-projects: table (tab-size + 80x35) #HWLV options ["Priority" 
    right .03 "ProjectName" left .2 "ExchangeRate" left .2 "Objectives" 
    left .3 "Deliverables" left .1] data [(SQL "select * from projects")]
				return

                                                     button "Save" [

                     SQL reduce ["insert into projects values (?,?,?,?,?)" Priority/text 
                     ProjectName/text ExchangeRate/text Objectives/text Deliverables/text]
				    current-projects/redraw
			              ]
                                                      pad 20

                                                      radio-group 60x5 data [1 "Add" "Edit"]
				pad 20
				button "Quit" [quit]
                                         ]

I had a trac also on geekisp, but it was plagued by trac spam, and 
the site owner wasn't willing at that time to upgrade the trac to 
block spam.  So the only way to stop spam was to block all comments 
.. so I abandoned it.

Ashley, the options are ordered in time.

Ashley, that was a long time ago .. where would I have changed the 
font? :)

changed from single color web like look to some W9x look, was there 
any reason?
 ... commercial reality ;)
where would I have changed the font?
 ... ctx-rebgui/effects/font
request-char somehow misbehaves here
 ... bug, noted
fonts must be handled differently in w7s

 ... I don't have access to W7 at home, but will check this Monday 
 at work
where do I set my UI options?

 Design time with ctx-rebgui/effects, /colors /behaviors and /sizes

 Adding request-ui back so you can alter these values from a GUI is 
 trivial ... what I've removed is the rebind logic that enabled you 
 to dynamically change values (i.e. you would have to re-do %rebgui.r 
 to see any UI changes take effect ... not very practical for an SDK 
 app)
they look like W9x

 ... the color scheme (with the colors/page change noted above) is 
 taken straight from W7
don't like gradiented buttons/tab
 ... based on W7 and Mac
I thought Ashley wanted to go more web way, not desktop app way

 ... I've actually gone for something halfway (simpler than OS, more 
 complex than Web)
is it using a smaller font?

 ... 12pt by default as always (maybe W7 renders it differently than 
 XP?)
everything seems much smaller
 ... bigger screen? ;)
I would welcome tour.r would fit 1280x800 notebook

 ... RC1 is about getting the basic functionality right, %tour.r and 
 %RebDOC.r will both be made to run 1024x768
used to fit
 ... they havn't been reworked yet
Windows XP with 1366 x 768 ...
 ... will be fixed with above

Another discovery. One can only select one table at a time. This 
is more serious problem, me thinks. The previous one seems to work 
later, but directtly from display.
And it seems tha I can send more than 1 line at the time now.

This should address the table and disable issues raised above. WRT 
other issues:

stack overflow return
 ... could not duplicate this.
One can only select one table at a time

 ... select = focus, and yes, as focus shifts so to does the "selected" 
 row
And it seems tha I can send more than 1 line at the time now

 ... not sure I understand what the issue is here.Are we saying 'multi 
 is always on now?
hidden column

 ...I plan to properly support hidden columns ... if column width 
 is zero the face iterator will not create a face and it will not 
 otherwise be treated as a "column"
button widths

 ... the width sizing algorithm changed for button, label, heading, 
 etc (basically anything that appears on a single line)

 - previously you had to use -1 (or larger widths) to accomodate larger 
 text as the width was fixed

 - now it is fixed to the greater of it's specified width and it's 
 natural text width; and -1 sizes to the maximum of text width and 
 a line

 - there is no checking for button height (as it is assumed you would 
 either leave it at default 5 or have it larger

About my previous musing...

stack overflow return

 ... This is my fault as I  put ctx-rebgui/behaviors/tabbed: [... 
 (no table in)] in my little program. Need another safe way to do 
 that.
one can only select one table at a time
 ... not tabbable table is the only way
hidden column
 ... will use 0.01
button width

 ... basically when one specify [button 100] one get old [button 103] 
 but that's ok if we know it.

Another little observation.

This works correctly:-

>>display "" [p1: panel data [a1: area] button [set-disable a1] button 
[set-enable a1]]

This does not:-

>> display "" [p1: panel data [area] button [set-disable p1/pane/1] 
button [set-enable p1/pane/1]]  ;;  disable every time, enable never

Build 207
- Fixed slider bug (zero divide error when ratio = 1)
- Added find-key-face to needed funcs when not using view.r
- Added undisplay (does what unview/only does, but better)
- request-error now accepts string
- Removed gui-error (obsoleted by request-error)
- Removed find-face func
- Cosmetic changes to:
	- led
	- led-group
	- radio-group
	- chat
- Removed tip & over? attributes
- Made init, options & old-color attributes optional
- Made action & feel objects optional

- Replaced rebface, subface, gradface & btnface with baseface & gradface
- Added over? function
- icon changed to accept file name directly

- Added action/on-time event (used in conjunction with rate - see 
anim)
- Added table & text-list alternate row coloring

hence no further ability to mix VID with RebGUI
 ... correct.
promise of 

much lower" memory requirements, but the opposite is true" ... not 
quite. A lot has been added, in particular 4 inline images, without 
noticeably increasing memory. Also remember that many of the improvements 
(reduced dependency on View/VID mezz code) will only be apparent 
when using RebGUI with enface/rebface (tour.r uses 13,817Kb under 
rebview here, and 11,223Kb under rebface). Lastly, reduced memory 
usage is not apparent with tour.r as it doesn't reuse a lot of the 
same widgets (i.e. tour.r is a good reflection of "base" memory usage 
not runtime memory usage). If I find the time I'll knock up an example 
that demonstrate runtime memory differences.

say you have 1000 rows... but you only want to display 20 at a time

having all the data inside the table at once means big slow down 
time

Try this on 10, 100 and 1,000 rows:

d: copy []
loop 20 [insert tail d reduce [random 10 random 10]]
s: now/time/precise
display "A" [
	table 20x100 options ["A" left .5 "B" left .5] data d
]
print now/time/precise - s

seems to scale pretty well here (on a Mac).

the icons are loaded each time from disk?

Ashley;  RebDOC feature request.  How hard would it be to add a Keywords 
tab to this uber handy app?  (Second part of the request being a 
please please if it won't take too much of your time)