On Tuesday 01 October 2002 4:26 pm, Rob Lahaye wrote:
> Angus Leeming wrote:
> > Incidentally, you remember your request about removing the
> > text_warning area and instead setting the widget label to
> > red if the input is invalid?
> >
> > Well attached is a proper patch that does just this for
> > LyXGlueLengths and which I have implemented for the Space
> > Above field in the paragraph dialog.
> >
> > Perhaps you might like to try it out and incorporate it in
> > your mega patch if it does as you desire.
>
> Sure, YES! I'll happily add this to my patch here and extend
> its use into the other forms as well. I have two
> comments/questions.
>
> With your setup, a call in, f.ex. FormParagraph.C, is as follows:
> > +
> > + bc().addCheckedWidget(
> > + new CheckedGlueLength(dialog_->input_space_above,
> > + dialog_->choice_value_space_above,
> > + dialog_->choice_space_above));
>
> This is very specific for the Paragraph case, which has a
> choice, input and a unit-choice. However, generally a length +
> unit has not the last choice entry. For example see Width &
> Height input in the graphics dialog.
Which bit of this do you find confusing:
class CheckedGlueLength : public CheckedWidget {
public:
/** The label widget's label will be turned red if input and choice
do not make a valid LyXGlueLength.
label may be one of input or choice or may be something else.
It should not be 0!
*/
CheckedGlueLength(FL_OBJECT * input,
FL_OBJECT * choice,
FL_OBJECT * label);
?
But, sure, this is a sample piece of code. You may find this preferable:
CheckedGlueLength(FL_OBJECT * input,
FL_OBJECT * choice,
FL_OBJECT * label=input);
Ie, the default value for the third arg is the same as the first, so you can
get away with writing just two.
Or, indeed, this
CheckedGlueLength(FL_OBJECT * input,
FL_OBJECT * choice,
FL_OBJECT * label=0);
although that means you'd have to alter checked_widgets.C a little too.
> Another thing: if every call to "bc().addCheckedWidget()"
> requires a "new CheckedGlueLength()" call, I'd rather move the
> creation of the new class object into addCheckedWidget(), so
> we will only need to type:
>
> bc().addCheckedWidget(dialog_->input_space_above,
> dialog_->choice_value_space_above);
>
> Or would that violate a fundamental C++ rule?
>
> How about rename "addCheckedWidget()" into
> "addCheckGlueLength()"?
No, the ButtonController knows nothing about the widgets themselves.
It doesn't even know about the existence of a GUI.
However, you could easily add a helper function to checked_widgets.h:
class ButtonControllerBase;
void addCheckedGlueLength(ButtonControllerBase & bc,
FL_OBJECT * input,
FL_OBJECT * choice,
FL_OBJECT * label = input);
and in checked_widgets.C
#include "controllers/ButtonControllerBase.h"
void addCheckedGlueLength(ButtonControllerBase & bc,
FL_OBJECT * input,
FL_OBJECT * choice,
FL_OBJECT * label)
{
bc.addCheckedWidget(new CheckedGlueLength(input, choice, label);
}
used as
addCheckedGlueLength(bc(), dialog_->input, dialog_->choice);
> Regards,
> Rob.
> -----------------
> PS: how do you create a diff file from CVS with new files
> showing up in the diff file as:
>
> Index: src/frontends/xforms/checkedwidgets.h
> ==============================================================
>===== RCS file: src/frontends/xforms/checkedwidgets.h
> diff -N src/frontends/xforms/checkedwidgets.h
> --- /dev/null 1 Jan 1970 00:00:00 -0000
>
> When I do "cvs diff -Nu > cvs.diff", the file has in the top
> lines: ? src/frontends/xforms/checkedwidgets.C
> ? src/frontends/xforms/checkedwidgets.h
>
> Without the contents of the new files in the diff.
I have read access to cvs.lyx.org and so can
cvs add checkedwidgets.h
cvs diff > difffile
Ask Lars for an account and read access too.
Hope all this helps,
Angus
