Boopsi gadgets and images were designed to be backwards compatible with
the old Intuition Gadgets and Images, so as part of their instance data,
both types of objects have the old Intuition structures built into them.
When NewObject() creates a new gadget or image object, the pointer it
returns points to the object's embedded Gadget or Image corresponding
structure. Because Intuition can tell the difference between Boopsi images
and gadgets and the original images and gadgets, applications can use
Boopsi images and gadgets interchangeably with the older Intuition
entities.

Although normally considered a "programming sin", in some cases it is
legal for class dispatchers to directly manipulate some internal fields of
certain Boopsi objects.  For compatibility reasons, a Boopsi image or
gadget object contains an actual Image or Gadget structure.  These objects
are instances of the Transparent Base Classes, imageclass and gadgetclass.

To change an attribute of a Boopsi object, you normally invoke the set
method, OM_SET.  The Intuition functions SetAttrs() and SetGadgetAttrs()
invoke this method.  A Boopsi class is informed of any attribute change at
that time, allowing it to react to this change.  The reaction can include
validating the changed attribute, changing other attributes to match, or
informing other objects of the change.  That is the inherent advantage of
using function calls to change attributes.

When using conventional images and gadgets, you generally modify the
structure's fields directly.  This operation is very fast.  For
conventional images and gadgets, there is no class that needs to know
about the changes, so there is no problem.  However, this is untrue of
Boopsi images and gadgets.  Although directly modifying the Boopsi
object's internal structure would provide a performance increase over
using the Boopsi OM_SET mechanism, altering a Boopsi object's internal
structure directly will not give the class the opportunity to react to any
structure changes.  This violates the Boopsi concept, and therefore cannot
be done in general.

In order to provide a balance between the flexibility of function-access
and the performance of direct-access, the transparent base classes
imageclass and gadgetclass do not depend on being informed of changes to
certain fields in the internal Image and Gadget structures.  This means
that it is OK for the dispatchers of direct subclasses of imageclass and
gadgetclass to modify specific fields of Boopsi images or gadgets.
Applications and indirect subclass dispatchers of imageclass or
gadgetclass may not modify those fields, since their parent classes may
depend on hearing about changes to these fields, which the SetAttrs() call
(or a similar function) provides.

For dispatchers of direct subclasses of imageclass, the following are the
only fields of the Image structure that are alterable:

    LeftEdge      Width     ImageData
    TopEdge       Height    PlanePick
    PlaneOnOff

For dispatchers of direct subclasses of gadgetclass, the following are the
only fields of the Gadget structure that are alterable:

    LeftEdge    Flags           GadgetText
    TopEdge     GadgetType      SpecialInfo
    Width       GadgetRender    Activation
    Height      SelectRender

Under no circumstances may an application or an indirect subclass modify
one of these fields, even if the subclass knows the superclasses do not
depend on notification for this field.  This is the only way to preserve
the possibility for future enhancements to that superclass.  Note that
these fields are not alterable while the gadget or image object is in use
(for example, when it is attached to a window).

[Back to Amiga Developer Docs]