On Fri, 6 Apr 2001, Allan Rae wrote:
> On Thu, 5 Apr 2001, John Levon wrote:
>
> > On Thu, 5 Apr 2001, Allan Rae wrote:
> >
> > > That's what the input checking routine is for.
> > >
> > > The fact that an input has changed isn't significant. The problem is
> > > whether or not that change has resulted in a valid contents of the dialog
> > > or not. If the contents are valid then Okay and Apply should be
> > > enable-able (if the state machine is in an appropriate state).
> >
> > The problem for me is that this also enables anything you added with
> > addReadOnly, if the dialog is read-write. Ideally these two things
> > should be split somehow, I'm sure you two controller bods can come up
> > with something clever that works ;)
>
> I don't understand why this is a problem. If we have a read-write
> document then all the read-only list widgets should be enabled. What
> operation are you expecting?
>
> Do you want some widgets that are only enabled when we have a read-only
> document?
no. It's not a conceptual problem.
Let me get specific. I have a button in Citation, "Add", that should be enabled
if the doc is read-write, disabled if not. However, there is *also* the rule
that it should *not* be enabled if there is no selection in the available-citations
listbox. Now adding it as addReadOnly() will enable the button, as the doc is
read-write,
but in fact I might need it disabled, so I have to turn it off again.
I think you suggested earlier that in this case, the button should not be added as
addReadOnly().
This means I have to my own readonly checking everywhere, and seems a little bit ugly;
in fact,
it makes the buttoncontroller not very useful at all ...
I hope that explains *my* problem
john
--
"I am a conscientious man, when I throw rocks at seabirds I leave no tern
unstoned."
- Ogden Nash
