Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
Gregory M. Turner g...@malth.us hat am 19. Oktober 2011 um 08:10 geschrieben: 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. Thanks for summing up. You need two design time packages, the Delphi dpk and the Lazarus lpk. Each one needs one unit for the IDE dependent part, for example registering a menu item and registering an event when the selected designer components changes. These two units access the shared unit, which implements your fancy designer window. You can safely put the Delphi and Lazarus package into one directory. The shared unit uses only the LCL/VCL, which are quite compatible, so you probably don't need any compiler directives at all. Mattias -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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
- Original Message - Gregory M. Turner g...@malth.us hat am 19. Oktober 2011 um 08:10 geschrieben: 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. Thanks for summing up. No problem -- sometimes I need to write the Great American Novel before I can figure out what I'm trying to say. There are worse character flaws, but I sometimes wish I more often had the good sense not to press Send :S You need two design time packages, the Delphi dpk and the Lazarus lpk. Each one needs one unit for the IDE dependent part, for example registering a menu item and registering an event when the selected designer components changes. These two units access the shared unit, which implements your fancy designer window. You can safely put the Delphi and Lazarus package into one directory. The shared unit uses only the LCL/VCL, which are quite compatible, so you probably don't need any compiler directives at all. That sounds perfectly reasonable. I think I was afraid the Oracle would put a hex on me if I did this, but after trying it the other way, I think she's much more likely to condone this tiny sacrifice. In fact, by encouraging me to limit the OTA's inevitably wicked and corrupting influence on my design(-er), your suggestion will probably result in a better outcome than if I had simply hacked up an IDE-specific implementation. Thanks, -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
