I needed to modify some code that had been amended from the Delphi TParser class (which parses DFM files, but can be amended to other sources as well), so here are some links I found during my research:
Be sure to watch the presenter Stefan Eggermont (StackOverflow, Twitter, LinkedIn, GitHub, FOSDEM, website www.legacycode.nl) as this kind of analysis (that is also possible for other languages and tools) can highly speedup your work.
Even in unsuspiciously looking code, the wit statement can bite you, especially if you need to do refactoring and (because of that) introduce two names in the same scope.
Whilst upgrading the code to remove the Containers unit (its not supported on NextGen platforms, so I have to make things work with Generics.Collections instead, (bye bye D7 support for this code) and refactor a couple stupidities in my original design (they always creep in, don’t they) I ended up with two class members of the same name. The with block then looked OK but I was in fact not access the member I thought I was.
Every once in a while you have multiple threads or processes wanting to write a short message to the same log file. Append then will give you an I/O error 32 (ERROR_SHARING_VIOLATION), but the below small routine will sleep a bit while retrying a couple of times.
in $I- mode, you access the IOResult to obtain the results of those I/O operations
IOResult gets the result of the last failed operation (if any) or zero if none failed
IOResult clears the underlying storage to zero
$IFOPT checks for a certain state of a compiler flag
You can store the state of $OPT in a temporary conditional define
Note there are a few tables of codes you can get back through IOResult as basically you can get many GetLastError results in IOResult as well: Read the rest of this entry »
From long ago, but still very valid, as I recently had another question like “what design patterns does Delphi use?”.
The Delphi usage of patterns to make the VCL and your applications work is one of the reasons I like the Delphi Component Design: Danny Thorpe so much.
Do not let you scare by the book title: a lot of information in this book is much broader than designing components.
It is about why and how things are done in the RTL and VCL, and which patterns you can use yourself.
Try and git it while you can still get it. It is excellent, but rare to get as it has been out of print for a while.
Only a minority of the Delphi developers knows that every Delphi developer uses a Factory pattern (delphi.about.com has an example in “regular” Delphi), but then implemented using virtual Create constructors.
So: time to shed some light on that :-)
Virtual constructors are to classes like virtual methods are like object instances.
The whole idea of the factory pattern is that you decouple the logic that determines what kind (in this case “class”) of thing (in this case “object instance”) to create from the actual creation.
It works like this using virtual Create constructors:
type
TDirectoryListBox = class(...)
constructor Create(AOwner: TComponent); override;
...
end;
You can store a class reference (the class analogy to an object instance reference) in a variable of type ‘class type’. For component classes, there is a predefined type TComponentClass in the Classes unit:
type
TComponentClass = class of TComponent;
When you have a variable (or parameter) of type TComponentClass, you can do polymorphic construction, which is very very similar to the factory pattern:
var
ClassToCreate: TComponentClass;
...
procedure SomeMethodInSomeUnit;
begin
ClassToCreate := TButton;
end;
...
procedure AnotherMethodInAnotherUnit;
var
CreatedComponent: TComponent;
begin
CreatedComponent := ClassToCreate.Create(Application);
...
end;
The Delphi RTL uses this for instance here:
Result := TComponentClass(FindClass(ReadStr)).Create(nil);
and here:
// create another instance of this kind of grid
SubGrid := TCustomDBGrid(TComponentClass(Self.ClassType).Create(Self));
The first use in the Delphi RTL is how the whole creation process works of forms, datamodules, frames and components that are being read from a DFM file.
The form (datamodule/frame/…) classes actually have a (published) list of components that are on the form (datamodule/frame/…). That list includes for each component the instance name and the class reference.
When reading the DFM files, the Delphi RTL then:
finds about the components instance name,
uses that name to find the underlying class reference,
then uses the class reference to dynamically create the correct object
A regular Delphi developer usually never sees that happen, but without it, the whole Delphi RAD experience would not exist.
Posts about the with statement usually cause a stir: people either like or dislike it with passion.
Starting with some history and examples, this posts lists a few DOs and DON’Ts when using the with statement, shows advantages and drawbacks, and shows you tools to eliminate with statements. Read the rest of this entry »
Summary: Always try to avoid sharing .DCU files between projects.
I see a lot of projects at clients that do not have their individual DCU directories set (therefore having the DCU files in the same directory as the PAS files causing shared units to share the DCU files), or share DCU files among different projects.
Both are a very bad idea, as the compiler does not always understand when the DCU file does not match the combination of PAS file and compiler options.
The result is the occasional use of the DCU file in stead of the PAS file causing wrong code to be used, or wrong debugger information to be included.
I don’t think that was premature optimization, just some code from an old fart that had already been programming in the era where processors had reasons to use it: