Version-independent TListAndLabel Class or Abstrakt Baseclass of TListAndLabel26

[ThomasI-42]

I am considering to make a proposal for a version-independent TListAndLabel Class .
Or, at least, an Abstract Baseclass of TListAndLabel to minimize customizations in project code.
How do you think about it? It's a piece of work and if you don't have an interest in it I'd rather leave it.

Uses of cmbtLL26x and cmbtLS26x in the project need to be adjusted with each new List&Label version.
Especially the declaration of types in cmbtLL26x hardly changes.
In my projects I have to declare uses of cmbtLL26x, because of the type declarations. A version-independet cmbtLLx with the types who barely change is desirable.

For the TListAndLabel26 Class I see two possible solutions:

1. abstract base class, to reduce adjustments in my project code
2. a property "DLL-version" with corresponding switches in the code
   What do you think?

[ThomasI-42]

I thought of a third possibility: an interface of IListAndLabel
This would probably reduce the effort and achieve the desired independence.
I will implement a variant with this approach

[jbartlau]

@ThomasI-42 The cmbt**x.pas files are auto generated. While I agree that the types rarely change, there are often new constants (e.g. LL_OPTION_...) with new versions. We usually patch projects to the new version with a search and replace, which works out nicely.

Regarding the base class for LL: an interface was my first idea as well here. The definition could go into the l26CommonInterfaces.pas. Ideally, this should work both for the new databound component and the old BDE component. If I understand your need correctly, you'd like to just reference the component via the interface? Thus, instead of having something like

var ListLabel: TListLabel26;

You'd have

var ListLabel: IListLabel;

Would this really be an advantage that's worth the effort? Note that some of the parameters might be version specific again if they consist of types defined in the declaration files (e.g. GetVarSizeInfo method in TLl26XObject, not sure about others). When referencing the component, you'd use something like ListLabel.Design() anyway, which would be the same in both cases. Maybe I just haven't gotten my head around the issue this would solve 🙂.

[ThomasI-42]

I have my own framework witch wrap around TListAndLabel25 / 26. I use my framwork in different projects with different ListAndLabel versions. My Framework uses Spring4D and the spring container instantiates the appropriate class. But the classes for ListAndLabel25 and ListAndLabel26 are mostly copied code. I'm trying to reduce the dependencies and the copied code. Because I use only a subset of the TListAndLabel26 methodes, I suppose with an interface of the public methods (design(), print..), the copied code could be reduced.

[jbartlau]

I see. I'm not familiar with Spring4D but know a number of dependency injection frameworks for .NET, sounds like it is no different. If you'd like to work on this - feel free, as this is "just" an additional interface we could merge the changes anyway without breaking any existing code.