On Tuesday 13 February 2001 18:26, John Levon wrote:
> No, I mean it ! Now after working some on the xforms frontend I really do
understand
> what a good idea your heirarchy reworking was. It made things pretty much a
doddle.
I hope to get some time soon to do a bit more with lyx. I'd managed to
separate the Controller and the View quite cleanly for a sample Citation
dialog but then have been very busy with other things. The nice thing about
that though is that we'll only need to implement most of this heirarchy stuff
once, for all the frontends, not once for each. That'll REALLY make things a
doddle.
> Currently FormInclude is deriving from FormCommand ilke other dialogs. This
works fine
> when accessing stuff stored as CommandParams, with getContents(),
getOptions(), etc.
>
> However, FormInclude has settings that are not represented in the
CommandParams, so there
> needs to be some way of communicating [in]directly with the inset itself. I
really don't
> know how to go about this (or rather, the best way).
If this is so, then it shouldn't be stored as a CommandParams, but as a new
IncludeParams.
Why not derive IncludeParams from CommandParams and give it all these extra
methods:
bool isVerb() const;
bool isVerbVisibleSpace() const;
bool isInclude() const;
void setInput();
void setNoLoad(bool);
void setInclude();
void setVerb();
void setVisibleSpace(bool);
bool loadIfNeeded() const;
etc etc etc
That way, you can pass it to the FormInclude as a (CommandParams *) and
dynamic_cast<> up to IncludeParams to get access to all these methods. (OK,
OK. static_cast for the time being.)
This way, the functionality is available to both the Inset and to the Form.
The Inset reverts to being nothing more than a button with a label that
launches a dialog when pressed (as all the other Button insets seem to have
become). And the amount of new code you need to write will be minimal.
Angus
