During conversion of our application suite to Delphi 2005, I ran into a very irritating bug where a form was flashing extremely quickly during application startup. It was so fast that I couldn't get a feel for which screen it was that was flashing. Debugging the application also didn't reveal what form it was. So, what to do? I thought of using Camtasia to record the screen during startup, and then play back the recorded session at a very slow rate so that I could find out what I needed to know. I had to be sure to crank up the frames per second capture rate as high as it would go, but after a smooth install and some tweaking of options in Camtasia, the plan worked beautifully. I found out what form it was that was flashing, and then fixed it.

The gory details were that this form only got included from a DLL that had its conditional compilation directives wrong (for this build). However, this flash didn't occur in the Delphi 6 days. So I thought back to my previous experiences with PopupMode, and set PopupMode to pmAuto for this form and everything is great again.

Some days, I long for the Ctrl-S / Ctrl-Q days again.

I had a need to get AutoUpdate functionality into one of my applications, so that meant a perusal of Google to find out what others were using. After checking out several options, I deceided that AutoUpgrader fit the bill nicely. There were plenty of options and events to help control the AutoUpdate process. There was also a trial version that supported Delphi 2005, so that made it easier to try it out to see how it works. It requires a text file on a server somewhere, defining the newest version available. If a new version exists on the server, the component downloads the new version (all the while, providing status information about the download), and restarts the application to use the newer one.

The only downside was that the component has a VersionNumber property that is used to compare versions. I would prefer that the component would be smart enough to retrieve the version information from the file and use that, but this is easily remedied by placing this line of code in the DataModule.OnCreate where the AutoUpgrader resides:

  // GetVersionInfo is a locally defined function to retrieve version info from the current Application
  AutoUpgrader1.VersionNumber := GetVersionInfo;

I recently had the need to release an application using an installer. The install had fairly simple needs, so I gave the free Nullsoft Scriptable Install System for a spin. It's certainly a little different to set things up compared to other installers, but it works flawlessly. My installer has a Modern UI, installs files, writes registry entries, has separate component install options, has a custom page that writes to an INI file depending on install options, and creates an uninstaller. The script syntax wasn't exactly intuitive, but the examples and documentation were more than adequate to get me up and running with minimal troubles. It also looks like I will be able to grow into this installer since it has some more advanced features (callbacks, plugins, etc.) should I need them. I was able to get the installer working in FinalBuilder 2, but I see that it is natively supported in FinalBuilder 3, too.

Give it a try, and I'm betting you'll like it, too.

I'm using Indy 9 here with Delphi 2005, and recently installed the Delphi 2005 Update 3 patch. During the patch process, several files that I deleted came back, along with several registry entries. Afterwards, I was getting an error when trying to load a DataModule that had some Indy components on them telling me that Indy90 could not be loaded because it uses IdWinsock2, which was already loaded by dclIndyCore. I imagine this happened during the install of the update by copying registry entries from HKLM to HKCU.

To work around this, delete the following registry entries:

HKCU\Software\Borland\BDS\3.0\Known Assemblies\c:\program files\borland\bds\3.0\bin\dclIndyCore.bpl
HKCU\Software\Borland\BDS\3.0\Known Assemblies\c:\program files\borland\bds\3.0\bin\dclIndyProtocols.bpl

I recently read What's Playing? Interfacing Your Media with an External LCD Panel using Visual Studio 2005 Express by Scott Hanselman, and the article that inspired it, Coding in the Blue Glow by Duncan Mackenzie. The WOW factor was very high. I need to come up with a good excuse to go get one of these and play with it!

If you use the ChildRDM architecture available in Delphi 6 in %DELPHI%\Demos\Midas\SharedConn, there is a possibility of the server hanging in memory after all clients have exited. This really only applies if you are using a COM object in another DLL and using that COM object as a ChildRDM in your main server EXE.

Debugging the problem, I found that there were still references to the external DLL, and that the CPU view was showing me that the EXE was repeatedly trying to enter a critical section, but not being able to do so. If you look at the destruction code for TDataModule, you'll see that it tries to lock access to the DataModule. Well, if you rely on Delphi to get rid of internally stored interface references when they go out of scope, it will be too late to reclaim the external DLL. The solution is as follows:

Create an overridden BeforeDestruction method in the main RDM. In that RDM, set all of your ChildRDM interface references to nil in order to explicitly release the COM objects. Then, make a call to CoFreeUnusedLibraries (found in ActiveX.pas). This will release the DLL, if the COM subsystem says it's OK to do so. However, I found that even that was enough in all cases, so add another call to CoFreeUnusedLibraries in the main RDM's finalization section. See the code snippet here:

procedure TMainRDM.BeforeDestruction;
begin
  fSharedDataRdm := nil;
  fChildRdm := nil;
  CoFreeUnusedLibraries;
  inherited;
end;

initialization
  TComponentFactory.Create(ComServer, TMainRDM,
    Class_MainRDM, ciMultiInstance, tmApartment);
finalization
  CoFreeUnusedLibraries;
end.

After doing this, I was not able to get the app server to hang in memory again.

Thanks go out to Steve Trefethen for providing this unit. We just got done updating httpsrvr.dll to use the unit, and performance has just sky-rocketed. After running stress testing on some MIDAS servers on a dual-CPU machine with hyper-threading, it is absolutely incredible how fast and stable things are. We didn't measure at the API level, but our perception and wall-clock timing tells us there is at least a 300% increase in speed, if not more.

Thanks again, for a job well done!

Quality Insight is Borland's re-branding of the JCL OTAPI exception, combined with an interface to submit bug reports directly to QC. In a nutshell, it takes any unhandled exceptions that occur in the Delphi 2005 IDE, report a dialog - complete with stack trace - to you, and allows you to submit the bug report to QC. It's similar in concept to Windows' online error reporting mechanism. It's a very handy tool, and I believe it will help increase the stability of the IDE, since it gives R&D more information about bugs that pop up in the IDE.

Unfortunately, it looks like it is disabled by default during install (at least it was here on all 8 machines). To turn this useful feature on, run regedit.exe and set the following key/value pair in

HKCU\Software\Borland\BDS\3.0\Known IDE Packages

$(BDS)\Bin\exceptiondiag90.bpl = (Untitled)

If the value is blank, the package will not be loaded in the IDE. Therefore, set it to some arbitrary value, like "(Untitled)", restart Delphi, and you should be greeted with the exception dialog the next time you encounter an unhandled exception in the IDE.

Note: Be careful of using other 3rd party exception tools (e.g. madExcept and Eureka). You'll have to test for sure, but these other packages may end up consuming the exception before it gets to Quality Insight. If that's the case, simply disable the IDE package of the 3rd party exception tool.