| RE: [cdt-dev] MBS option enablement requirements |
|
We’re thinking on the same wavelength… after you posted your requirements I drafted an interface already that basically looks like what you just proposed. I’ll change the naming convention to match what you propose (it was almost identical anyway).
I wasn’t thinking of having options listen for changes. I was referring to how to go about knowing when to perform the isOptionEnabled() check. I realize the obvious now with the help of some morning caffeine; I can get away with just one property change listener after all (just add the same listener object to every field editor… duh). So, no big deal, I can go ahead independently from Lars’ work.
I’ll try to have something put together on Tuesday or Wednesday latest. Monday is a holiday here in Canada. ___________________________________________
Chris Recoskie Software Designer IDE Frameworks Group Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo
Hi Chris,
I was thinking of implementing this a different way – that is, other than having Options listen for changes. My “rough” idea is that MBS would define a new callback for Options (e.g. IOptionApplicability) with 3 methods.
Regards, Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Recoskie, Chris
I think that In order to accommodate Leo’s requirements we will want to consume Lars’ work on the shared options functionality. Leo wants the option state to potentially change every time an option changes value, but this would require that every individual field editor have its own property change listener that, when the option changed in the GUI, would go and check every single option in the same option category to see if its state should change.
I think it’s much cleaner if there were just one event handler that took care of listening for all option changes via the stuff that Lars is implementing. No need to have N objects when just one will do. ___________________________________________
Chris Recoskie Software Designer IDE Frameworks Group Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo
I have a couple of comments.
Regarding Chris’ proposal, I want to be able to control “visibility”, “enabled”, and “used in command line generation” separately. Here are two examples where I do not want them all tied together:
I don’t have a strong opinion on whether methods to support this should be added to Lars’ IManagedOptionValueHandler interface, or a new callback and interface should be defined (as in Chris’ proposal). I’m currently leaning towards a separate callback and interface so that the tool integrator can deal with these capabilities separately.
Regarding implementation, it sounds like Lars doesn’t have time and I don’t think that my team has time. That leaves Chris to decide whether he has time over the next couple of weeks. If so, it would probably be easier to implement this using a separate callback.
Regards, Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
**********************************************************************
Symbian Software Ltd is a company registered in England and Wales with
registered number 4190020 and registered office at 2-6 Boundary Row, Southwark,
London, SE1 8HP, UK. This message is intended only for use by the named
addressee and may contain privileged and/or confidential information. If you
are not the named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error please notify
postmaster@xxxxxxxxxxx and delete the message and any attachments accompanying it
immediately. Neither Symbian nor any of its subsidiaries accepts liability for
any corruption, interception, amendment, tampering or viruses occurring to this
message in transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
********************************************************************** _______________________________________________ |