Decide upon use of stored procedures and other advanced database utilities. Test the Delphi implementation.
Test BDE and/or ODBC functionality for the database selected. National characters, sort order, delimiters, data type differences, treatment of 'blob' fileds, transaction control from the Delphi side, limitations in SQL implementation, etc. All products on the markets differ on closer scrutiny. Work-around the parameter subsitution devices of Delphi if needed.
Plan and design classes for caching and manipulating data in the application form units while displaying and in internal memory. The objective may either be true object orientation separation or equally important: utilities making coding more compact, revisable and self-checking.
You might need general classes for insert, change and delete of data.
Timestamp and similar devices can be integrated.
Classes and components could for instance be: Date controls, comboboxes with picklists, buttons receiving messages, grids, component groups with standardized appearance or any control with important visual design, variables or data access contained.
Assembling or modifying standard Delphi components:
2) Implement the events aimed at, preferably by using the override option and leaving standard event triggers unblocked.
3) Add properties and sometimes events to get the new components functional or to make embedded components visible. Public declarations for variables/objects might be used as shortcut sometimes. Keep in touch with the VCL code. You may not understand all of it, but you can usually figure out the details that you need ( for instance the methods that you want to modify with the override directive).
4) Having planned properties and methods, including reservations for the future, add the internal logic and processing.
5) Improve the component as new requirements appear in the programming
work.
Have a plan for common variables, windows messaging methods and flags or triggers for deferred actions within the application.
Use purchased components or freeware if they add substantial value.
Do not use them if you with reasonable effort can make own solutions. Foreign
programming, even if very smart, may bring you into troubles. Even bundled
products like QuickReport may turn out as quite a bit less reliable than
the standard Delphi toolbox.. Own mistakes are easier to live with than
those of others. The worst thing that you can get into is a general instability
in your environment caused by some unknown lack of strictness.
Generally: Load and free forms when needed. If possible, create and free objects like a TQuery within the block. The more extended the lifetime of your objects, the bigger the risk to get problems because of hidden interrupts in the execution flow, etc.
Use the ComponentState property to read pending destroy status if you create and free objects systematically.
Do not mingle to much with the Windows internal flow of action - trying
to prevent some actions from running more than once seldom succeeds. The
same applies to the basic idea in Windows that the user triggers
the action: Attempts to move the cursor around and driving the form windows
programmatically too much will cause problems like uncontrolled loops.