A long time ago, Lars Fosdal wrote this on the Delphi G+ group:
It really is beyond me why there is no Project.rc file which includes
Project.version.rc
Project.icon.rc
Project.themes.rc
Project.manifest.xml
and so forth.
That way, the .res file would be a compile-time thing (or even a thing of the past) – and the resource linker would assemble the various bits from their individual sources.
It has been an issue forever. Vincent Parrett correctly commented that if you clean out too much out of the Project.res file, the IDE gets confused:
The only thing it is used for is version info and the mainicon (the IDE gets confused if don’t do that).
Like many of the G+ commenters, I’ve switched to script based resources for my own projects a long time ago. That’s also the reason why I forgot: this approach just works for any Delphi version.
This post is a reminder to self to see if the IDE has finally refrained from doing Project.res handling itself.
An elaborate wrapper around the Define column is jedi.inc which is used in many projects (both open source and closed source) to distinguish between various Delphi versions, libraries and platforms at compile time (URL: github.com/project-jedi/jedi/blob/master/jedi.inc)
The Project Options in the Delphi IDE has a few option (like the Search Path) each with an ellipsis button (the one on the right having only three dots ... in the image below) to pop-up a dialog.
Delphi Component/Tool vendors have to support a truckload of Delphi and C++ Builder versions which can be a pain: they have to work around problems in Delphi and C++ Builder versions that have long been abandoned by Borland/CodeGear/Embarcadero/Idera/…
This means that sometimes the Delphi Component/Tool vendors have to work around stuff in a way normal applications vendors would never do.
Recently I learned that sometimes this can be a painful thing: keeping DFM files in binary state.
I’m not kidding about either the DFM file format nor about supporting old versions:
That’s why TeeChart still has most DFM files stored as binary files (again the ‘most’ word).
For version control and searching this is a pain, so normal application developers (the ones not using Delphi XE5 Update 1 for Android work) should run convert.exe with the -t (target=text) switch on DFM binary files.
A while ago, StackOverflow user Kobus Smit did some brilliant editorial work that – due to current state of StackOverflow – sort of fired backwards: his question got marked as duplicate before he could post his excellent answer. After that answer was posted, the oh-so pride SO-demi gods never took any energy to revisit to see which answers were best.
His simple question:
How can my Delphi app easily write to the Windows Event Log?What is the difference between TEventLogger and ReportEvent? How do I use the ReportEvent function?
Which somehow should be encompassed by this Delphi 5 question (apparently that 15+ year old Delphi version is still considered current by the SO demi-gods).
The answer summarises and extends existing answers spread out over StackOverflow and adds an EventLog git repository wrapping the ReportEventandRegisterEventSource (which somehow is always a pain: Delphi services for instance often forget that).
Lesson learned when doing editorial work:
prepare both the answer and question in markdown off-line
ensure you mention in the question that the answer is meant as collection of “best of” answers found elsewhere
post the question and answer in rapid succession
cross your fingers for the StackOverflow demi-gods being in a good mood
Recently I bumped into a thing that I’d long forgotten: the Delphi compiler treats searching for include files (any files used with the {$I} or {$include} directive differently:
The compiler first searches the directory where the file that is including resides and then uses the project and IDE search paths.
The IDE only uses the project and IDE search paths.
This means that when you press Ctrl-Enter on the filename to be included you might edit a different file than the compiler will include.
So when a product has multiple include files with the same name in different sub-directories, then you must modify them all.
I’m not sure this is a bug or feature, so Embarcadero is free to put this in either their QA system or documentation system.
Because the IDE uses this on-line content, potentially any code could be executed inside the IDE (apart from that page being loaded over http, so any man-in-the-middle could abuse this, but I digress). This imposes a security risk as many developers run the IDE from accounts having more rights than the average user.
The Wiert Corner - irregular stream of stuff 
