twm’s blog

There isn’t yet any official release of GExperts for Delphi XE4 but if you don’t mind a little bit of manual work for installing, you can have it anyway.

WARNING: I have just now made this version compile with Delphi XE4. I have not done any tests. You are on your own and responsible for any damage this version might do to your computer and your files. If you don’t accept this responsibility, do not download the software!

Download
GExperts-XE4-1.37-experimental-twm-2013-04-28.zip
and unpack it to a folder of your choice
(e.g. c:\program files\GExperts for RAD Studio XE4)
Copy the expert you want to use from one of the subdirectories created:

• EditorExpert
• RegularExpert

to the main directory.

Use the ExpertManager tool to register GExperts to Delphi XE4.
Voila, you are done.

This version is based on the current source code from the GExperts svn repository. I have not released it for any other Delphi versions because nothing has changed since the last release.

I always wondered why the assemble tool in dxgettext appends the translation files directly to the executable rather than using the existing mechanism of resources. This is no longer necessary. I have updated the gnugettext code to optionally use RCDATA resources named after the files.

So you e.g. create a translations.rc file as

LOCALE_DE_DEFAULT RCDATA ..\locale\de\LC_MESSAGES\default.mo
LOCALE_DE_DELPHI RCDATA ..\locale\de\LC_MESSAGES\delphi2007.mo
LOCALE_DE_DZLIB RCDATA ..\locale\de\LC_MESSAGES\dzlib.mo
LOCALE_EN_DEFAULT RCDATA ..\locale\en\LC_MESSAGES\default.mo
LOCALE_EN_DELPHI RCDATA ..\locale\en\LC_MESSAGES\delphi2007.mo
LOCALE_EN_DZLIB RCDATA ..\locale\en\LC_MESSAGES\dzlib.mo

Compile it using a resource compiler e.g. brcc32 to translations.res and add it to the executable.

The new code in gnugettext will automatically find and use these resources, all you have to do is add the conditional define dx_SupportsResources.

// if the conditional dx_SupportsResources is defined the .mo files
// can also be added to the executable as Windows resources
// Be warned: This has not been thoroughly tested.
// Default is turned off.
{.$define dx_SupportsResources}

You can find the updated gnugettext.pas in the dxgettext subversion repository on sourceforge.

Disclaimer: I have only cursorily tested this code. Use it at your own risk!

My colleague Daniel has added an option to the dxgettext assemble tool to specify a different directory where to look for the locale data. This is meant to be used, when you compile the executable to a different directory than the one in which the locale subdirectory is located. Since dxgettext would use the locale directory directly if it exists, you can never be sure where your translations come from. Compiling to a different directory solves this issue.

There isn’t a new executable release yet, but you can just check out the dxgettext sources and compile it yourself. It is located in the subdirectory dxgettext\tools\assemble. Alternatively I have a compiled executable in my buildtools on sourceforge, but beware: I take no responsibility regarding viruses or other problems this executable could cause.

It has taken a while but I have eventually arrived in the “modern” Windows world. After many years of sticking with Windows XP (and Linux) I have updated two computers to Windows 8 (both 64 bit) and another two to Windows 7 (64 bit and 32 bit).

In doing so I have been made aware of some annoyances of Windows >= Vista, one of them being the virtual store. This is a convenience feature Microsoft added to Vista and later Windows versions to allow users to continue using old programs without escalating their security issues. This feature virtualizes write access to directories in the file system and branches of the registry that are read only on properly configured systems (like “c:\windows”, “c:\program files\…” or  HKey_LOCAL_MACHINE).

While Microsoft’s intention was good and normal users won’t have a problem with it, for a software developer this feature is rather inconvenient because it prevents him from realizing if his programs do something undesired. Rather than failing and in Delphi’s case raising an exception, these actions succeed and the programmer won’t notice. Even worse, he will not find the files or registry entries his programs was supposed to make in the place he expects them and waste hours in trying to find out what’s wrong.

The idea was that newer software disables this feature with a .manifest resource. Unfortunately this will only work if the programmer updates his development tools to create these files and bind the resources to the program. Delphi 2007 did not know about .manifest resources so it needs some help. There are already many sites with information about this topic so I won’t repeat them. Suffice to say, that a .manifest resource is a special kind of resource that is added to an executable from a text file in xml format.

That format requires version information and also some descriptions, which are already part of an executable’s version resource so I added support for it to dzPrepBuild. As always, that program “eats its own dog food” (uses itself for building), so you can have a look at the source code on how it is done:

• add {$ *_manifest.res} to the .dpr file, like the ($ *_version.res} and {$ *_icon.res} entries that were already in place.
• add a pre-build event to the project which calls the prebuild.cmd file in buildtools if it isn’t already there
• copy the template.manifest.in file from buildtools\templates to your source directory and rename it to <yourprogram>.manifest.in
•  modify it to suit your needs
• The pre-build event will, in addition to creating a *_version.rc file and compiling it, also create a *.manifest file from the contents of the *.manifest.in file + the version information, create a *_manifest.rc file and compile it. This compiled file will then be added by the Delphi compiler to the executable.

Voila: Your program has a valid .manifest resource and Windows will automatically disable virtual store for it. Now you can start finding all the bugs you never noticed. ;-)

Since this is a tool created by one Delphi developer for other Delphi developers and you will probably want to have a look at how it is done anyway, I have not created a release. Just point your favourite svn client to http://svn.code.sf.net/p/dzprepbuild/code/trunk/ and make sure you also include the externals. The project requires Delphi XE2 to compile but it should be easy to revert back to Delphi 2007 if you desire so.

Recently a customer sent me an XML file which was 3.5 gigabyte in size. I had to parse this file and met some new challenges.

The first one was that I did not have any tool to display a file that large. All text editors balked at it and the few viewers (for Windows) that claimed they could handle large files I found on the Internet were slow like dogs or very difficult to use (does nobody teach those kids user interface design nowadays?). I made do with the Linux less command for a while but always putting the file(s) on the server, ssh’ing into it just to display it was an annoyance in itself.

So I ended up rolling my own. It’s of course written in Delphi and needed only a few lines of code. It relies heavily on my TdzVirtualStringGrid component to only keep that part of the file in memory that is currently being displayed. It immediately displays the first few lines of the file and in the background it reads through the file to find CR/LF characters and creates a list of Int64 values with the stream offsets of every single line in the file. While indexing you can only scroll down up to the point that has been indexed but that’s the only restriction.  For the above mentioned 3.5 gigabyte file indexing takes around 30 seconds on my computer.

Apart from displaying the file, it does nothing. There is no search function and it even does not display line numbers. But I thought it might be useful to somebody else, so I put it into my dzlib svn repository on sourceforge. You can find it in the subdirectory tools. so after I received some patches from Daniela Osterhagen for it I put up a sourceforge project for it. There is also a downloadable executable now.

Back when Delphi 2005 was released everybody and his brother complained about the new help system. While up to Delphi 7 it used WinHelp the new version used the Microsoft Document Explorer. The new system was not only slow and buggy, the content also wasn’t up to par with that from Delphi 7. The content issue has been resolved in recent versions, but it is still very slow and at least in some of the Delphi versions the DExplorer task tends to hang after the window is closed preventing Windows from shutting down.

But I digress… I got so annoyed by the new help system, that I wrote an expert for the IDE that opened the old Delphi 7 help when pressing Shift+F1. Later on, I added more options like opening any WinHelp or HtmlHelp file and also open a web browser with the results of various search engines. I also made experts for all Delphi versions from Delphi 2005 to XE3. The latest addition was inspired by the superb Delphi Praxis Help Booster: The expert no longer opens a browser window in a separate task but uses the Delphi welcome page instead.

The project is now on SourceForge. To compile your own expert, use (Tortoise)Svn to download the sources, open the package for your Delphi version and just hit compile and install. A new entry in the Help menu will let you configure what to do on Shift+F1, Ctrl+F1, Alt+F1 and Ctrl+Alt+F1.

Some might know that I have been using and contributing to the GnuGetText for Delphi and C++ Builder project. I just had another look into the gnugettext unit and found that it was rather difficult to understand the logic behind all these if(n)defs that refer to specific Delphi versions and older.

I have now changed the way it works by introducing conditional defines based on compiler / RTL features rather than a range of Delphi versions. These defines are set depending on the Delphi version that supports them. There are currently:

• dx_has_Unsafe_Warnings
• dx_has_WideStrings
• dx_Hinstance_is_Integer
• dx_NativeInt_is_Integer
• dx_StringList_has_OwnsObjects
• dx_GetStrProp_reads_unicode

Also, there was a bug because of the these difficult to read ifdefs regarding the handling of the TStringList.OwnsObjects which exists in Delphi 2009 and later. This should be fixed now as well.

And last but not least I removed a warning when compiling with Delphi XE3.

These changes are in the subversion repository on SourceForge.

Be warned: I have only superficially tested them. If you find a problem with it, please let me know.

Ian (whose last name I don’t know, from the email address I guess he’s from Australia) pointed out a bug in the last release: The option “Except single lines” for adding line feeds after then, else, do and : did not work for for … do and while … do loops.

This issue is now fixed. All my unit tests still work, so I have hope I haven’t broken anything else.

Head over to the Experimental GExperts page to download the new version.