On Mon, 27 Nov 2000, Angus Leeming wrote:
> > > In the case of an OkApplyCancelReadOnly Policy, I'd have four buttons on
> > > the
> >
> > ^^^^^^^^^^^^^^^^^^^^^
> >
> > > popup:
> > > "Restore" "Ok" "Apply" "Cancel"
> > > Conventional connections of each to the ButtonController.
> > >
> > > Make some change in the popup and "Restore" "Ok" "Apply" are activated.
> > > Press "Restore" or "Apply" and the relevant action is activated BUT the
> > > buttons do not then become Inactive. They should. (This is only partly
> > > true. See below:)
> > >
> > > Press "Apply".
> > > "Restore" goes inactive, but "Ok" and "Apply" remain active.
> >
> > If you don't want a repeated apply you should use NoRepeatedApplyReadOnly.
> > This operation is correct for the policy you are using. Note however that
> > for this policy (and other repeated apply policies) you have to make a
> > change first before you can do repeated applies -- perhaps that is
> > incorrect.
>
> So, using the policy OkApplyCancelReadOnly Policy you're telling me that:
> 1. I open the dialog
> Ok, Apply are inactive
> 2. I make some change
> Ok, Apply go active
> 3. I "Apply" the change
> Ok, Apply remain active.
>
> WHY? Surely, things are now back to 1. What's the point of the buttons
> remaining active?????
Not all dialogs work on insets. Some like the Character dialog can be
applied anywhere anytime without an update to the dialog. Others might
insert some change (search/replace for example) and thus be repeatable.
I have implemented every type of policy I thought might be useful. There
are uses for each of them amongst the existing dialogs.
Remember I also said that perhaps I have step one wrong and the Ok+Apply
buttons should be active initially.
> ANyway, to fix it to what I'd like, I need to change to
> NoRepeatedApplyReadOnly. No other changes?
That's right.
Allan. (ARRae)
