On Wed, 11 Oct 2000, Angus Leeming wrote:
> Attached is a patch implementing Allan's suggestions about a FormInset base
> class. I've actually implemented three small new classes:
>
> FormBaseBI and FormBaseBD are base classes for Buffer Independent and Buffer
> Dependent dialogs respectively. FormInset is, in turn, derived from
> FormBaseBD.
[sigh] Didn't I tell you not to run off and implement this stuff for a few
days so we could have time to think about it. ;-)
It occured to me that we could make things clearer by just merging the two
enums in FormBase to:
enum BufferDependency {
BUFFER_UPDATE, // always update
BUFFER_CHECK, // same buffer then update else hide
INDEPENDENT
}
This removes the confusion I mentioned in FormPreferences, although it
still leaves the buffer check problem.
An alternative fix would be by making
Signal1<void, bool> updateBufferDependent;
Such that true == "buffer change", and false == "same buffer". This is
simple enough and we could then eliminate the keeping of a Buffer*
anywhere. We wouldn't need the updateOrHide() stuff at all. We wouldn't
need the modified BufferDependency enum above or the ChangedBufferAction
enum. The various update() members would need to change to accept a bool
but they could/should also default to false. The testing of whether to
hide or update can then be done in the update() where it belongs. (It'd
also mean we wouldn't need most of your patch -- see why I told you not to
run off and implement the FormInset stuff: some other idea came up)
What do you think of this?
I'll take a look at your patch and see what I think of that.
Frustrating aren't I?
> I've also got my head around overloading connect() and disconnect() in
> the daughter classes. Incidentally, Allan, I think that the names of
> these methods are fine. Think of them as meaning "things to be done on
> connection" rather than simply "connect signals".
Fair enough. I'll add a longer comment to that effect to FormBase.
> All this gives no new functionality, just cleans up the code base. Hope that
> its now logical.
We probably still want a FormInset anyway. Although if we adopt my
suggestion for changing the updateBufferDependent signal much of what you
have written will need to be rewritten (or just culled). I'm inclinded to
just leave the BufferDependency stuff in FormBase rather than add another
layer in the form of FormBaseB[DI].
> One new piece of functioality has been added, however. I've used some of
> Baruch's code from FormGraphics in the FormInset-derived classes. If a dialog
> is open and recieves a new "Show" or "Create" signal from another inset, then
> the dialog is updated with the new inset's data. No need to first close the
> dialog to one inset before opening it for another.
Yay!
Allan. (ARRae)
