World: r3wp

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.

Back again regarding the data format for tables, sometimes I want 
to include a database key in the data without displaying it.  So, 
it might the 3rd element in a row where there are only two columns 
displayed.  With a flat data spec, I can not do this.

Also, I don't know if this is intended, but if you manage to click 
on the arrow in a table header, nothing happens.  to sort, you have 
to avoid the arrow.

show-focus highlights all the text in a field. Wonder if better to 
just show the cursor at the end.

Note the following user-configurable blocks under ctx-rebgui/edit:

	tabbed: [area field edit-list password button]

	hilight-on-focus: [field edit-list]

	caret-on-focus: [area field edit-list password]

	action-on-enter: [field edit-list password]


But its probably a good idea to agree on the "correct" default behaviour 
anyway.

show-text ( I think ) should set the slider back to the top when 
used with an area widget.

If you do a show-text area {some rather large text},and then do a 
show-text area with small text, the small text appears at the bottom 
of the area field.  If you then click on the area field, it moves 
to the top.

You have to use the slider to move to the bottom of the large text 
before showing the small text to see this.

Area / scroll / slider reset definitely needs more work.

Thanks for commenting James.

Should a double click also fire the single click action ?

It does by default as a double-click generates two 'down actions 
with the latter having event/double-click = true. This is usually 
a good thing anyway as (in the case of lists with a highlight bar) 
double-clicking a new entry automatically triggers the default single-click 
action (highlight a new row) plus the double-click action we are 
interested in trapping.

Any reason why request-file has lost the /keep refinement ?

Version 1.3.1.3.1 has /keep. Is it in a newer version?

Rebgui redefines 'request-file without the /keep refinement

Oversight I think. ;)

Ahh....

I'm doing some async io, which works with View, but in Rebgui, I 
get the following error when I click on my button

make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [if pf/data <> face/data [
            old: pf/data
            if old [
                clear skip pf/pane/:old/effect/draw 7
                show pf/pane/:old
            ]
            pf/data: face/data

            insert tail face/effect/draw [pen leaf fill-pen leaf circle 6x10 
            3]
            show face
            face/action face
        ]]
    where: 'switch
]

nope ... something else going on.

I think, that Cyphre will be able to give you an advice on that

it was my fault