On Fri, 16 Feb 2001, Angus Leeming wrote:
> On Friday 16 February 2001 00:32, Allan Rae wrote:
[...]
> For example, in the citation dialog, clicking on an entry in either browser
> activates the appropriate (up, down, transfer, delete) buttons and displays
You could extend buttoncontroller to do this -- using a generalised
version of the RadioButtonGroup stuff I have in cold storage. Note that I
said "could" not "should" or "had better".
> the contents of the key in the info browser. It does NOTHING to the contents
> of the data ultimately returned by the dialog when the Ok,Apply buttons are
> pressed.
>
> So, somehow, the event must be processed, but it should NOT change the state
> of the Ok,Apply buttons. There are two ways to achieve this.
>
> 1. have a new selection() method to process such events.
> 2. tell the ButtonController not to process these events BECAUSE they are
> internal selection()s not input()s
>
> I opted for option 2. I don't think that this invalidates the assumptions of
> the ButtonController. On the contrary, you are merely giving the
> ButtonController more information with which to make it's decision about what
> is valid/invalid input and what is an internal selection. You are giving the
> controller MORE control, not less.
The button controller is supposed to be exactly that: the controller.
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)
