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.
There are many implementations of this in other languages, for instance Ruby’s ‘times()’ function in C# | Of Code and Me (which the WordPress.com editor fucked up as it replaced Action<int> with Action which is a totally different thing, so the gist with code is below.
public static class IntExtensions
{
public static void Times(this int i, Action func)
{
for(int j = 0; j < i; j++)
{
func(j);
}
}
}
Since the WordPress.com editor fucks up TProc<Integer> into TProc and TProc behaves differently from TProc<Integer>, I’ve included a gist link with the actual code below.
program RubyManiaConsoleProject;
uses
System.SysUtils;
type
TRubyMania = record helper for ShortInt
procedure times(const IterBody: TProc);
end;
procedure TRubyMania.times(const IterBody: TProc);
var
i: Integer;
begin
for i := 0 to Self-1 do
IterBody(i);
end;
begin
5.times(
procedure(i: Integer)
begin
Write(i, ' ');
end
);
end.
It also shows why I hardly use anonymous methods in Delphi: they’re way too verbose.
Stefan Glienke worded it perfectly: Default(typeIdentifier) is a “magic” function that is implemented into the compiler and causes it to generate the correct code – like for records with managed fields it generates a call to FinalizeRecord and some instructions to zero the remaining fields.
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.
I think the reason forward declaration of classes and interfaces is possible because they both are reference types, so referring does not impose copying.
Anyway, the trick is this:
You can’t have forward declarations for record types. Define both Implicit operators in the second type
The reason is that when using Delphi, the TOpenDialog and TSaveDialog will use the classic Open and Save Dialogs on Windows < Vista and fall-forward to the new Common Item Dialogs handled by TFileOpenDialog and TFileSaveDialog (both will not fall backward).
When you have your COM initialisation done wrong, your application appears to hang. Amidst the plethora of threads started by the COM subsystem, these two dead-lock:
The Wiert Corner - irregular stream of stuff 