On Mon, 21 Aug 2000, Juergen Vigna wrote:

> 
> On 19-Aug-2000 Baruch Even wrote:
> > On Sat, 19 Aug 2000, Baruch Even wrote:
> > 
> >> Whoever did the new FormDocument, I BLAME YOU!
> > 
> > Sorry for this harsh language, I'm too tired to think anymore. I apologize
> 
> You shouldn't be sorry it was friday, wasn't it ;)
> 
> Anyway I've seen Allan fixed this already and also changed the
> ButtonPolicy for FormDocument.
> 
> BTW.: Allan now the "Restore"-button is always disabled, do I have to
>       enable it by hand?

Uhhhh... let me guess... you added a restore button to FormDocument?
Okay, then we have a problem.  I didn't realise you had done this.

In which case we need to do one of three things:
1. Allow more than one object to be matched to a given "Button" in
   ButtonController.  For example,
        list<FL_OBJECT *> apply_;
   instead of
        FL_OBJECT * apply_;

2. Create a new policy for RestoreReadOnly.

3. Add "UndoAll" to the output of the appropriate states in all the
   policies.

#1 is easy to change but would mean that Restore wouldn't be active while
the doc was readonly (all the readonly policies allow editting of the
dialog contents but keep OK and Apply deactivated).  I also can't see that
it would be much use for any dialogs.

#2 means adding a new policy that is effectively a merger of
NoRepeatedApplyReadOnlyPolicy and PreferencesPolicy.

#3 is probably the best option otherwise we end up creating a million and
one different policies that are otherwise almost identical.  Hmmm... yes
that makes better sense.  That just means any state that has the dialog in
a modified condition should have "| UndoAll" appended to its state output.
I'll take a look.  But I really need to get LDN done first.

Allan. (ARRae)

Reply via email to