World: r3wp

Graham, I think a clear-widget accessor (with a "/default value" 
refinement) would make a good addition.

What do feel about adding a right mb click to tables ?  Just thinking 
of way to remove items from tables.

Sounds reasonable. What about a double-click action as well? I was 
thinking of expanding the layout parsing rules such that *any* widget 
could be specified as:


 widget [default left-click action] [default right-click action] [default 
 double-click action]

but I'm not sure whether this is overkill or not.

choice is good... already have tristate widgets :)

It also means we have a cleaner screen .. fewer widgets to clutter 
it up to do the things we need to do with tables ie. add, remove, 
elements

Another wish for tables .. a way to set the colour of a row, which 
is controlled programmatically.  So, you might have a table of messages 
in your inbox, some of which you have read ( one colour ), and those 
to be read ( another colour ).

Ashley, good idea. As long as the later two are optional.

display "" [ p: password return button "Login" [ if empty? p/text 
[ show-focus p ]] do [ show-focus p ] ] do
-events


if you tab out of the password field, and then activate the button 
with the spacebar, the password field fills with one character.

tabbing does not seem to work between fields in a modal window.

the docs says that display has a /layout refinement, but it doesn't.

Looks like the layout is not parsed correctly when you specify a 
modal layout with /dialog

Retract that last statement.

Should <CR> act the same way as tab in shifting focus ?
Should tab also fire an action associated with a field ?

display "" [ group-box 60x20 "Test" data [ a: field 40 [ show-focus 
f]] return group-box 60x20 "Test2" data
[ f: field 40 ]] do-events
** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:


After typing a few times in the top field, and then hitting enter, 
the error above can occur.

CR: For single line fields OK (in addition to TAB), for multiple 
NO. Standard is to use TAB to shift focus.

In that case, actions should fire on tab and not just on cr as at 
present.

Ashley, how do I set the radio buttons?  I tried this


 display "" [ sexfld: radio-group 30x5 data [1 "M" "F"] button "change" 
 [ sexfld/data: 2 show sexfld ] button
 "show" [print sexfld/data ]] do-events

Simulate a click, as in:

	button "change" [
		sexfld/pane/2/feel/engage sexfld/pane/2 'down none
	]


but long-term this needs to be handled by a generic show-widget function. 
Other points above have been noted. ;)

Yep, that works.  Thanks.  I am trying to provide field level data 
validation so do need actions to fire on tab as well as on enter.

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

display "" [ group-box 60x20 "Test" data [ a: field 40 [ show-focus 
f]] return group-box 60x20 "Test2" data
[ f: field 40 ]] do-events


type abcd in the top field, hit enter.  Type abc in the bottom field, 
and hit enter.  Then hilite all the chars in the top field, enter 
a single character, and hit enter.  

** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:
>>

This is version 3.6

What we need is a key logger to record all the keystrokes so we can 
easily duplicate these errrors.  Took me  a few mins to duplicate 
it.

In tour.r, the simple led example, I see nothing happening when I 
try the three buttons ( true, false, and none ).

In the led-group, the "random 1" button only seems to affect the 
Item 1 in the horizontal group ( only turns it off ).

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

Can clear-widget also be made to take a block of faces

should clear-text be generalised to also clear the rows of a text-list 
and table ?

Focus question. Given that CR and Tab should fire a field's action; 
should loss of focus due to mouse click do the same (i.e. should 
clicking in field1 then field2 cause field1's action to fire)?

I suppose

Me too. Suppose the clicked face is a "save". That would expect all 
the fields to be entered, means fired.

Yes, same semtantics to the program just an other user action to 
activate it.

I think it should too.

Otherwise field level validation becomes trickier to do.

should have the option for area widgets though as in VID.

Compare these two:

display/dialog "" [ f: field return p: password  ] do-events

and 


display/dialog "" [ f: field return password do [ show-focus f] ] 
do-events


Adding the show-focus adds a cursor to the password field as well.

Ashley, what do you think of adding in some way of assisting with 
field level validation.  I was thinking of perhaps an optional dialected 
block that specifies if the field is of date type, not null, character 
length min/max, and for passwords, sufficiently complex.  That way 
when building database applications, you can specify the table constraints 
at the field, and let rebgui automatically enforce that.

Hm, those were my first programs in 6502 machine code: validating 
field input routines to call from Atari BASIC. :-)

The problems is how to do the feedback on input errors. This may 
have to be customized for a given program. I kept it simple and just 
made it beep :-)

My tentative design concept for field level validation at the moment 
is to allow a block of REBOL data types to be specified, such as:

	field options [integer! decimal! none!]


with invalid input changing the field color and not allowing focus 
to leave. Successful validation would restore field color and place 
the loaded face/text contents in face/data. Haven't thought about 
min / max lengths, although an empty field would be treated as none! 
so null / not null is handled by default.


The password suggestion is a good idea, perhaps a min/max length 
option and a 'dict option that ensures the password contains no spaces 
and does not appear in the currently loaded dictionary?

yep, or we could enforce an optional complexity rule such as contains 
mixed upper/lower case digits and punctuation marks

ie. the rule can be defined by the user, and the gui allows us to 
specify a rule.

If you make the rules that complex, I think there should be a way 
to give custom feedback, like displaying an error message

Ok, perhaps use the action block for that.

Ashley - pressed for time, more on that later, but basing field values 
upon datatypes is not imo good way to go ...

And the alternative is?

I'm willing to bet Petr wants an evaluation function, like in Lotus 
Notes ;-)

Which is indeed very flexible, but data types would be a good default

There's a problem with money, though, because the REBOL 1'000 syntax 
is not the human 1.000/1,000 way

(Not that there isn't always a problem with money ;-)

My thought is to have two parse rules -- one evaluated on keypress, 
the other on exit (of field).  The exit parse rule would be strict, 
the keypress one would allow for partially completed entry, but denies 
a keypress that fails the rule.  The two parse rules could be passed 
as arguments or created from a dialect?