[Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?

[Gregory M. Turner]

Wow, is that what I really sound like?  tl;dr,ldo

What I meant to say was:

"I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window.  What is the best approach to get one's Designer into both IDE's?

Thanks, and sorry for so many words.

-gmt

----- Original Message -----
> Hello Lazarusians.  I'm working on a component with a relatively fat
> design-time footprint (that is, compared to it's run-time footprint
> -- it's a smallish sub-project but I expect ~75% of the code to be
> as design-time-only).
> 
> My objective is simple, so I'd might as well just spell it out: I'm
> building a component to manage and encapsulate trivial configuration
> metadata at the module level in a platform-independent way.  The
> basic approach I'm relying on right now is to give the user a
> TFrobCollection with various metadata-attributes, kind of like
> database columns.  There will be some fairly straightforward
> slice-and-dice of the metadata, including aggregation across module
> boundaries.
> 
> I want my code to be operational and maintainable in bleeding edge
> Delphi and Lazarus environments.  I don't care too much about old
> versions.  Being able to back-port to, say, D7, without horrible
> agonies, would be vaguely preferable, but it's far from a priority.
> 
> I am pretty confident all of the run-time and business-logic aspects
> of this can be implemented without any need to step outside of the
> standard VCL/LCL mainstay design-patterns.  The only thing that
> still has me still scratching my head is the design-time stuff.
> 
> Specifically, I would ideally like to be able to code up my
> Collection property designer just once, and without utterly
> pathological usage of precompiler features.  BTW even if it worked,
> I don't think I can just do form inheritance off TCollectionEditor
> or whatever it's called -- I'm looking to do something considerably
> more sophisticated than show a list and let the Object Inspector do
> all the real work -- probably showing the user a hierarchical
> representation even though the underlying data will be flat.
> 
> What's troubling me is that Lazarus and Delphi seem to diverge more
> and more radically the deeper I push towards OTA territory.
>  However, without some fairly elaborate designers I just can't see
> my component being both cross-platform and
> application-designer-friendly (I really hate when app. designers are
> forced to click back-and-forth bazillions of times, like monkeys, to
> accomplish semantically simple tasks, as too-often seems to be the
> case with Components supporting lots of TPersistents and
> Collections, but poor, buggy, or non-existent property designers...
> I won't name any names, but I'm sure many of you have been that
> monkey at some point or another (I know I have) and didn't like it
> :S
> 
> Anyhow... can some of you with more experience with the LCL <-> ide
> state-of-the-art give me some advice on where is the right place to
> draw the line?  i.e.: Should I just ignore all of the various
> Collection property editors and so forth and do something from
> scratch which absolutely minimizes OTA dependencies or will Lazarus
> be able to accommodate some more aggressive approach?  Are there any
> particular OTA interoperation oases that work really well right now?
>  Any hard-core face-slappers that I will need to fix upstream in
> Lazarus or the LCL before doing /anything/ meaningful along these
> lines?
> 
> So far my TOwnedCollection skeleton works like a charm in both IDE's
> using the default designers, btw.  I didn't have to use a single
> kludge. But my initial efforts at design-time stuff have ended up
> looking hopelessly pathological in one IDE or the other.
> 
> Thanks for any help/advice you may have for me,
> 
> --
> 
> -gmt

-gmt