Re: Control::reactivate_and_undo

["Chuck Jazdzewski" <cjazdzewski inprise com>]

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

>  > It is not clear, however, that to support undo you
>  > must be an embedding so that argues for a separate undo interface that
>  > Embeddable might inherit from.)
>
>     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,
one for an embedding, etc. This is where I differ slightly from Miguel's
philosophy against multiple inheritence. I believe that if you require a
control or embedding to implement a set of interfaces, that set should be
the set of base classes to one interface. This becomes clear, implement, say
EmbeddingLevelOne, and you conform to level one embedding. Or, implement
ControlLevelOne then you implement the level one requirements for control,
level 1, behavior. Since multiple inheritence should not be required, I
would require the containers to never assume that such interfaces are
implemented, just the set of the the base interfaces are.

Chuck.