Re: Control::reactivate_and_undo

[Nat Friedman <nat helixcode com>]

Chuck Jazdzewski writes:
 > > Chuck Jazdzewski writes:
 > >  >
 > >  > reactivate_and_undo() is certainly only design-mode behavior
 > >
 > >     It is?  Ok, now I'm confused.  What's design-mode behavior and how
 > > is it distinct from run-mode behavior?
 > 
 > The is best explained by example. Assume the control is a simple OK button.
 > In design mode you want to be able to change its location, the caption (in
 > this case to OK), make it appear to be the default button, and then add some
 > code to do the OK behavior. All that is in design-mode. In run-mode, you
 > just want the user to invoke the code by either pressing the button or
 > hitting Enter. You would never do undo-able changes to the button.

    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.

 > >     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?

Nat