| From: | Gabriele Svelto |
| Date: | 03 Aug 2000 at 21:46:58 |
| Subject: | Re: BOOPSI again & again |
Hi Allan,
> Yes. This allows notification, binary compatibility etc.
Understood, thus if I change for example the size of a gadget it's superclass could want to redraw the objetc, but to be informed of the size change it must have come from a SetAttrs().
> Generally yes. I think using SetGadgetAttrs() supplies the receiving
> object with enough info to do an ObtainGIRPort(), which some gadgets
> need... I'm not really familiar with C='s BOOPSI gadgets, only MUI,
> which doesn't have such problems ;-)
I'll try searching the RKMs on this subject (the BOOPSI section is probably the worst in the whole manuals!)
> This depends on wether (and when) you want the functionality of your
> superclass. Imagine 3 different examples, where we've subclasses the
> checkmark class.
>
> 1) you want checkmarks to have a blue background:
> SetAPen(rp, ...);
> RectFill(rp, ...);
> DoSuperMethod(...);
>
> 2) you want checkmarks to have a glowing edge:
> DoSuperMethod(...);
> DrawGlowingEdge(rp, ...);
>
> 3) you want checkmarks to appear as in Windows:
> DrawUglySquare(rp, ...);
>
>
> Though two methods are important to get straigt.
>
> OM_NEW: here you have no object (nor instance data) *before* you call
> your superclass, so here you must call it before doing anything with
> the object, including accessing the instance data.
> OM_DISPOSE: here you have no object (nor instance data) *after* you call
> your superclass.
>
> A rule of thumb says you call your super class as the first thing in
> setup methods and as the last thing in cleanup methods.
Ookie, I think I'm getting what DoSuperMethod() does, it just executes the code of the superclass where you call it thus, call it in front of your code if you need what it does, or after when he needs what your code does... Great... Thanx
Gabriele