Delphi – In Delphi 7, can I set up ‘Debug’ and ‘Release’ modes

You could if you do it the other way around if you use the commandline compiler. Tell the compiler to compile for debug or release. Set a compiler directive to DEBUG for the debug build (it does that by default).

msbuild YourProject.dproj /p:Configuration=Release

msbuild YourProject.dproj /p:Configuration=Debug

Delphi is mostly serial in handling events. Unfortunately, it is possible to tell Delphi to handle other events while you're running in some event already. As a result, new events will run while your current event is waiting for the new event to finish. In the worst case, your application might appear to behave normally while it's really stacking events within events within events. Rule one: avoid using Application.ProcessMessages unless you really need this.

When using COM objects, things become a bit more complex since the COM object might have it's own events, start it's own threads and do all other kinds of things that you don't have any control over. COM appears to be easy to use in Delphi but it does have many hidden pitfalls for the inexperienced developers. (I still have the scars after surviving a few of them!)

In general, when working with COM objects, I try to separate the COM calls in their own threads, creating special components that will keep the COM object within it's own thread and adding a lot of synchronization code, just so I can keep the GUI responsive while some long COM task is doing some processing. But doing this requires a lot of experience with COM and multi-threading. But basically, designing your custom wrapper component around any COM component is good practice, just to protect the resources that your COM class needs.

Delphi's strongest weakness tends to be string handling and the handling of huge arrays. (Especially arrays that contain objects; use records instead.) Strings themselves are fast in Delphi, but the string functions in Delphi are not very optimized. For example, I once had a string containing some XML data. It had a lot of boolean fields that were spelled like "True" and "False" and needed to convert them to "true" and "false". A simple string-replace took about 15 seconds to replace all these values. The I rewrote it by using MSXML to load the XML in a DOM Document, using XPath to select all boolean nodes, loop through those nodes to replace all the values with the proper texts and then put the XML back into a single string. Suddenly it was able to do the same within two seconds! A huge performance gail for something that appeared to be slower. The reason? When Delphi is handling strings, it tends to copy the string a few times during processing. Or it needs to allocate more and more memory for the string to increase in size. This takes time, which doesn't get wasted in some other languages like C++.