Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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.