This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [SetupXP] The two styles for handling activation refusal

Robert Collins wrote:
> On Sat, 2003-07-19 at 23:40, Max Bowsher wrote:
>> Gary's current SetupXP patchset calls 2 member functions on page
>> OnActivate (returns void), and OnAcceptActivation (returns bool). I think
>> this is unnecessarily messy. AFAICS, OnAcceptActivation only exists to
>> prevent the need to change the return type of the existing OnActivate
>> function.
>> I would very much prefer changing OnActivate to return bool, combining
>> purpose of both functions. Yes, this does require changes in all derived
>> classes, but the changes are trivial, and the end result is a cleaner,
>> logical API.
> If its what I think you are talking about, I disagree.
> OnAcceptActivation was, IIRC, prompted to allow pages to accept or
> refuse activation. Refusing == don't display. Accept = display.
> OnActivation, is called on each activation, which only occurs
> post-accept checking.
> OnAcceptActivation can have default behaviour for the common case,
> reducing duplicate code over a conflated function that both activates
> and indicates whether it's willing to be activated.
> Naming wise though, I'd call OnAcceptActivation canBeActivated or some
> other query-indicating function.
> Again, all the above is based on recollection..

Right. One detail though, at the moment, OnAcceptActivation is called
*after* OnActivate.
That *is* redundant. Unless there will ever be a need to ask a page whether
it would take activation in the future, but not activate it immediately,
even if it is possible to do so, I think the 2 calls should be merged. Will
there ever be such a case?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]