On Thu, 15 Feb 2001, Angus Leeming wrote:
> Allan,
>
> why have you made ButtonController::valid() a "Passthrough function --
> returns its input value"? It isn't used as such. Can I make it a void
> function please?
It seemed like a good idea at the time. I thought it might be used in a
way similar to readOnly() is used so made it a pass through.
> I think that I'll modify my trigger_change_ vector and associated methods to
> dont_trigger_change_ because FL_OBJECTs that trigger a callback to InputCB
> but shoudn't trigger a change in the state of the Ok,Apply buttons are much
> rarer than those that should.
Maybe they shouldn't have callbacks at all then?
The point of input is to do input checking and make changes to interface
as appropriate.
> What do you mean by "I think you're attacking the problem from the wrong
> end"? Do you mean that callbacks from these FL_OBJECTs should not be dealt
> with by input(), but by another method, say internalInput(). This would be
> exactly equivalent to my solution I think.
If a callback from something is checked by input() and input() decides
that there is invalid data when you think there isn't any there is a bug.
Right? The bug is either that input() shouldn't have been called or a
check in input() is wrong. I'm inclined to believe the second possibility
since the user has obviously done something to the interface for input()
to have been called. SO, which check in input() is saying there is
invalid data?
If you want to use input() to also monitor if the contents of the dialog
have changed and thereby decide if the Ok & Apply buttons should be
[de]activated you could do this explicitly by checking against a copy of
the contents when it was first show()n. But, this shouldn't be necessary
because the state machine should transition to a modified state and stay
there until the user Cancels. Any invalid input transitions to
MODIFIED_INVALID or something like that name. So the only problem, as I
see it, is why is it transitioning to MI when it should still be in M?
Some test in input says that the input is invalid. Or perhaps more
likely, a test is trying to do the work of the button controller and
enforce some policy change. This is a major no-no. input() should only
test input validity and nothing else. The button policy defines all
policy decisions. Mixing the two does not work and violates all the
assumptions.
In simple terms, for the case you are trying to fix, clicking on an
existing reference _is_ a valid input. Although I'd be inclinded to say
it isn't an input at all but a selection.
Allan. (ARRae)
