World: r3wp

another "bug" - maximize demo .... move last column to righ, minimize 
back - you can't see last column and there is no chance how to get 
to it .... I would expect horizontal scroller to appear ...

as for text-list multi-selection - dunno if I was understood incorrectly, 
or it was my fault to provide you with not so accurate description 
of how multi-selection with shift works .... however - it should 
be easy for you to check - just start Explorer and play with shift 
multi-selection ...

when you hold shift, it should remember the "last" press, but it 
means last before you pressed the shift. And that last point should 
not change. So - if you then select some other row, whatever the 
row is, it should still hilite rows between the initial point, and 
the point of your actual selection ...

I selected incorrect word last time .... "last" meant "initial" - 
it should work like anchor ..... simply you have one row selected 
..... once you press shift, no matter what happens, that hilited 
row becomes kind of anchoring initial point. Then when you select 
whatever row, everything in between anchoring initial position and 
the point of your actual selection becomes hilighted/selected ... 
ufff, somehow can't express myself :-)

otherwise ctrl and other multiselection functionality is correct 
...

Why does using alert sometimes close down the window it is being 
called from?

Haven't come across that one before. When it's happened was there 
anything in common between occurrences (I'm assuming its too sporadic 
for a reproducible test case)?

Any plans to write accessor functions like 'get-text ?

I guess what's happening is that 'alert shuts down any modal screens 
showing like this:


display "" [ text "Non modal screen" return button "dialog" [ display/dialog 
"Test" [ text "Modal Screen" retur
n button "Alert" [ alert "hello" ]]]] do-events

display "" [ text "Non modal screen" return button "dialog" [ display/dialog 
"Test" [ text "Modal Screen" return button "Alert" [ alert "hello" 
]]]] do-events

No plans with 'get-text, unless it was to do something over and above 
what face/text does (i.e. trim then show).


The alert problem is related to RebGUI's liberal use of hide-popup 
to cope with drop-lists and edit-lists that need to be closed when 
another one is opened. I figured at the time that having more than 
one non-modal dialog open at the same time probably didn't make much 
sense - although an alert from within one is a valid case [in hindsight].

I just noticed that you can't initialise the data in a table with 
a copy [], but you have to 'clear it instead.

table/data: copy []
append table/data [ ... ]
table/redraw 

does not work

but 
clear table/data
append table/data [ ....]
table/redraw 

does work

Ashley, can we fix it so we can allow alerts within a modal window?

The other thing ( small ) is that rows from a database are normally 
returned like this


[ [ .... ] [.... ] ] whereas table expects it's data like [ ............... 
]

we have to flatten it before sending it to the table.

Alert ... to be fixed.


Table data is normally changed with "insert clear data [...]" - this 
optimization needs to be documented.


The table data representation shows my bias towards a simple flat 
structure and is compatible with RebDB (representing each row as 
a block makes sense for small volumes of data but is wasteful once 
sizable numbers of rows are being managed).

Good observations, keep them coming. ;)

I guess the slight problem with a flat structure is that you have 
more interdepencies in the code


With a flat structure, I have to know that there are 4 elements in 
each row

row: skip face/data first face/picked - 1 * 4

Whereas with blocks for rows I can do this instead

row: skip face/data first face/picked - 1

that should be .. face/picked/1 - 1

From my experience with Cyphre's table style, it makes sense to use 
a name/value block for the data. With this you can throw a block 
in any order and even one, that has more fields than being displayed. 
The latter makes a lot of sense if you just want to get back an internal 
ID.

Also, when removing rows from a table, you have to remove each item 
in a row, rather than just the one block

One problem is sorting; You need to extract the row you need to use 
for sorting, create the sorting sequence and rebuild the block. Or 
is there a faster way?

How does I detect a close event in the main window so I can do a 
clean up ?

Not easy at the moment. This probably needs to be a refinement handler 
block like scroll.

Is there an updated list of the outstanding issues?

Latest build available at: http://www.dobeash.com/files/RebGUI-037.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:

	- Close handler refinement added to display function

 - Closing the main window when more than one is open now prompts 
 for confirmation

 - New 'after keyword added to layout (helps with displays that arrange 
 widgets in one or more columns)

 - Fixed major bugs with 'at positioning and window size determination
	- Couple of layout 'reverse bugs fixed
	- Documentation updated to reflect above changes
	- Number of minor bug fixes

In the works

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

Cool.

I owe you my opinion on field level validation probably, so here 
we go ...

As I already said, it is imo insufficient or even let's say incorrect 
to base field validation upon rebol datatypes. As we can't have our 
own datatypes, those available are just some kind of primitives, 
not of much of a use ...

mail: make email! [petr-:-nonsense]
type? mail
== email!

Back in old DOS days, with tools we worked with, we had following 
available:


1) VTG (Variable To Get) function - you could specify VTG$("AB"), 
and user was able to only enter A or B letter, nothing more - we 
used it to limit letters for floppy disk access


2) we had system of field-masks .... e.g. tel-number: (999) - 999 
999 - then all non num chars were displayed in field, you could not 
delete them, they were skipped, and you was only able to write numbers 
.... if you wanted to allow chars, you used "X" insted of "9". Pretty 
powerfull concept - not too much complicated, and allowing you to 
limit bugs ppl can enter ...

In CA-Visual Objects, the logic was even more abstracted - you e.g. 
defined DB field tel-num, char(20). That field, you could use across 
your tables, and from the application pov, you defined mask objects 
- you could e.g. have different mask objects, defining behaviour, 
validation, mask, tight to the same tel-num, char(20) field ...

I don't know how to do it best in REBOL, maybe a mask dialect, or 
directly a parse block? That is upon clever heads here :-)

One of the most difficult fields was date entry field 99.99.9999, 
with VO we had three or more implementations. Native one pretty sucked 
- it is all about what chars you allow, what happens if you press 
tab, del, how is field hilighted by default, what part is hilighted, 
if your backspace key deleting letters stops at dot or not etc ec. 
With date field - do you want to allow user to enter any number? 
67 or other number is surely not a good day-number, is it? :-) Now 
do you want to disallow user to type nonsense directly? How do you 
know without linking it to calendar? Or do you do your validation 
when leaving your field? Some ppl do validation once per form, e.g. 
when you try to press "Save" button (not my preferred way, at least 
for some field-types, but some do prefer that) ...

I don't want to complicte the whole thing - but if you are about 
to add some functionality - first answer to yourself some of above 
questions - because semi-functional solution is not a solution for 
me and in that case it is just becoming a bloatware, which sooner 
or later, will be replaced by custom solutions, as ppl simply will 
need above functionality. And the worst possible thing is, if your 
solution does not allow to be replaced in an easy way ...

Some of those are philosphical questions about application design 
/ user interface.

For example, I have one application that permits things like "Not 
sure, maybe next tuesday. must ask Bob" in a date field.

That's perfectly valid until they click the "publish" button. Then 
we need a real date. So *private* data conforms to their rules; *public* 
conforms to ours.

perhaps we need different field types.

field accepts every character, but if I had integer-field, or alpha-field, 
or bitmask-field .. it would help.

it sucks having to validate after the event.  better to stop the 
user from entering the characters in the first place if we wish to 
disallow them.

Graham - aren't character of integer field another level of complication? 
Let's have one type of field, with kind of clever masking/validation 
- then, using the SAME rules, let's define your character or integer 
field, please ;-)

*Some* validation can only happen after the event -- unless you enforce 
the order in which fields are completed. And even then it's not always 
possible.

May you need some lightweight masks for simple things. Plus the ability 
to skip off to a tailored validation function for the more awkward 
stuff.

It depends upon how easy this is to implement.

... it was just food for thoughts from my side - maybe most of developers 
don't need such advanced functionality ... so let's think about possible 
ways of how to implement that and then let's present some solutions 
...

I am currently doing field validation by datatypes, but it does have 
it's limitations as Pekr says.

Is a zip code an integer! or string! Is a password field string! 
or integer!  ?

zip code might by an integer, if the space used in that is part of 
your mask - e.g. in CZ we have "739 92", PL uses "73-992" etc.

(not mentioning some countries, which allow chars,not just digits)

Good questions.....A zio code format depends on the country....even 
if you switch masks vy country name, the country name may be entered 
after the zip code.

You'll only handle that correctly with post-form completion validation.

vy == by

load  "739 92"
== [739 92]

imo some simplified parse dialect could work (we have Gab's parse 
rules, so we could be able to define parsing rules dynamically, or 
we implement it other way, dunno), the tricky part could be, if you 
would like to do validation upon each event (key-press), or only 
when your field is losing focus ...

in some ways you have to implement a mini editor for the field.  
prevent scrolling. skip over characters.