VID: clear-fields - how to improve it
[1/7] from: greggirwin::mindspring::com at: 27-Mar-2003 13:55
Hi All,
CLEAR-FIELDS is one of those really handy functions that annoys me. :\
It's very useful, but also problematic in that it only clears FIELD
faces, not AREAs; much less CHECK, RADIO, etc. *and* it only works if
a field contains a SERIES! value.
Admittedly, coming up with a completely general solution would probably
add lots of code, but can it be made better without too much effort
and added code? I think so, but I'm not sure how far to go, assuming we
want to submit the improved version to RT for future inclusion.
Here's the standard version:
clear-fields: func [
"Clear all text fields faces of a layout."
panel [object!]
][
if not all [in panel 'type panel/type = 'face] [exit]
unfocus
foreach face panel/pane [
if all [series? face/text flag-face? face field] [
clear face/text
face/line-list: none
]
]
]
This one works for AREAs as well, and sets non-series values to NONE:
clear-fields: func [
"Clear all text fields faces of a layout."
panel [object!]
][
if not all [in panel 'type panel/type = 'face] [exit]
unfocus
foreach face panel/pane [
if any [flag-face? face field flag-face? face area][
either series? face/text [
clear face/text
face/line-list: none
][
face/text: none
]
]
]
]
This one does the same as above, but tries to MAKE the type of value
that's in the field. E.g. numeric fields would reset to 0:
clear-fields: func [
"Clear all text fields faces of a layout."
panel [object!]
][
if not all [in panel 'type panel/type = 'face] [exit]
unfocus
foreach face panel/pane [
if any [flag-face? face field flag-face? face area][
either series? face/text [
clear face/text
face/line-list: none
][
face/text: attempt [make face/text none]
]
]
]
]
Beyond these simple kinds of changes, should we directly add support
for CHECK, RADIO, etc. or is it better to adopt a more general approach,
e.g. using a dialected block as a parameter, that you use to reset the
display in your app? The latter approach makes it more effort to use,
but potentially much more useful as well.
Any thoughts, or other implementations would be welcome.
-- Gregg
[2/7] from: atruter:labyrinth:au at: 28-Mar-2003 10:46
How about a clear-faces function that supports:
clear-faces/all
clear-faces/field
clear-faces/area
clear-faces/field/label/text-list
clear-faces/mystyle
clear-faces/my-style
clear-faces/my-date-style/default now/date
etc
The ability to clear by user-named styles would enable the VID designer to
control the granuality of the operation while keeping the function itself
as generic as possible.
The /default refinement would provide a handy means of assigning a value to
a style.
Regards,
Ashley
[3/7] from: brett:codeconscious at: 28-Mar-2003 13:46
My first thought (haven't tried it) is that the functionality could be
either part of the feel object or part of the style object. I would probably
lean to it being a part of the style/face object (just like INIT) as a block
that can be bound and evaluated by the clear-fields function at a later
time. So the clear-fields function is modified to just evaluate the
face/clear-fields block with some of the existing code in the function being
moved to the face/clear-fields block.
In this way it allows the functionality to be specified in a consistent way
with the rest of VID and allows for future custom styles. I wouldn't be
suprised if this approach could be generalised for other uses
(validate-fields?).
Regards,
Brett.
[4/7] from: g:santilli:tiscalinet:it at: 28-Mar-2003 14:07
Hi Brett,
On Friday, March 28, 2003, 3:46:02 AM, you wrote:
BH> I would probably
BH> lean to it being a part of the style/face object (just like INIT) as a block
BH> that can be bound and evaluated by the clear-fields function at a later
BH> time.
In my forms, I use custom styles that have at least two methods,
SET-VALUE and GET-VALUE. Basically for any "field" (whatever style
it is) in the form, FACE/SET-VALUE NONE clears the field. I use
this mainly to automatically translate from/to an object and a
form.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[5/7] from: greggirwin:mindspring at: 27-Mar-2003 18:40
Hi Ashley,
AT> How about a clear-faces function that supports:
AT> clear-faces/all
AT> clear-faces/field
AT> clear-faces/area
AT> clear-faces/field/label/text-list
AT> clear-faces/mystyle
AT> clear-faces/my-style
AT> clear-faces/my-date-style/default now/date
AT> etc
AT> The ability to clear by user-named styles would enable the VID designer to
AT> control the granuality of the operation while keeping the function itself
AT> as generic as possible.
AT> The /default refinement would provide a handy means of assigning a value to
AT> a style.
The trouble with this, in my view, is that you end up with either a
huge list of refinements - and the code to support them - or a number
of calls to the function to clear a particular subset of styles,
thereby losing the beneift of it. Plus, how do to tell it what facet
to change in each style (e.g. check/data vs. field/text)?
There are 3 attributes to contend with: STYLE, FACET, and DATA. A
catch with the DATA part of the equation is whether to distinguish
between mutable and immutable values (e.g. CLEARing series values
rather than setting them to NONE).
-- Gregg
[6/7] from: greggirwin:mindspring at: 28-Mar-2003 13:18
Thanks Guys,
Good thoughts, which sparked more ideas. Maybe using facets is the way
to go (per Brett's validate thought). If you use a DEFAULT and
VALIDATE facet, for example, you can provide values for them in a
style, process them in a number of ways, and extend the concept at
will. Of course, this goes beyond just improving the original function
in question, but maybe it's the better solution.
-- Gregg
[7/7] from: brett:codeconscious at: 29-Mar-2003 11:24
> If you use a DEFAULT and
> VALIDATE facet, for example, you can provide values for them in a
> style, process them in a number of ways, and extend the concept at
> will.
One futher thought. The Feel object handles the shared look and feel
behaviour
of faces, with the face object retaining the "state" of the
face. Maybe in a similar way instead of a facet in each face holding
clear-field behaviour, we could instead have a Model object that handles the
data manipuliation behaviour. Probably extra facets for specific default
values is still needed, but the idea is that shared code is in an object.
Unfortunately modifying vid for handling another object would be far more
complex than just adding a few facets.
Regards,
Brett.