Where should I put my utility methods? How can I used my customized form? (Delphi)

I've been using Delphi for a little over a month, but I still do not k开发者_运维问答now the proper way of doing things.

If I have methods which I can use on a lot of projects should I put them on a Unit, Form or DataModule? I have not used a unit (in itself), New-> Unit. Should I put my utility methods there? If so, is there an example I can look at, a tutorial or whatever. I've used DataModules in the past, though it gives me the impression that it should only be used when I'm dealing with databases and such.

Another thing, I'm customizing some forms (for instance a form with some TEdits that do specific things). To use this, first I add this to the uses in the .dpr

CustomizedForm in '\CForm\CustomizedForm.pas' ;

then I add CustomizedForm to the uses in my mainform (where I'll be using it).

Is this the correct way to do it? I'm was just guessing, it seems to work though I'm not particularly confident that it's the proper way.

I put all mine in a unit called utils.pas. It works for me.

If you have different segmentations of utilities that some programs use but not others, you may want to create separate units for them.

Look at: Anatomy of a Delphi Unit

It is part of the excellent Beginner's Guide to Delphi Programming by Zarko Gajic that is very worthwhile to go through.

For the best "visual" introduction, see Nick Hodges' Thirty Camtasia Demos in Thirty Days. It is for Turbo Delphi which no longer is offered, but is still very similar to full Delphi and lets you visually get a feel for how to do things in Delphi.

Where you put things depends on what they do. The unit associated with a form should really only contain code that's directly related to the user interface that the form presents. Putting business logic directly into a form unit is considered bad practice for a number of reasons. If your utility methods aren't part of a specific form, it's best to put them in a Unit.

As for Data Modules, they're containers for holding non-visual controls. As the name implies, they were created for database access, but they can hold all sorts of other things. For example, at work we have a handful of data modules that contain TImageList controls, which hold lists of icons that are used in various places throughout the app. If you have any non-visual controls that you need to share with several different forms, a Data Module is the logical place to put them.

And yeah, it looks like you're doing the customized form right. If you have a second form that the first form needs access to, (to make it show up when you hit a button or menu item, for example,) then the first form's unit will need the second form's unit in its uses clause. (There are ways around this involving class registration techniques, but that's an advanced topic.)

You might want to avoid using the global form variable that Delphi likes to set up in a form unit, though. It makes your program start up more slowly, and using globals is another thing that's considered a bad practice. A form is an object like any other Delphi object, and you can create it with its constructor, call Show or ShowModal to make it appear, and then call Release or Free on it (read up on TForm.Release in the helpfile to know when you need to use it) when you're done with it.

For starters, create a few different units based on categories - StringUtils.pas, MathUtils.pas, DateTimeUtils.pas, etc - put your functions into those units according to category and be sure to include all the prototypes in your interface section so they'll be visible to other units (but don't get too caught up in how to categorize things...) and keep all your util units in a separate, dedicated directory.

Then, point your Delphi or Project library paths to that directory and you'll be able to use the functions in all your utility units.

Eventually, you may want to make the units into classes with class functions or persistent structures etc.

I myself generally create a project group that includes a package called MyProjectUtils.bpl and I put all my utility units and classes into that package. I never actually deploy it as a package, but since they are wrapped up together I can always check that they all compile properly and they are all available immediately for browsing in the IDE, etc.