0

I have a Datamodule in my project that containing a large number of TTable and TQuery, I am seeking for way to organize them like as TComponentCollector in old versions of delphi.

Is there any way to grouping non visual components like TTable and TQuery in a component collector in delphi 2007.

Badr Ajjour
  • 15
  • 5
  • Not really an answer but once you stop using non visual components at design time and instantiate them at runtime, you will find that you don't need datamodules and a componentcollector, because you can design your classes in a way that they contain the related data components it needs... – whosrdaddy Nov 16 '14 at 09:32
  • Instantiate components at run time produce complex management of code, and made it difficult to append or insert items to your project. – Badr Ajjour Nov 16 '14 at 09:44
  • 1
    Why do you think it causes complex code? Use factories to build the table and query instances and the code can look like `FArticleTable := FTableFactory.Build( 'article' );` or `FArticleInsert := FQueryFactory.Build( 'INSERT INTO article (id,title) VALUES(:id,:title)' );`. – Sir Rufo Nov 16 '14 at 10:17
  • 2
    The Thirdparty component can still be found if you want to stay with it. – bummi Nov 16 '14 at 10:32
  • @Sir Rufo, or e.g. a *collection* like `FTables: array[TQueryType] of TDatasetDescendant;` where `TQueryType` is an enumeration like `dtArticleTable, dtArticleInsert`. That way saves you from listing all the component names when doing something common to them. – TLama Nov 16 '14 at 10:54
  • Instantiating components at runtime is usually the way to go. Putting everything into a big global data module is usually poor design. Why do you want to use objects with global scope? – David Heffernan Nov 16 '14 at 11:23
  • @Sir Rufo, what about linking component to other controls, we don't want to lose the designer abilities. – Badr Ajjour Nov 16 '14 at 11:37
  • If you want to stay at the `Drag'Drop Programming` then there is the option bummi offered in his comment – Sir Rufo Nov 16 '14 at 11:53
  • 3
    @DavidHeffernan, even datamodules can be instantiated at runtime and in multiple instances, that can then be local properties of any class. Wiring evrything at runtime may be a valid approach, as is using the wiring capabilities of the object inspector. The point with the global instances is more related to the global variables introduced by default and the instantiating in the DPR file. Designing forms and datamodules inside the IDE is just a valid approach as is doing everything at runtime. – Uwe Raabe Nov 16 '14 at 12:28
  • @Uwe Yes, wiring in the designer can be convenient I agree. I'm just assuming the asker is using globals. – David Heffernan Nov 16 '14 at 12:50
  • I am using globals because these globals used in the most of my forms. we didn't discus the differences between designer and run time, We search for a way to collect non visual components in form or datamodule to let work easier. Thank you for all of you. – Badr Ajjour Nov 17 '14 at 06:07
  • @Badr Use of global state generally results in poor design. That's my point. As a rule you should shun the use of globals. However, if you do wish to collect a bunch of components in a data module, what is stopping you? – David Heffernan Nov 18 '14 at 07:22
  • @DavidHeffernan, Just I need to manage my components at design time. – Badr Ajjour Nov 18 '14 at 10:28
  • It seems to me that the reason that you feel the need for help in managing your components at design time is that you have a data module containing every single component in your entire program. No wonder you feel lost. However, I would not solve your problem the way you are attempting to. I'd refactor the program towards a better design. – David Heffernan Nov 18 '14 at 10:29
  • Incorrect, when you work with an enterprise applications, you forced to generalizing objects that you using it in the most of your forms. Otherwise you will repeat the same work at each form. – Badr Ajjour Nov 18 '14 at 10:36

0 Answers0