On Mon, 7 Feb 2000, James Henstridge wrote:
> Sometimes a simple offset is not enough -- for instance, with flowchart
> box, one property corresponds to box->text->height, which can't be
> described as an offset in the box structure (although, in this case maybe
> making the Text structure a single property would be useful).
In that case, the current manual handling can be kept (offset set to 0 or
-1 or whatever). Most other properties of the current box code can be done
the way I described, though : already a saving.
For Text properties, maybe a special flag ? Or a different property type
(TextHeight) so that the property handling code "knows" what to do ?
> Another good idea. I think we may have touched on this in the last lot of
> properties discussions on the list. The save function could be a standard
> function, but the load one would probably need a small amount of object
> dependent code. Each object will need to implement the properties they
> inherit from Object, Element, etc. This should not be too difficult to
> do.
I had begun some code similar to the code you've brought up recently ;
though I never had time to bring it into something useful (and won't have
the time to, besides it being now pretty obsolete). I went to the
conclusion that each of the actions which can be done on a property (show,
apply, get_state, set_state, create, destroy, load, save) could be
automatic, but there has to be a way for the coder to require a manual
processing.
As for the "load function needs object dependent code".... load() can be
done as create() + set_state(). Really. We might loose a few microseconds
per object, but we also loose a hundred lines of duplicate code.
[ _[sg]et_state ]
> That should not be too difficult. I am not sure how many objects will
> require a get_state/set_state function now though.
Does your new interface make these obsolete ?
[ some place for notebook page specification ]
> Being able to specify some extra formatting for the properties would be
> good. I don't think it is worth making it complicated enough to build the
> UML class dialog though :)
Of course not. But already chronoref and chronoline, though
pretty straightforward objects, gain a lot from having a notebooked
dialog.
-- Cyrille
------------------------------------------------------------------------------
Grumpf.
