Okay. I’m going to just implement it in ISelectionManager. On the odd chance that I do break someone’s implementation, it should be a relatively easy job to add some blank functions to honor the interface promise (assuming they don’t need the table support).
On May 27, 2014, at 6:22 PM, Alex Harui <aha...@adobe.com> wrote: > If someone has their own implementation of an interface, adding an API to > an interface can break them. The verifier will see that not all methods > are implemented. > > It is a trade-off. You can create an ISelectionManager2 or > ITableSelectionManager to be completely safe, but the odds you will break > someone is probably very low. > > -Alex > > On 5/27/14 3:47 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >> Adding to an API shouldn't be a problem, as long as the new >> methods/properties don't change anything about the existing >> implementation... >> >> EdB >> >> >> >> >> On Tue, May 27, 2014 at 12:42 PM, Harbs <harbs.li...@gmail.com> wrote: >> >>> I¹m working on cell selection of TLF tables. >>> >>> Cell selections does not fit into the normal index based selection >>> concept >>> of text. To support cell selection, I need coordinate-based selection >>> (to >>> support rectangular selections within a table). >>> >>> Basically, I want to add some table-specific functions to >>> ISelectionManager and SelectionManager. My question is whether this >>> might >>> cause problems for users who might have implemented ISelectionManager >>> and >>> whether I should be concerned about that and/or what there is to do >>> about >>> it. >>> >>> Thoughts? >>> Harbs >> >> >> >> >> -- >> Ix Multimedia Software >> >> Jan Luykenstraat 27 >> 3521 VB Utrecht >> >> T. 06-51952295 >> I. www.ixsoftware.nl >
