AltME groups: search

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

The above list is in chronological order, thanks to the zero-padding 
I used.

Can you mix vid stuff wih RebGUI s that I can perhaps use Henrick's 
list-view widget within rebgui?

It is a pity, as it it light-years more powerfull than table, which 
is just - plain vid list, with column resizing, nothing really more.

Got this on a edit-list 

make object! [
   code: 311
   type: 'script
   id: 'invalid-path
   arg1: 'dbl-action
   arg2: none
   arg3: none
   near: [p/parent-face/dbl-action p/parent-face]
   where: 'wake-event
]

and there are no actions  associated with the edit-list.

Looks like its been triggered by a double click. I don't think edit/drop 
list handled those... but they usually don't need to as the first 
click of a double click sequence is enough to select an item and 
close the popup. Odd.

Ashley I'm still seeing the dbl click on an edit-list bug

Is there a way to program a drop/edit-list to drop the list without 
having to click on it?

Thanks.

Graham, how about something like:

	display "test" [
		d: drop-list data [1 2 3]
		button [d/pane/action/on-click d/pane]
	]

In the following script I would like to be able to click on a row 
of the table to populate the data entry fields, so that I can edit 
the data for the record displayed in that row. How do I do that? 
 

rebol []
do %sqlite.r
do %rebgui.r
unless value? 'ctx-rebgui [

    either exists? %rebgui-ctx.r [do %rebgui-ctx.r] [do %rebgui.r]
]
set-colors
tab-size: 120x55

fonts: reduce [font-sans-serif font-fixed font-serif "Courier New"]
if not exists? %id.txt [write %id.txt 1]
either not exists? %indodex.db [
    CONNECT/create %indodex.db

    SQL "create table base (ID, Title, Nama, Alamat, Kota, Propinsi, 
    Telefon, Handfon, Fax, Email, URL, Tgl_Nikah, Nota)"

    SQL "create table birthdays (ID, Nama, Jenis, Hubungan, Tgl_Lahir, 
    Agama, Nota)"
][
    CONNECT/flat %indodex.db
]

do show-cc: make function! [] [
set-colors
(i: to-integer read %id.txt)
label-width: 19
f-width: 59
display "IndoDex Ver. 1.0.1" compose/only [
            button-size 16x8
            margin 1x1
            space 1x1
            ;image %roladex.jpg 
            ;return
            label 7 "ID:" id: text (to-string i) 7
            pad 17
            ;label 13 "Nama:" 

            title: drop-list 30 #W "Pak" data ["Pak" "Ibu" "Sdr." "Sdri." "Drs." 
            "Dr." "Tuan" "Nyonya" "Nona" "Pdt."] 17x5
            nama: field f-width
            label label-width "Telefon:" 
            telefon: field f-width
            label label-width "Handfon:" 
            handfon: field f-width
            return
            pad 31
            label label-width "Fax:" 
            fax: fax: field f-width
            label label-width "E-Mail:" 
            email: field f-width
            label label-width "URL:" 
            url: field f-width
            return
            pad 31
            label label-width "Alamat:" 
            alamat: field f-width
            label label-width "Kota:"
            kota: field f-width
            label label-width "Propinsi:"
            propinsi: field f-width
            return
            pad 31
            label label-width "TglNikah:" 
            tgl_nikah: field f-width
            label label-width "Nota:" 
            nota: field 139
            return
            return

            t: table options ["ID" left .03 "Title" left .04 "Nama" left .2 "Telefon" 
            left .16 "Handfon" left .14 "Fax" left .14 "E-mail" left .15 "URL" 
            left .15] data (sql "select id, title, nama, telefon, handfon, fax, 
            email, url from base") 270x150 
            return
            button "Add" [
                either all [nama/text <> "" nama/text <> none][

                    SQL reduce ["insert into base values (?, ?, ?, ?, ?, ?, ?, ?, ?, 
                    ?, ?, ?, ?)" id/text title/text nama/text alamat/text kota/text propinsi/text 
                    telefon/text handfon/text fax/text email/text URL/text tgl_nikah/text 
                    nota/text]

                    insert t/data SQL "select id title nama alamat kota propinsi telefon 
                    handfon fax email URL tgl_nikah nota from base"

                    ;a: sql/flat "select id/text title/text nama/text alamat/text kota/text 
                    propinsi/text telefon/text handfon/text fax/text email/text URL/text 
                    tgl_nikah/text nota/text from base"
                    ;sql reduce [insert table/data a]
                    id/text: form i: i + 1
                    save %id.txt i
                    clear-text nama
                    clear-text alamat
                    clear-text kota
                    clear-text propinsi
                    clear-text telefon
                    clear-text handfon
                    clear-text fax
                    clear-text email
                    clear-text url
                    clear-text tgl_nikah
                    clear-text nota
                    ;show id
                    t/redraw
                    return
                ][
                    alert {Cannot save if "Nama" field is empty.}
                ]
            ]
            button "Update" []
            button "GUI Info" [

                print [id/text " " title/text " " nama/text " " alamat/text newline]
            ]
            button "DB Info" [
                print [TABLES newline]
                SQLite/col-info?: true
                newline
                print [SQL "select * from base" newline]
                print [SQLite/columns newline]
                print [ROWS "base" newline]
            ]
            button "Halt" [
                halt
            ]
            button "Quit" [
                quit
            ]
]
]
do-events

I remember looking at this and concluding that ctx-edit.r would have 
to be changed rather dramatically to allow this ... it has to do 
with the order in which set-focus and show are called. Several minor 
hacks I experimented with (mainly in set-focus) just didn't cut it. 
I put it in the "too hard" basket but may revisit this now that the 
long-running (for me at least) pick-list bug has been fixed; and 
I also have a few users asking about this as well.

rebgui ver 93 seems to crash when a drop-list is double clicked

ver 93 seems to crash when a drop-list is double clicked
 ... fixed in later builds.

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

REBOL [
	title: "Weird error in area"
	Date: 04-Dec-2007
	File: %areaerror.r
	Author: "Johan Aires Rasten"
	Version: 0.1.0
]

do %rebgui.r


; Values of 25 or less doesn't produce the error, but larger ones 
do
max-info-lines: 26


display system/script/title [
	panel sky data [
		after 1
		button-size 30
		button "Status" [print-info "status"]
		button "Archive" [print-info "archive"]
		button "test" [
			loop 30 [print-info "status"]
			loop max-info-lines - 4 [print-info "archive"]
		] 
		button "crash!" [print 1 / 0]
	]

 info-area: "To see error: Press test button, then Status once" area 
 80x40 #HW options[info] data []
]

info-area-list: make list! []

print-info: make function! [
	info
][
;	Add the line to the buffer
	append info-area-list rejoin [info "^/"]
	if max-info-lines < length? head info-area-list [
		remove head info-area-list
	]

; set-text works, but it moves the scrolling area to the top
;	set-text info-area rejoin make block! head info-area-list

; This produces weird errors:
	info-area/text: rejoin make block! head info-area-list
	show info-area
]

do-events

Also, replace:

	info-area/text: rejoin make block! head info-area-list

with:

	info-area/text: form rejoin make block! head info-area-list

Forget my two previous suggestions and try adding the following line:

	info-area/text: rejoin make block! head info-area-list
	info-area/line-list: none	; line to add
	show info-area

in your RebGui tour under Configure UI, Behavior you have a tabbable 
field - among the widgets in there is drop-list. The Grouping tab 
cintains drop-lists among other widgets, yet I cannot tab to them... 
What am I missing?

Good spot, edit-list is tabbable drop-list is not.

How does attribute eval work for the data blocks of widgets like 
drop-list? Tried a few variations but none worked for me...

v: "Initial"
d: [a b c]

display "Test" [
	drop-list v data d
	return
	area
]

I have taken a deep look at the GUI System available for Rebol I 
and my choice has gone to RebGUI. I have taken a look to to list 
VIEW project too and I have a request/proposal: why don't you merge 
the list view into RebGUI. It is really very powerful, much more 
the standrd lists available in RebolGUI. It woul be an huge improvement 
and we will have a GUI system on steroids for DB projects.

Dunno how far is Ashley with the merge of Robert's RebGUI stuff, 
but once it happens, RebGUI will get powerfull enough grid (although 
not so powerfull as list-view) ...

why don't you merge the list view into RebGUI

RebGUI is 127Kb of source (just over 4,700 lines of code)
LIST-VIEW is 93Kb of source (almost 3,500 lines of code)


The largest RebGUI widget is currently TABLE with 10Kb of source 
weighing in at 329 lines. That's about the limit of simple that I'm 
prepared to deal with. The effort required to merge LIST-VIEW is 
huge (GRID less so as it's already a [albiet earlier] RebGUI widget).


I've had a few people say (via email) that it would be easy. OK, 
here are the source code links:

	http://trac.geekisp.com/rebgui/browser
	http://www.hmkdesign.dk/rebol/list-view/list-view.r

I'd like it merged and fully tested by Monday thanks. ;)

Ashley, my question is probably from a primer but someone told me 
that I can't use RebGUI and LIST-VIEW in the same project in 2 different 
windows. Would it be easier to make the two projects compatible instead 
of merging them ?

LIST-VIEW  seems very usefull when dealing with database viewing/modification/filtering. 
Even if they are merged it would be good to use them independently.

someone told me that I can't use RebGUI and LIST-VIEW in the same 
project in 2 different windows.
 They were wrong:

do %rebgui.r
do %list-view.r

display "" [
	text-list data [a b c]
	button [
		view/new layout [
			list-view with [
				data: [a b c]
			]
		]
	]
]

do-events

Henrick told me so, I supposed it was the programmer of LIST-VIEW.

Here it is what he has written: HENRIK: I don't think it can when 
using when using RebGUI, but I honestly don't know if you can mix 
VID and RebGUI windows. LIST-VIEW only works with VID.

list-view in rebgui:

rebol []
do %rebgui.r
do %list-view.r
				
display "" [
	text-list data [a b c]
						b: box 50x50 sky
						button []
		]

view/new layout [
			lv: list-view with [
				data: [a b c]]]
unview

b/pane: lv	
b/pane/offset: 0x0 
show b
do-events

Ashley, please confirm what I am understandig: when I will release 
a commercial application I will have to include VID, RebGUI, LIST-VIEW 
source (and SQL-Lite one) inside the application but everything will 
work flawlessy.

So, to use list-view as an example, you can now write:

do %list-view.r

display "" [
	area 60x40
	vid 60x40 data [list-view with [data: [a b c]]]
]

Magic, huh?

LIST-VIEW uses the LAYOUT keyword to generate row faces at least 
for edit fields, possibly other places (don't have the source right 
here). Try adding:

vid 60x40 data [list-view with [data: [a b c] editable?: true]]

and double click to edit

Only works with:

	area
	field
	edit-list
	button

widgets at this time.

Not soon. This is a hack to support common editable widgets, whereas 
a proper solution should support every widget that is editable *and* 
selectable (e.g. tab-panel, table, drop-list, check, radio-group, 
etc). It means adding 'info support to a lot of widgets that currently 
do not have it.

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

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.

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)

What color does it use for borders?
 ... none, it's transparent.

will sheet and tree-view support at least keyboard basics?

 sheet already supports tab, tree at present has no keyboard support. 
 These are on the "things I'd like to improve one day if I have nothing 
 better to do" list. ;)

well, I believe some of the small details can be fixed. I could easily 
name them, list them here, if it would help to answer us, what is 
fixable, and what is not (e.g. due to View inefficiency in particular 
area)

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.

List of some inefficiencies of RebGUI - decide what could be fixed 
with no significatn effort (e.g. widget redesign or particular subsystem 
redesign (tabbing))

1) no keyboard navigation to swith between the tabs (ctrl + tab)

2) no default focus on page? (maybe just not defined in tour.r), 
but if there is e.g. table, I would expect it being in-focus, so 
that keyboard immediatelly works without the need to click the table

3) are othere elements tabbable? I noticed that e.g. on tab with 
sheet demo, buttons are tabbable. IMO there should be also one primary 
element selected as being "in-focus", it should be reflected in UI, 
or I regard it being faulty.

4) sheet widget - define ENTER action doing the same as TAB action. 
Enhancement request (not necessarily needed) - ability to define 
tab/enter movement direction - vertical vs horizontal.

5) menu - when mouse moves, menu should collapse/expand upon the 
movement, not needing 2 clicks (to collapse old position menu, and 
another click to open one - please reduce at least to one click)
6) tree-view - add arrow support
7) area - hilite by mouse or keyboard should auto-scroll area

8) state elements - add tabbing support with visual reflection - 
imo you are wrongly assuming, that users might not use keyboard here 
(space selects)

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.

RebGUI color management.


The "old" RebGUI color management system evolved by adding new colors 
to ctx-rebgui/colors as and when a new color was selected. Many of 
these colors (e.g. button, tooltip*, btn*) were widget specific. 
In all, 15 colors were defined. In addition to this, a number of 
hard-coded colors such as white, black, coal, red and blue were scattered 
throughout the system.


The effect of all this was to provide a means whereby *most* colors 
could be changed, but the design of a "theme" other than the default 
WinXP scheme was problematic.


The new color management system rationalizes these colors down to 
a base set of 8, being:

	page
	text
	theme-light
	theme-dark
	state-light
	state-dark
	outline-light
	outline-dark


with all existing "old" color references being converted to the "new" 
ones. page and text will usually be white and black (high contrast), 
with outlines being grey, and theme and state being variations on 
the same color. The updated request-ui shows how these themes can 
more easily be chosen (there is a drop-list beneath each of the theme 
and state groups that sets both light and dark to a similar color).


This is still a work in progress, and I am basing the model (and 
color selections) largely on those described in the "Quilt design 
style guide"; and colors / ideas from:

	http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

 http://library.gnome.org/devel/gtk/unstable/gtk-Resource-Files.html
 (styles section)

A number of things have to come together to make this work:


 1) Conceptual model: do we have the right tokens to reflect all color 
 configurable aspects of the UI (e.g. is there a color word appropriate 
 for a highlight selection, a heading, etc)

 2) Are they named appropriately (e.g. is selected better than state-light?)
	3) What colors should be used in what context?


This last one is very tough. As a general rule I've followed the 
Quilt model and used outline-light for non-edit edges, theme-dark 
for edit edges and heading backgrounds, etc (you can find a crude 
list of usage cases under the new "Colors" tab of RebDOC).


But what about a widget like button? It potentially has the following 
color states:

	Unselected	theme-dark
	Focus		theme-light
	Button-down	?

and widgets such as sheet which might have:

	Headings	theme-dark with page font/color text
	Cells		page
	Edges		outline-light
	Selected cell	theme-light
	Forumla cell	theme-light
	Cell that cursor is currently over

and there are a number of ways of denoting this with color:

	as a background color change
	as a font color change
	as an edge color change
	as a combination of the above


In short, there are a lot of ways of implementing this. What I want 
needs to be simple and consistent with as few colors as possible. 
Any suggestions (including links to good color management techniques 
/ approaches) greatly appreciated.

latest checkout


>> display "" [ sp: scroll-panel data [ field 10 "Hello" ] button 
"get values" [ probe get-values sp
]] do-events
** Script Error: foreach expected data argument of type: series
** Where: get-values
** Near: foreach widget face/pane [
    if find [

        area check check-group drop-list edit-list field group-box password 
        rad...
>>

I've got some drop down lists that are inside a scroll panel, but 
the bottom of the drop list goes beyond the bottom of the scroll 
panel.  this means that I can not see the bottom of the list and 
because there's no keyboard navigation of the drop list, I can't 
choose the bottom choices.

http://synapse-images.s3.amazonaws.com/drop-list-display-problem.png

That would be it. Unlike other list widgets, which use a face iterator 
to only display visible faces, tree takes a brute-force approach 
and pre-builds the entire tree based on face/data. At runtime it 
uses face/data to work out where to position faces.

I did. Correct me if I'm wrong but it's only a problem in scroll-panel's 
that can scroll vertically? Is there a real (as opposed to theoretical) 
usage case where you'd need a drop-list in a vertical scrolling panel?

Just had a look at the source again ... as the droplist-mode for 
drop-list gone?  We used to have the option of setting 'auto, 'middle, 
'upward and  'dowward

Looks like my problem was that I had nested tab-panels,and the inner 
one with the drop list was deeper r than the outer one.

and the outer tab-list cut off the bottom of the drop list.

Temporarily solved the drop-list problem in a scroll panel by just 
doubling the data in the list ...

Carl's Rebodex has something like what you describe.  It filters 
the data in a list rather than a drop-down type widget, but that 
would be easy enough to change.

Note that drop-list / edit-list already have this feature.

graham, to me it would be faster to type than to select from a list, 
for most words. so it would really be just annoying. it can only 
help on longer words of which i'm not sure about the spelling...

different point - is it necessary for the highlight to be removed 
from a text widget if the focus has gone elsewhere?
It doesn't happen with list widgets

Yes, text focus is implemented via View's caret handling functions 
which enable portions of text to be highlighted ... contrasted with 
list widgets which either highlight the entire row (or not).

I would like to double click on the choices in the edit-list, but 
that then results in loss of the highlite on the selected word.

Also, I would like to see some way for the text to scroll following 
the highlite, and currently I have to move the slider manually.

Quite possible ... I'm looking at a 'no-focus option that would allow 
you to click certain widgets (e.g. text-list) *without* changing 
focus. This option would be the exception rather than the rule.

A set-info func is in the works, but requires some rather extensive 
widget changes (e.g. drop-list and edit-list are different widgets 
at present).

Well, we need to be able to specify a column, or a list of columns, 
 and a test on that column(s).

The problem's a bit more general than table data then ... what happens 
when this decimal value appears in other widgets (e.g. text, field, 
drop-list, etc) ... fix needs to be at the native level ... perhaps 
we need to patch 'form as an interim measure? Is this a windows only 
issue?

I tried once.  But it was more an exercise in linking RebGUI menu 
Find/Replace to area ... too many hacks to keep caret in synch, so 
instead of tarnish Dobeash with my lousy code ... I just didn't. 
  But a quick RebGUI display of an area isn't too hard to pull off, 
but you need to rely on the built in key handlers.  Sadly Find/Replace 
is not in the list, but you do get a spell checker 'for free'.  ;) 
  In Ashley's defence, it is not the design intent of RebGUI to be 
an editor.


I've not tried, but Anton has been pumping out a new editor ... may 
conflict less than  editor  dunno, but I kinda doubt it will work 
without the same types of problems.

Alternative is to use CALL and launch an external editor.

Support request on Mailing List:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlRHXC

Ashley, the tree widget is not indexed here http://trac.geekisp.com/rebgui/wiki/WidgetList
though it appears in the source code list

well, I have had a similar problem.  I have a drop-list with title 
in it followed by a radio-group with gender, followed by occupation. 
 I want the user to skip the radio-group which is set based upon 
the droplist value.  Eg. drop-list is "Mr." and so set the radio-group 
to "M" and then skip to occupation.

display "" [ edit-list data [ "Mr." "Mrs." "Dr." "Miss" ] return 
field ] do-events

and of course this is a major impediment to using the keyboard.  
So, for an edit/drop list you have to click twice - once to choose, 
and then once to regain the focus.

it works the folowing way you build a data list and then you pass 
 it in arg into your display block

ana  button call for anamonitor wich helps me to debugging and no 
my list-view don't works anymore with recent rebgi version (it was 
done with rebgui 0.36 ... )

w: has [][
	display "" [
		f: field
		do [ set-focus f ]
	]
]

display "test" [
	button "Focus Test" 20 [ w ] 
	return
	text-list 45x45 
	data ["W" ] [
		switch face/selected [
		"W" [ w ]
		]
	]
]

What's going on here?  If you use the button, the field f focuses 
okay.  Use the text-list, and the focus does not appear.

the equivalent VID code


w: does [
	view/new layout [
		f: field
		do [ focus f ]
	]
]

view center-face layout [
	button "Focus Test" 90 [ w ] 
	return
	text-list 100x30 
	data ["W" ] [
		switch face/text [
		"W" [ w ]
		]
	]
]

works as expected.  No focus issues.

Excellent ... the drop-list focus is also fixed

>> display "" [ text-list data [ "test" ] [ print "click" ][print 
"alt click" ] [print "dbl click" ]] do-events

looks like double click no longer works now.

hi every one . i would like to know if it is possible to change color 
of row in widget table ? . or if i must prefer use table-list of 
shadwolf ?

shadwolf do you have a compatible widget table-list with rebgui-bluid 
114 thank you in advance ?

amacleod ----> http://shadwolf.free.fr/RebGUI-038-shad.ziphere is 
a working version of rebgui + my list list-view

Graham - there are some aproaches out there. Some apps choose some 
pre-app-run dialog box, which let's you select, where you want to 
go. I am not much comfort with it, e.g. Open Office 3.0 starts that 
way. Othere do use different aproch, e.g. - on the left side, you 
have icon-list element, which can be even tabbed. That defines your 
right pane content

http://www.megaleecher.net/uploads/spybot_search_and_destroy.jpg


You can have many icons, on many tabs, so many options of how to 
organise your content pane ....

This is an odd one


display/dialog "test" [ edit-list "1" data [1 2 3]  return text "some 
space"] do-events

click on the edit-list, and tab out .. the window disappears

Doesn't happen with drop-list, and doesn't happen with display/parent

There's another thing with edit-list.  Unlike a drop-list, you can 
tab into it, and use the down arrow to cause the list to drop, but 
you can't use the keyboard to select a value.  You have to switch 
to using the mouse.

Tracked down the edit-list tab problem ... it's the on-unfocus handler 
it inherits from drop-list that is causing the problem. Need some 
way of conditionally wrapping the hide-popup so it only does it if 
the edit-list is actually active.

Other issues are noted.

however main goal of rebGUI was to provide a cool widget enhancement 
library for VID propose a "example" set of widget people want to 
use the most in their software ( well that list of widgets can be 
found in any advanced graphical library such as GTK+ winap32 aqua 
QT WxWindows Tcl/tk etc...)

however, I can't reproduce it outside my app yet.  
Now if I replace the above with 

add2script: has [ tl ][
    view/new layout [
        t1: text-list 100x100 data [ "one" ] [ print t1/text ]
    ]
]

then double click always produces two windows ...

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

Since we no longer have access to the geekisp trac and issues database 
... would all of those who remember any existing issues please enter 
them into the new issue tracker.
http://rebgui.codeplex.com/WorkItem/List.aspx

In build 122, in tour.r  and in List/Tree the right hand tree is 
now missing.

In List/Table, if you click on the table,  you can tab in and out 
now if the Look & Feel/Behaviors/Tabbing .. if you add table and 
text-list

re: list/tree missing ... a half-implemented change that I had to 
pull out several builds ago.

Uploaded build 123 with tab-thru implemented as described above (except 
that tab-panel doesn't cycle each tab). Also fixed initial text case 
(stack overflow) and a long-standing text-list bug (no cursor control 
when select-row used).

RebGUI v2 RC1 (build 200) uploaded to SVN

Focus of this version has been:
	* Make it look good (color scheme based on Windows 7)

 * Take into account OS sensibilities (different corner rounding, 
 window colors, system fonts)

 * Get rid of the cruft (removal of little-used widgets and options)
	* Improve tabbing
	* Make it load and run faster



Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?



Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color



Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font



Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]


WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

hmm, SVN says:

RebGUI v2 RC1

Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?

Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color

Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font

Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]

WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

One note to drop-list. Apart from the fact, that it can be closed 
only by pressing ESC, it does a little bit weird thing - it remembers 
its last mouse-over element. So mouse-over some drop-list item, then 
go-away from it, then press ESC. The value of drop-list changes to 
that last remembered mouse-over one ...

Marek, good pickup ... I'll add that to the list of fixes.

I hope I nailed down my table problem now.

It seems that one can select from all text-lists on display, but 
only one table is selected from - selecting next one deselects previous 
one. Tabbded on not is not the problem.


Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.

title-group and image RebDoc section depend upon image ...
 Fixed in next build
scrollbars are behing a little weirdly
 ... noted

basically when one specify [button 100] one get old [button 103] 
but that's ok if we know it
 ... ah, I understand the issue now. Fixed in next build.

I hope somebody else was using this feature so it's not only me using 
before and wanting it.

 ... don't worry, I think the issue is that table needs to differentiate 
 between a selected row and a row that has focus. This was not an 
 issue in previous versions as table was not a tabbable widget. Will 
 be fixed in a future build.

Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.
 ... on the list to fix
Another little observation.

 ... that's an interesting bug and I have no idea at this stage why 
 the 2nd case doesn't work. Needs further investigation.


Good work marek (and others) ... we're slowly but surely ironing 
out the issues.

Build 205
- Added request-list
- Added request-email
- Added do-events
- Updated request-spellcheck (added image)
- Updated request-error
- Updated request-value
- Label size now defaults to 25x5 (was -1x5)
- Replaced "attempt" logic tests with "error? try"
- Memory footprint drastically reduced
- Added no-wait to display func
- Updated request-progress to use display/dialog/no-wait
- Fixed button over state bug
- Fixed slider jerkiness