Delphi has this handy feature to insert a GUID into source code by pressing CTRL+ALT+G. Visual Studio doesn’t have any comparable feature. I found the following two articles useful instructions on how to create comparable ability in Visual Studio. With the stroke of a single key combination, a new GUID appears in the source code.
The article Quickly Generating GUIDs in Visual Studio 2008 has the full step-by-step rundown. It has a link to Generating GUIDs in the Visual Studio IDE, which contains additional useful information on customizing the format.
I’ve been tracking down some memory leaks in a program written in the Delphi language (formerly known as Borland’s Object Pascal). I’ve run across this a few times over the years.
Interfaced objects in Delphi have the wonderful benefit of automatic lifetime management due to automatic reference counting. It’s almost as convenient as the automatic object disposal Java, C#, and Objective C (on Mac OS X Leopard).
There’s a potential memory leak, however if you descend from TInterfacedObject and override the AfterConstruction method. You must call inherited else the object will never be released!
Note that the constructor increments the reference count otherwise it will go to zero during construction under certain circumstances. That, of course, would cause the object to free itself immediately… and you the programmer would go an a man hunt to avenge the accelerated hair loss.
Because the constructor increases the reference count to prevent premature destruction, the reference count must also be decreased to its correct value after the constructor has finished executing. This happens in the AfterConstruction method. Look at the implementation in System.pas:
procedure TInterfacedObject.AfterConstruction; begin // Release the constructor's implicit refcount InterlockedDecrement(FRefCount); end;
Say you descend from TInterfacedObject, and do something in AfterConstruction. The following example is simplistic, but makes the case:
type IFoo = interface end; TFoo = class(TInterfacedObject, IFoo) private Bar :Integer; public procedure AfterConstruction; override; end; . . . TFoo.AfterConstruction; begin Bar := 1; end;
Note that TFoo.AfterConstruction does not call inherited. Because inherited is not called, TInterfacedObject.AfterConstruction is not called, and the implicit reference count done in the constructor will never be undone.
Thus, the following code will never release the instance of TFoo:
var lFoo :IFoo; begin lFoo := TFoo.Create; end;
To fix this memory leak, call inherited in the descendant’s AfterConstruction definition, thus:
TFoo.AfterConstruction; begin inherited; // <---- CALL inherited HERE! Bar := 1; end;
In the Delphi IDE, when working on a project, you open a package (.dpk), then close the package. However, when you open the project at a later date the package “sticks” to the project. In other words, the package is listed in the Project Manager window. Sometimes the package becomes the default active project, so when you compile your project, the package is compiled rather than your project. This forces you to go to the Project Manager window and activate your project before you can compile. It’s annoying.
The cause of this is that when you close a project, the IDE remembers which windows you had open, breakpoints, and other IDE state information for that project. It does this by storing the layout in the desktop (.dsk) file. For some reason, even when you completely close the package file, the Delphi IDE remembers the package in the same way that it remembers the files you have open in the IDE. This does make sense on one hand. Packages are more than a source file, but less than a full-fledged project. However, packages have side effects that normal source files don’t. This is why the package seems to be “sticky”, showing up every time you reopen the project, and possibly interfering with your work on the project.
To get rid of the pesky “sticky” package there are two options. For both of these, do not have the project open in the Delphi IDE. If you do, you’ll end up overwriting your fix when you close the project and the IDE rewrites the desktop file.
If you don’t care about which windows you had open, breakpoints, etc. you can just delete the whole .dsk file. Bam!
On the other hand, if you want to preserve the IDE state without the “sticky” package, deleting the entire desktop file is too draconian. You’ll have to edit it. This is pretty simple. The desktop file is in Windows INI format. Open it up in your favorite text editor. (As an old Un*x head, I like vim.) Search for the name of the package’s file name, and delete the offending INI sections. Save the desktop. When you reopen the project, the IDE will not see any references to the package. Thus the pesky package will not show up anymore.