Re: Control::reactivate_and_undo

["Chuck Jazdzewski" <cjazdzewski inprise com>]

> On Wed, Feb 16, 2000 at 08:53:41AM -0800, Chuck Jazdzewski wrote:
> > >  > 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.
>
> OK, seems like you're looking at undo solely from a gui builder
> point of view. I would think undo would be useful for more than just
> a gui builder, and thus would benefit from an interface of its own.
> That way, the builder components, an embedded document, and other
> things could use the same interface.

Exactly. This is why I suggested it be moved and why I agree that it should
be moved to its own interface.

> I don't think controls want an undo functionality outside of the
> gui builder, so including the functionality in the control interface
> seems weird to me.

We agree again. I am using a different vernacular apparently. Your "in the
gui-builder" is what I refer to as design-mode, and "outside the gui
builder" is my run-mode.

> > 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. [...]
>
> Could you please explain why?

I thought I did, but, obviously, not well enough. With such an interface
some tool could, at compile time, verify that all the method that are
required to be a control are implemented. Also, containers that require
interfaces not in the ancestor list of the spec interface would be
considered in error. Think of it as enforceable documentation.

Such an interface would make it very clear what is required of, and what can
be expected of, a control or an embedding. Also, such interfaces would allow
you to define multiple levels of requirements as implied by the names I
used.

Chuck.