Re: Control::reactivate_and_undo

["Chuck Jazdzewski" <cjazdzewski inprise com>]

>     This is what I thought.  So how is reactivate_and_undo design-mode
> behavior?  Think of a text editor control.  It certainly seems like
> run-mode behavior to me, though you make the decision about whether or
> not to implement the undo methods at design time.

Certainly undo of a text editor is useful at run-time but I don't see anyone
calling reactivate_and_undo at run-time. They would call the undo() method
of the control directly through its programable interface. The control
interface is the interface between the container and the control not the
programmer and the control. I don't expect the container to call
reactivate_and_undo() at run-time, only design-time, so it should not be in
Control. In other words, Control should only contain methods that the
container requires at run-time. Methods that the designer needs should be
relagated to another interface. This way, the control's design behavior
could be supplied by a separate .so that is only loaded when the design
interface is requested.

As an aside, the implementation of reactivate_and_undo() would probably be
more complicated than just calling invoking the text-editor undo() since it
would only have to undo user operations where the reactivate_and_undo()
would need to undo any operation accessable at design-time.  For example, it
would need to undo the background color changes that might not be able to be
changeable through the UI of the text-editor, but is available at design
time. This means that the reactivate_and_undo() would contain code that you
would not want to deploy in a run-time version.

>  > >     What about a separate interface altogether, which you QI for but
>  > > which the embedding does not derive from?
>  >
>  > This seems reasonable, but I feel that there needs to be at least one
>  > interface that encompases the essense of what is required to be a
>  > control
>
>     I agree.  I'm also strongly reconsidering my decision to make
> property bags be a separate (non-aggregated) object which you get off
> a control with control->get_property_bag.  If we glom them into one
> object, then each control which also supports a PB has 4 interfaces:
>
>     . Bonobo::Unknown
>     . Bonobo::Control
>     . Bonobo::PropertyBag
>     . Bonobo::PersistStream (which you use to persist/depersist
>                              properties).
>
> Does this seem reasonable?

Yes. Very reasonable. I still think that PersistStream is not the right way
to persist the contents of a control, however. I feel that writing the
contents of the PropertyBag should be the only way to persist a control. A
control could, itself, degenerate into a single property that contains a
PersistStream of data. It would then have a property editor that would edit
this stream of data (e.g. by as simple an editor as a file open dialog). To
require a control provide its entire state in a PropertyBag and, yet again,
in a PersistStream, seems odd.

For embeddings, this is different. PersistStream makes much more sense for
an embedding. I would not expect an embedding to represent its entire state
in the PropertyBag, only selected properties.

Chuck.