BorderStyle is set to bsNone, ReadOnly to True, ad it looks just like a label on modern Windows.

But as soon as you use this on a Windows that uses the classic style (the one that looks a bit like Windows 2000), the tabsheets do no longer have a white background, but a clBtnFace one, and since TEdit is not really tranparent, they look out of place suddenly.

I searched the Delphi-PRAXiS forum for solutions, and found a TTransEdit component there – but that one, I had already discarded years ago, and again didn’t solve the issue for me.

Annoyed by all these struggles, I went another route. I added UXTheme to the uses clause, and simply updated the color based on theming.

procedure TformNTProcess.FormCreate(Sender: TObject);
begin
   FProcessImageName := '';
   FTerminated := false;
   if not UseThemes then begin
   editImageName.Color := clBtnFace;
   editImageNameNT.Color := clBtnFace;
   end;
end;

So far, this works much better and reliable than replacing all TEdit with TTransEdit. Granted, it does not provide transparency for background images, but it solves the TTabSheet theming issue better than a nonperfect transparency solution.

I’m a low level coder. If I use databases, I use SQLite or WySQL libraries directly, without the overhead of Delphis database components. Some questions deal with this. Guessing how many areas there are and that you need only 80% of correct answers to pass, I decided I could have some lack of knowledge here.

Another area are generics and anonymous methods. Before upgrading from Delphi 2006, I never cared about them, so I had to learn. Not that difficult, I reserved half a day and knew everything I needed.

Meanwhile, time has passed, since work is more fun than exams, and I requested the serial for the exam the last day possible, and took the exam again the last possible day. Wouldn’t have needed to, since answering the majority of questions took 15 minutes, with another 15 minutes spent on 5 questions I was unsure about.

If you also have a free go at the test, I can only recommend taking it. Even if you don’t prepare, you won’t loose anything, but if you spend some time on preparation and have a few years of background, I think it’s easy to pass.

To sum things up, after a header of 20 bytes, we have repeated records of this type:
TIconStreamRecord = packed record
FilenameRaw: array [0 .. 263] of WideChar;
VisibilityRaw: DWord;
Reserved0: array[0..3] of byte;
LastVisibleTooltipRaw: array [0 .. 253] of WideChar;
Reserved1: array [0 .. 591] of Byte;
Reserved2: DWord;
end;
Filename and Tooltip are Rot13 encoded, in a strict form (only letters are moved). Visibility is 0 to 2, with 0 being Only Notifications, 1 Hides Icons and Notifications, and 2 shows both. There’s more data in there, but that is irrelevant for this question and open for some future fun.

I got notice of this due to subscribing to the announcement thread on their forum, and went ahead to download and try it.

So far, the new driver seems to emulate the mouse well – scrolling in Explorer and Firefox for example works out of the box.

Code-signing files on Vista with the Vista SDK (and of course Win7) has a new command line parameter available: /ph generates page hashes for executables.

In combination with a IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY (0×0080) flag in the Characteristics field of the PE Optional Header, this allows some more security.

After researching bugs for a long time without success, Microsoft finally helped me pinpoint the problem – the section table of files compiled with Delphi, including 2009, lists sections with a physical size of zero but a non-zero address, which causes the failure. A workaround is to manually patch the section table of Delphi executables here.

I’ve got a small tool that does this, but had hoped for Delphi to fix this. Because Microsoft is clear on the specifications of the PE format, the PointerToRawData for empty sections to be exact:

“When a section contains only uninitialized data, this field should be zero.”

So why do you create files where this is not so, Embarcadero?

More information:

• MSDN: PE Optional Header
• Microsoft: PE format documentation
• Embarcadero QualityCentral issue 72147

This means that in an ideal case, an application crashes, WER looks up the error and informs the user that he should update to version X.Y to avoid this problem in the future. And if the bug is yet unfixed, at least the developer receives information about in (from WinQual) and can deal with it.

This basically means that at least for the Release builds, Delphi should simply call WER. I reported this as a bug in 2007 (since not doing so makes it impossible to get Certified for Vista), but so far, the issue was opened, but otherwise ignored.

You can work around this by adding your own handler for unexpected exceptions and calling ReportFault from there, but since this is standard that should be part of all applications, I would expect this to be part of the RTL.

More information:

• MSDN: AddVectoredExceptionHandler
• MSDN: VectoredHandler
• MSDN: ReportFault
• Embarcadero QualityCentral issue 39132

To add one downside of WER: I like madException a lot for error reporting in test versions, where data won’t have to be passed to Microsoft. But then, test versions don#t need to be certified, so using madExcept for DEBUG and WER for RELEASE builds is my way to go.

Why that? By compatibility, I refer to Microsofts standards. If I use some tools to create applications for Windows Vista or Windows 7, I expect that my created applications could at least pass Microsofts certification process.

Starting with Windows Vista, Microsoft has introduced UAC, which makes certain settings within the manifest file mandatory (necessary for the certification process). And next to certification requirements, MSDN says:

“In future releases, the only way to run an application elevated will be to have a signed application manifest that identifies the privilege level that the application needs.”

Which means it will be mandatory for applications that need to elevate (need administration rights).

Now, you can create a manifest file yourself and embed it within the application, so this is not really a total showstopper, but Delphi still has just a simple checkbox labeled “Enable runtime themes” that would add an imcompatible manifest. Sad, isn’t it?

More information:

• MSDN: Create and Embed an Application Manifest
• Embarcadero QualityCentral report 37448

I also finally uploaded the source code to LaunchPad, the open source platform I use, so now my previous updates to the code, including for example OwnerData as well as section hightlighting. The printer dialogs from examples have also been added into reusable units, and the prefix changes from MP to dcr, since I plan to add more legacy forsaken code into this package.

More information:

• Delphi Code Revival @ LaunchPad