On Mon, 16 Oct 2000, Juergen Vigna wrote:
> On 14-Oct-2000 Allan Rae wrote:
> >
> > If use is made of the button controller and an appropriate ReadOnly policy
> > then all the dangerous bits can be disabled. The Goto/GoBack button can
> > still work and the user gets to see a full list of references within a
> > document. So you'd get (or should get) similar functionality to that
> > provided by the Refs menu entry.
>
> At least I've seen that we've problems with the ReadOnly stuff in the
> ButtonControler. Have a look at the FormParagraph where stuff in the
> Extra-Folder should enabled/disabled depending on some radio-buttons,
> while all should be disabled when readonly. Now if I disable the stuff
> (because it shouldn't be selectable) the the ButtonControler activates
> all of the stuff again because the document is not readonly.
These would be the bits I added to the readonly handling on Friday because
they still enabled?
> So I have to handle objects which should dynamically dis/enable themself
> by hand (also in the readonly sense!). Would you think we can solve this
> problem a bit more elegant (then I did it in FormParagraph!)?
This sounds like a job for RadioButtonGroup. (perhaps, perhaps not)
This could involve extending RBG to [de]activate arbitrary objects when
certain radio buttons are active. Not that difficult an extension.
Actually, the problem could be that you shouldn't disable the fields when
the document is readonly at all unless you really really need to. The
readonly policies are such that you can edit a dialog's contents to your
hearts content but as long as the document is readonly you'll never be
able press OK or Apply. If however you toggle-readonly the dialog will be
in an appropriate state with respect to input validity.
So the question is:
Do you _really_ need to disable the various fields when the dialog is
readonly or will disable OK and Apply suffice?
Remember that when switching to a readonly buffer, toggling readonly on or
opening a readonly file the user gets a message dialog saying "Document is
readonly -- you won't be able to change anything" or something to that
effect. So the user has already been warned that they can't expect to do
much to the document.
The only cases I can think of that need to have objects disabled are where
a particular objects callback can cause some change to the document (such
as the documentclass combo in FormDocument�) but that can sometimes be
blocked in the callback by checking the readonly status either of the
buffer directly or of the bc_. In the documentclass case it needs to be
disabled.
Allan.
� Ideally nothing should affect the document until the user presses OK or
Apply so the handling of documentclass combo is wrong when it asks if it
should set some defaults for that class -- it should only ask that once
the user has pressed OK or Apply.
