Is anyone interested in a DataModule Beautifier? I wrote a utility to do this a while back to handle my large/complex datmodules that were starting to look very messy due to high component counts and sloppy positioning. This utility snakes all the components on the form, taking into account the label width. It sorts by component class name and then the component label . It works directly on a (text) DFM. Other sort criteria can be added.
Is anyone interested in a DataModule Beautifier? I wrote a utility to do this a while back to handle my large/complex datmodules that were starting to look very messy due to high component counts and sloppy positioning. This utility snakes all the components on the form, taking into account the label width. It sorts by component class name and then the component label . It works directly on a (text) DFM. Other sort criteria can be added.
Screen shots below show before/after running my utility. Free + source included!
http://idk.serveftp.net/DMFormat/dmformat.rar
Note that you cannot reformat a DM that is currently loaded in the IDE. There is also a minor limitation on inherited datamodule classes. It won't directly format inherited components unless they have modified properties in the subclass. Workaround: Move any inherited components a few pixels to make them show up in the subclassed DFM.
Screen shots below show before/after running my utility. Free + source included!
http://idk.serveftp.net/DMFormat/dmformat.rar
Note that you cannot reformat a DM that is currently loaded in the IDE. There is also a minor limitation on inherited datamodule classes. It won't directly format inherited components unless they have modified properties in the subclass. Workaround: Move any inherited components a few pixels to make them show up in the subclassed DFM.
yes please!!
ReplyDeleteit would be awesome if we could first parse the dfm, then tell it how to beautify it, i.e.
there are
2 TImageList
5 TQuery
etc.
TImageList, align in Rect(width - X, Y, Width, Y + Z)
TQuery, align in Rect(0, 0, 200, 200)
It only beautifies the component location on the form, not the internal properties. Did you want to beautify the internal properties of components? My utility can handle any component type on a DM.
ReplyDeletenot the property, I was thinking of grouping together similar types, maybe option to "group by type" or "group by name"
ReplyDeleteIt already groups by class, then by component name. If you look at the "After" screen shot, you can see that similar component types are grouped together.
ReplyDeleteAlso, the RAR contains the source, so you can easily change the sort order if you like. You need the JEDI components if you want to make the DFM file name persistent and use the fancy file selector.
ReplyDeleteah, my bad, didn't notice there are two screenshots... I thought g+ failed to show me the entire image... but the arrows are too small (:
ReplyDeleteGraeme Geldenhuys Dude! You seriously need my app :-) The picture I posted was just a sample.
ReplyDeleteHere is a link to one of my larger DMs - I can only show half of it, because it scrolls off the screen vertically:
http://idk.serveftp.net/DMFormat/ejail.png
The only beautifier is hands (sometimes with head) :))
ReplyDeleteOf course, your tool have its audience, but I try to organize components in datamodule in domain-specific groups and automatic formatting results may be difficult to understand in my case (sure, I have large legacy datamodules to maintain)
I never did figure out why they made datamodules a form, instead of a list.
ReplyDeleteI remmeber that CnWizard can align all non-visible components.
ReplyDeletethanks a lot, man.
ReplyDeleteHave a need! This is much easier than playing "15 puzzle" on a 15x15 board :)
ReplyDeleteDamn... I'm really happy that we - at least in the non-legacy parts of the code - create Querie's and DataSet's and such stuff at runtime in the code...
ReplyDeleteDM's like that are IMHO a pain in tha ass... Opening the DM takes hours.. even when I just want to open the code.. And maintaining it... pretty close to impossible I would guess ;)
Sven Finke
ReplyDeleteI do both DB components and on-the-fly query creation. I think you must match the query method to what you are trying to accomplish and not just pick one or the other.
Components are good for dbgrids and other dbeditors since you can depend on them "being there" and properly initialized when a grid asks for more data or wants to update a record. They are also good for reuse in multiple parts of your app.
On-the-fly queries are better for one-of functions where they do not have to span more than one context in your app. You use the function once, destroy the queries and move on. This type of query is also good for highly complext DB operations that cannot be done in a single/simple SQL query.
Sven Finke
ReplyDeleteOpening a large/complex DM does not take hours if all your query components are placed on the form with Enabled=False.
In your app, you create a context-watcher method. As notebook tabs and sub forms take the focus or lose it, you close any previous and unneeded datasets and open (enable) only the ones necessary for the currently visible form(s).
I use this method in all of my DB apps and it is surprisingly easy to manage. Datasets for a given form rarely change, so it is low maintenance after initial design. It also decreases my app's memory footprint since only a few query components are live at any given time.
I have several hundred query components in some of my larger apps, and my DMs initialize almost instantly.
Many DB components have a design-enable property that allows you to use live datasets during design, but closed datasets at runtime. Using this feature allows you to see your DB data at design time, yet optimize your app's performance at runtime.
Kevin McCoy That's a nice approach. We currently create our datasets directly in the forms code at runtime.
ReplyDeleteBut using DM's in that way would make the development at designtime much easier...
Do the cx-Components have such a design-enable property?
Sven Finke The cx DB editor components don't to my knowledge, but the DevArt DB components I use do. I use their MyDAC components for MySQL. Their MyConnection component has a KeepDesignConnected property so that you can view actual data in the designer. DevArt sells DB components for all major database engines - all optimized for the given engine. I think they also sell generic "any" DAC components, with reduced performance.
ReplyDeleteI think the open-source ZeosLib DB components also have a design-time property too.
Note that viewing data in the IDE form designers is not fully functional using any manufacturer's DB components. If you have master-detail relationships, you only see the master data and the details will be blank.
Putting DB components on visible forms is not a good idea IMHO. This spreads your business rules all around your app and encourages duplication of code and out-of-sync business rules. With a central datamodule, you can use the synergy of the various DB components, using them in concert. You can't easily do that with disparate forms.
Kevin McCoy Hm... that's right. Maybe I get the chance to do it that way in some of my next projects. But I will have a hard time if I wan't to convince my boss to use Datasets and queries this way...
ReplyDelete