Forwarded to the list as suggested by Allan Rae:
You sure give me a lot to think about ... ;)
I'll probably spend the rest of the morning trying to
digest all that you've said.
Anyway, some comments to your comments on my code, rather
than to your comments on the "Best way forward"
On Thu, 09 Mar 2000, you wrote:
> > The close similarity between FormCredits.[Ch] and FormCopyright.[Ch]
> > (see attachments), suggests that I should proceed by creating a base
> > class with virtual build() and two derived classes FormCredits, and
> > FormCopyright implementing the build() function. Is this a Good Idea?
> > (I ask because C++ is new to me and I'm learing as I go ;-).)
>
> Okay, I did have time after all. I thought they were patches attached not
> just the final files. I think I now see what you mean about similarity
> between FormCopyright and FormCredits. The code for show(), hide() and a
> couple of others does tend to look almost identical apart from the name of
> the form_xxx generated by fdesign. There are only a couple of times where
> things are different or where a couple of extra Connections are needed
> (insets in particular use 3 Connections). The major differences between
> any two dialogs are apply() and build().
>
> Last year (or was it the year before that?) I tried to figure out a way to
> do that with templates and macros but it got overly complicated and I gave
> it up as a bad joke. It could still be worth another look but it may make
> the code look overly complicated and scare off people who haven't had much
> exposure to templates before (or big macros).
>
> Note that we can't really achieve much in the way of shared code because
> while the code is structurally similar the callbacks and signals are all
> different in each dialog. That's why templates and macros (which can do
> substitutions for each of those different data types and member names
> respectively) are more appropriate than trying to inherit some common
> behaviour. Although, I'm willing to learn if someone can do it that way.
I think that all the Signal0 pop-ups are functionally
identical and that they are crying out to become derived
classes. As an exercise, I've continued my stuff with these
two classes (FormCopyright and FormCredits). I also have a
third class FormVersions which is also nearly identical.
I've managed to write all three as derived classes from
FormBase by defining the constructor as:
FormBase::FormBase(LyXFunc * c, Dialogs * d, Signal0<void> & signal )
: dialog_(0), lf_(c), d_(d), h_(0)
{
// let the dialog be shown
// This is a permanent connection so we won't bother
// storing a copy because we won't be disconnecting.
signal.connect(slot(this, &FormBase::show));
}
Then Dialogs.C could call them all as:
Dialogs::Dialogs(LyXFunc * lf)
{
dialogs_.push_back(new FormCopyright(lf, this, this->showCopyright));
dialogs_.push_back(new FormCredits(lf, this, this->showCredits));
dialogs_.push_back(new FormVersion(lf, this, this->showVersion));
// reduce the number of connections needed in
// dialogs by a simple connection here.
hideAll.connect(hideBufferDependent.slot());
}
FormBase contains all the code of your FormCopyright except
the build(), which is now a virtual member function and is
specific to each derived class. I've attached a file
containing my xforms directory so that you can see exactly
what I mean. After this, I'll pause for a while so that you
can finish your script in peace. Please keep me
informed/give me your opinions!
Keep up the good work,
Angus
> P.S. Angus are you on the list? If so I'll stop sending an extra copy to
> you.
Yes, I am.
A
FINALLY --- and perhaps most importantly for me --- A
QUESTION
I haven't done anything in the xforms/forms directory, yet
all three pop-ups work. Why is the forms directory needed?
A.
--
DR ANGUS LEEMING <[EMAIL PROTECTED]>
Department of Biological and Medical Systems
Imperial College
LONDON SW7 2BX
Tel. 0171 594 5186
Fax. 0171 584 6897
xforms.tar.bz2
