On Wed, 2 Oct 2002, Rob Lahaye wrote:
> Rob Lahaye wrote:
> > Angus Leeming wrote:
> >
> >>
> >> 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.
> >
> >
> > I prefer to use the "label = input". May I then take it from here and add
> > new code to your patch in my tree?
>
> Angus,
>
> I tried:
>
> class CheckedGlueLength : public CheckedWidget {
> public:
> CheckedGlueLength(FL_OBJECT * input,
> FL_OBJECT * label = input);
>
>
> but my compiler doesn't like this and complains that the second "input"
> is unknown. Is my compiler funny, or is this example code wrong?
Fussy compiler. I suspect the default arg would work if the
implementation was written in a .C file (ie. the default arg was
written in the .C file as well).
> To avoid the error, I do now:
>
> class CheckedGlueLength : public CheckedWidget {
> public:
> CheckedGlueLength(FL_OBJECT * input,
> FL_OBJECT * label = NULL);
NULL == C
0 == C++
> and
>
> CheckedGlueLength::CheckedGlueLength(FL_OBJECT * input,
> FL_OBJECT * label)
> : input_(input), label_(label ? label : input)
> {
> lyx::Assert(input && input->objclass == FL_INPUT);
> }
>
> Is that acceptable C++ coding?
This looks terribly yucky.
Why not just offer two or more constructors? One with one arg and
another with two? That would be simpler, neater and more obvious.
It'd also eliminate the default arg problem.
> As you can see here, I already removed the choice parameters to the
> functions and works fine. So I guess they may go.
Are you sure there isn't something that should/could be checked about
the choice parameter?
> ----------
>
> BTW: since this works great, shall I now remove all the text_warning
> stuff in the Forms. Your checkedWidgets code does automagically the
> "isValid" checks. But for the text_warnings I have to do that again in
> each FormFoobar.C to display the proper text.
> Feels like by keeping the text_warnings we are forced to do things double.
>
> The red coloring of the error-input widgets should be enough to indicate
> that input is wrong. So: text_warnings shall go?
I'm inclinded to still keep text_warnings but only use it for
complicated error conditions. Such as when two or three interrelated
fields need entries that make sense: printer page ranges and that
sort of thing probably (obviously going to depend on the dialog).
Simpler stuff could certainly just rely on pointing out which field is
broken.
Allan. (ARRae)
