Allan,
I've implemented your "tri-state output for input()" method exactly as you've
described it below. (This implementation is in my local tree only).
In order for it to work, (and it works perfectly) I have to modify
ButtonController::input() to:
void ButtonControllerBase::input(ButtonPolicy::SMInput in)
{
bp().input(in);
+ if (ButtonPolicy::SMI_NOOP == in) return;
refresh();
}
(excuse the change of class name here.)
I have to do this because refresh() is set up as:
void xformsBC::refresh()
{
if (okay_) {
if (bp().buttonStatus(ButtonPolicy::OKAY)) {
fl_activate_object(okay_);
fl_set_object_lcol(okay_, FL_BLACK);
} else {
fl_deactivate_object(okay_);
fl_set_object_lcol(okay_, FL_INACTIVE);
}
...
}
(Again, this is the xforms implementation of the refresh() method).
My modification seems like the cleanest solution (well, actually, move it up
to line of ButtonController::input(), not line 2).
Is it acceptable?
Angus
On Saturday 17 February 2001 05:15, Allan Rae wrote:
> Remember the MVC discussions. Either way we have two choices as I see it:
> 1. use input() only for input processing. This is the same as
> your introduce a selection() option.
> 2. tri-state output for input():
> -- SMI_VALID
> -- SMI_INVALID
> -- SMI_NOOP -- don't change whatever state we're in
>
> Then input() should change to:
> SMInput const input(...);
>
> so it returns something appropriate above.
>
> Then FormBase::InputCB should use:
> pre->bc.input(pre->input(...));
>
> We can still leave valid() and invalid() in the interface but they
> probably won't be used unless called directly within some dialog-specific
> callback.
>
> This generalization of the input() methods outputs could be useful for
> feeding back multiple state machine inputs triggered by some change in the
> dialog. That'd require some mods to either ButtonController or the
> ButtonPolicys and I'm not sure we'd really need that capability anyway.
>
> Anyway, IMO this is cleaner than building lists of stuff the controller
> should ignore. Especially if someone decides something should be ignored
> only sometimes.
>
> Yes, it will mean extending all the state machine definitions slightly --
> add a line that says:
> if (SMI_NOOP == in) return;
>
> to the top of nextState() in ButtonPolicies.C.
>
> Too easy?
>
> Allan. (ARRae)
