Joe White’s Blog

Binary DFMs are a pain, because you can’t see what changed between two versions. Right?

That’s what we thought. We’ve been avoiding binary DFMs since time immemorial, especially back in the Dark Ages when we used VSS, which won’t even keep revision history for binary files. Even now that we’re on Subversion — which has no problem with binary files, thank you — we still avoid binary DFMs. Among other things, it’s hard to write a Ruby script to grep through a directory of binary DFMs. And, of course, they’re hard to diff. Or so I thought.

So imagine my surprise yesterday when I was writing a Ruby script to grep through our code and DFMs, and it dumped out some gibberish and beeped a couple of times. I looked, and sure enough, we had a binary DFM. It wasn’t even some fringe GUI that we had written once and never modified — we had, in fact, made several changes to the DFM in the past year.

This really puzzled me. Did this file get accidentally changed to binary format recently? But we should’ve noticed when we checked in. We shouldn’t ever check in without looking at the diffs first. And of course you can’t diff a binary DFM, right?

But I looked at the file history. That file had been in our repository for years, binary all the way. It had been modified several times. Surely people had tried to look at the diffs. So what happened?

I will, at this point, call your attention to two things:

1. We’ve been happy users of the superb Beyond Compare diff tool for almost three years, and have made it our default diff viewer for TortoiseSVN.
2. 

   Beyond Compare is written in Delphi.

Yep. Of course Beyond Compare, as a Delphi app, has some Delphi-isms built in. It’s so cool that it can diff binary DFMs, and make them look just like text in the diff viewer. Internally, I’m sure they call Classes.ObjectBinaryToText (handy thing about writing a tool in Delphi that works with Delphi code, you get the library functions for free), so as far as you can tell when you’re looking at diffs, the file looks like it’s been a text DFM all along.

My only gripe is that it does this utterly silently. There’s no indication that this is a binary DFM that it converted to text for your convenience. And since binary DFMs are inconvenient in other ways (e.g., Trac can’t show diffs on them), I’d rather not have any binary DFMs in our code base at all. So in some ways, I’d almost rather not have this feature — I’d notice the binary DFMs a lot sooner if they looked like garbage in the diff window.

Then again, when I re-saved the DFM as text, it was sure nice to have those diffs to show that nothing important had changed. Binary DFM on the left, text DFM on the right, and the handful of changes highlighted just as nice as you please.

I’m often curious about whether an app I’m using was written in Delphi. Here’s an easy way to tell, that works most of the time.

(Note: this won’t work for apps that use Delphi 2007’s new Vista-compatibility MainFormOnTaskbar property.)

All you do is right-click the taskbar button. Non-Delphi apps will have an ordinary window menu:

Delphi apps have an abbreviated menu instead, because it’s actually the context menu for the invisible TApplication window, instead of the context menu for the form:

This isn’t true just of Delphi for Win32 — it also works for VCL.NET applications. (It’s VCL-specific, though, so you can’t identify a Delphi/.NET WinForms app this way.)

If a Delphi app does use Delphi 2007’s MainFormOnTaskbar, then it will have the normal window menu, so a normal menu doesn’t necessarily mean it wasn’t written in Delphi. But if you right-click the taskbar button and do see only Restore, Minimize, and Close, it’s a pretty sure thing that it’s a Delphi app.

Version 0.5 of DUnitLite is now available. This is a minor enhancement release.

Download it here: DUnitLite 0.5

What’s new in 0.5

• Should.ReferTo now works with interfaces, and can mix and match between objects and interfaces. It also correctly works around the interface reference-equality problem.
• Added Given as an alias for Specify. So if you want to document your assumptions at the beginning of your test, you can use Given.That(...) to improve readability.
• Added Should.[Not.]Be.False and Should.[Not.]Be.True.
• Added Should.[Not.]Be.Null and Should.[Not.]Be.Assigned. Both work with either objects or interfaces.
• Added Should.[Not.]Be.GreaterThanOrEqualTo and Should.[Not.]Be.LessThanOrEqualTo, as aliases for AtLeast and AtMost.

In Delphi for Win32, you can’t necessarily use the “equals” operator to tell whether two interfaces both point to the same object. The following code:

var
  Foo: IFoo;
  Bar: IBar;
begin
  Foo := MyObj as IFoo;
  Bar := MyObj as IBar;
  Assert(Foo = Bar);

will fail — even though both Foo and Bar point to the same object.

Let’s look at why that happens, and what you can do if you want a comparison that would succeed.

Memory layout of an interface reference

Note: If you don’t care about the technical details, and just want to know how to work around the problem, skip ahead to the “Workaround” section.

Let’s dig into the memory layout of an interface reference:

var
  Foo: IFoo;
begin
  Foo := TFoo.Create;

An interface is a pointer to a pointer to an interface VMT. This means there’s a slot in the object’s instance data, just like any other instance field (except that it’s not visible in code), that automatically holds a VMT pointer. This field is automatically initialized during object construction. This is exactly the same way VMTs for Delphi classes are handled, except that the class’s VMT pointer is always at offset 0 within the block of memory allocated for the instance. Interface VMT pointers have to be at a nonzero offset, since offset 0 is already spoken for; they’re added at the end just like fields. (This will be familiar to those who remember Turbo Pascal objects, whose VMTs didn’t have to be at offset zero.)

And there’s the reason for the problem. Every interface you define gets a VMT all its own (even if it has the exact same methods as its parent interface, it still has its own VMT), so there has to be a slot in the instance data for the IFoo interface VMT, and another slot for the IBar interface VMT.

When you cast the object instance to IFoo, you’re really taking a pointer to the invisible “IFoo VMT pointer” field inside the object. When you cast to IBar, you’re taking a pointer to the “IBar VMT pointer” field. Those two are at different memory locations, so a reference-equality check will fail.

Bonus trivia: Because the interface pointer (which is also what’s passed as the implicit Self pointer when you call a method on the interface) isn’t at the same address as the object, the compiler has to generate a method stub that does a Self-pointer fixup, then call the actual method. The interface VMT points to this thunk method, not to the actual method body. You always wanted to know that, didn’t you?

A failed workaround: changing the variable types

So if the problem is the variables being of different types, let’s just make them both the same type:

var
  Foo: IInterface;
  Bar: IInterface;
begin
  Foo := MyObj as IFoo;
  Bar := MyObj as IBar;
  Assert(Foo = Bar);

The Assert will still fail, even though both variables are of type IInterface! Why?

That’s because the Foo variable still points to the IFoo VMT pointer inside the instance. IFoo descends from IInterface (as all interfaces do), so an IFoo reference is assignment-compatible with an IInterface variable, and is stored as-is in that variable — still pointing to the IFoo VMT pointer.

So even though a reference may be stored in a variable of type IInterface, it does not necessarily point to the IInterface VMT pointer for that class. This becomes a particular problem when you add different interfaces to an IInterfaceList: they’re stored in a list of IInterface variables, but they’re not canonicalized to point to the IInterface VMT pointer. So, for example, TInterfaceList.IndexOf can give you the wrong answer, if you’re not careful about the types of your interface references.

The workaround

The fix is really simple: just as-cast both variables to IInterface. This normalizes them, and puts them on an even footing for comparison.

When you as-cast to an interface type, you get back a pointer to the interface VMT pointer for that exact interface — none of that weirdness with assignment-compatibility and putting an IFoo reference into an IInterface variable: when you cast to IInterface, by golly, you get an IInterface all the way. QueryInterface and SysUtils.Supports will also canonicalize to the interface you specify.

(You could even use something other than IInterface, as long as you know both instances will support it. But every interfaced object can be cast to IInterface, so using IInterface makes for a nice general solution.)

So to revisit the code at the top of the article, the correct way to compare the interfaces would be something like this:

var
  Foo: IFoo;
  Bar: IBar;
begin
  Foo := MyObj as IFoo;
  Bar := MyObj as IBar;
  Assert(Foo as IInterface = Bar as IInterface);

Now, the assertion will pass.

Tyler version 0.01 is now available for download. Currently there’s just a source distribution, but it includes compiled EXEs.

The feature set is pretty sparse at the moment, but what’s there, works. It’s the bare minimum that I decided would be worth releasing. Here’s a brief rundown:

• Pluggable display libraries. You can select from “compatibility mode” (basic GDI via TCanvas), Asphyre eXtreme, and (un)DelphiX (but see note 1 below). Windowed mode only — no fullscreen support in this version.
• Graphics. These are primitive — everything is a solid-color square. Walls are light gray, floors are dark gray, the hero is yellow, the wandering NPC is white, and that’s all you get. (Well, except for black.)
• Movement. You can use the cursor keys to move the hero around the map. There’s nothing yet to make you stop when you run into a wall or the NPC, though.
• Map editing. TylerEdit.exe lets you edit the map and save your changes. It’s primitive, but it works. (But see note 2 below.)

Currently you can only have one map. Later you’ll be able to have lots of them — a world map, a map for each town, a map for each dungeon level.

Some stuff is hard-coded in this version, like the initial position of the hero, and the position and movement of the NPC. This will be improved in the next few versions.

Note 1: The license agreement for (un)DelphiX does not allow me to redistribute its source code. So, the source distribution is (un)DelphiX-less. But it still compiles: if you download and compile the source distribution, (un)DelphiX support will be automatically disabled. To enable (un)DelphiX, see the notes in the vendor\undelphix directory.

Note 2: The map file format will change in future versions. Any maps you create in this version probably will not work in v0.02 and later.

What’s next

The next few releases will be working toward a major milestone: a finished game. Not a long game — it’ll probably take less than a minute to play from start to finish. And not a very exciting one. In fact, it’ll be pretty stupid. But it’ll be playable, and everything will be editable in the game editor. Stay tuned for more news of… Stupid Quest.

In Delphi, Ctrl+Tab moves forward to the next editor tab. In Visual Studio, Ctrl+Tab is more like Alt+Tab, moving to the tab you were most recently using.

It looks like Delphi actually supports something similar to the Visual Studio behavior — just with a different keystroke. If you press Ctrl+B, Delphi pops up the list of files currently open in the editor, sorted by “most recently focused first” — and when the dialog opens, the second item in the list is selected.

In the screenshot, my current editor tab is SpriteSpecs.pas. Before that, I was working in Screens.pas, and before that, I had done a Project > View Source to edit Tyler.dpr. That’s not the order the tabs are listed above the editor — Ctrl+B shows them in the order I used them last, just like the Alt+Tab window list or Visual Studio’s Ctrl+Tab list. And notice that, when the dialog opens, the second item is selected by default.

So the equivalent of Visual Studio’s Ctrl+Tab would be Ctrl+B, Enter. The equivalent of holding Ctrl down and pressing Tab twice in Visual Studio would be Ctrl+B, Down arrow, Enter. Not bad. Not bad at all.

The only downside is, Ctrl+B only works when the focus is on the editor window. If the focus is in a docked window, MS Visual Studio is nice enough to let you Ctrl+Tab back to the editor. Delphi isn’t so thoughtful; there doesn’t appear to be any reliable way to use the keyboard to get the focus from a docked window back to the editor. (If the current editor tab is a form or frame, you can hit F12 once or twice. Otherwise, reach for that mouse.)

DUnit has an option to use JCL to generate stack traces. The idea is that, whenever there’s an exception or a test failure, DUnit will show a stack trace right along with the failure message. The only problem is, it doesn’t work.

There’s no problem getting stack traces for unexpected exceptions. This is really useful; you get the address, unit name, method name, and even the line number of the line that threw an exception, together with the call stack that led to that code getting called. Immensely useful.

The problem is, you don’t get the same thing for test failures — even though Fail and CheckEquals, and even DUnitLite’s Specify.That, operate by throwing exceptions (they’ve got their own exception class, ETestFailure). You should be able to get a stack trace that shows the exact line of code that contained the failing assertion. In fact, we’re using older versions of DUnit and JCL at work, and we get stack traces just fine.

Unfortunately, stack traces for test failures are broken by default in the latest versions of DUnit and JCL. But there’s hope — notice that I said “by default”. Below, I’ll tell you how to fix that default.

Enabling DUnit stack tracing

First of all, here’s how to get DUnit to show stack traces in the first place.

You’ll need to download the source code for both DUnit and the Jedi Code Library. (Recent versions of Delphi ship with an older version of DUnit, but I only tested this with the latest version.)

Add the DUnit, JCL, JCL\Common, and JCL\Windows directories to your project’s search path.

Then make the following changes in Project > Options:

1. On the Directories/Conditionals page, set “Conditional defines” to: USE_JEDI_JCL
2. On the Linker page, set “Map file” to “Detailed”.

Now write a test that throws an unexpected exception, compile, and run. Here’s a contrived example, but it’ll give you an idea of what it looks like:

Enabing stack tracing for test failures

We don’t get unexpected exceptions in our tests very often. More often, it’s test failures. And when we have more than one assertion in the same test (not the ideal, but it happens a lot), sometimes it’s hard to know which assertion failed. Or rather, it’s always easy to know, if you have stack traces.

The problem is with JCL’s exclusion list. The latest version of JCL keeps a configurable list of exception types that it shouldn’t generate stack traces for. Seems like a reasonable feature. But the JCL and DUnit teams made three important design decisions, at various points in time:

1. JCL’s exclusion list, by default, contains one class: EAbort.
2. JCL ignores not just the classes in the exclusion list, but any of their descendant classes as well.
3. DUnit’s ETestFailure descends from… yep, you guessed it, EAbort.

Put all three together, and stuff doesn’t work.

But, all that said, it’s easy to work around. Just add the following code to your project file, before you call one of the RunRegisteredTests routines:

uses
  ...,
  JclDebug,
  ...;

begin
  ...
  JclDebug.RemoveIgnoredException(EAbort);
  ...
end.

And bask in the goodness that is stack traces.

Today’s Delphi-macro power tip: moving the cursor to the end of the current word.

This isn’t an everyday need, but it comes up from time to time, and there’s not an immediately obvious way to do it. But it’s easy if you know the trick.

The big problem here is that Ctrl+Right arrow won’t work, because it moves to the beginning of the next word, not the end of this word. Sometimes you know what you expect the line to look like, and know you can just hit Left arrow twice and be where you want; but then again, sometimes you’d really rather just go to end-of-word and be done with it.

Here’s the trick: Ctrl+K, T, Right arrow, Left arrow.

Ctrl+K T selects the word under the cursor — it’s just like double-clicking. And the cursor is left at the end of the selection. So the cursor is left at the end of the word, right where you want it; all you need to do is clear the selection, which is easily accomplished by hitting Right and then Left.

This isn’t really either a macro recipe or a power tip, but it’s a useful trick.

Sometimes I’ll run into a situation where I want two different things on the clipboard at once. Maybe I’m passing a filename through several layers of methods, and at each layer, I’m typing

; AFileName: string

twice (once in the class declaration, once in the method implementation), and

, AFileName

once (where the value needs to be passed along to the next guy). Wouldn’t it be nice if I had two clipboards, each with its own “paste” keystroke?

Once you think to use a macro as the second “clipboard”, it’s trivial. Select ; AFileName: string and copy it to the clipboard; then start recording a macro, type , AFileName, and stop recording.

Voila — two clipboards. Paste one with Ctrl+V, and the other with Ctrl+Shift+P.

Several people clued me in on a couple of ways to save macros for later. I haven’t had a chance to try either one yet (so someone correct me if I say something wrong about either), but they both sound great — and both are open-source.

(I’m really curious how they do it… I should look at their code sometime.)

GExperts Macro Library

GExperts includes a dockable Macro Library window. It lets you have multiple macros, lets you assign names and descriptions to them, and automatically saves them when you close the IDE.

I’m not sure where it saves them, though. This would be terrific if we could save them in revision control somehow — otherwise, with eight development machines, the macro I want would inevitably be on one of the other computers.

Keyboard macro manager on CodeCentral

TOndrej wrote a keyboard macro manager that you can compile into a design-time package and register in the IDE.

This one definitely can save the macros to a file, so could probably be used to share macros between computers.