On Tue, 3 Apr 2001, Angus Leeming wrote:
> > Angus, I know you were going to reimplement the input checking functions
> > of the dialogs to return an SMInput but this doesn't seem to have been
> > done yet.
>
> Errrr. Yes it has. Look at FormBase::InputCB rather than
> FormBaseDeprecated::inputCB. There's a reason for it being Deprecated...
Hmm... Well I had just 'grep valid *.[hC] | less' in xforms/ and saw a
bunch of calls to bc().valid() and thought that you must not have done it
yet. It turns out it was another problem you were working around
instead.
> Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
> citation-inset from the minibuffer. The params are perfectly valid, the
> dialog pops up. Do you want to "Apply" them? Yes I do!
Doesn't the citation inset already exist at that stage with those values?
You're more familiar with this process than I am since you reworked a lot
of it.
I think this is the problem we've discussed before about the
OkApplyCancel[ReadOnly]Policy. I think it would probably make sense to:
- outputs_[INITIAL] = CLOSE;
+ outputs_[INITIAL] = OKAY | APPLY | CLOSE;
This should be a safe change for both these policies. It'd also mean that
after a Restore you can still press Okay or Apply without changing
something in the dialog.
Provided we do an input check on the contents of the dialog just as it is
being shown then we can move to the appropriate state (INVALID or
RO_INVALID) if the contents aren't initially valid. I suspect we assume
that the contents are always valid on initial showing.
> > John, don't change the valid() function name or add another one. Wait
> > for Angus or I to change the operation of the dialogs input checking.
> > Then you won't need those direct calls to bc().valid() just to workaround
> > a mishandled input routine.
>
> I'd enjoy having you around again...
I'd enjoy being back. I'll have to get familiar with the code again
though. So much has changed. You blokes, and you in particular Angus,
have been doing a terrific job.
Allan. (ARRae)
