Here, I will be posting notes on converting Subversion repositories to Mercurial.

NOTE: This is work in progress. I will probably come back and change things as well as adding.

Some links on using Mercurial:
Hg Init: a Mercurial tutorial by Joel Spolsky
QuickStart in the Mercurial Wiki

I have got TortoiseSVN 1.8.3 including the command line clients and TortoiseHG 2.10.1 installed.

There are several short tutorials on converting from svn to hg. They all suggest that you first create a local copy of your subversion repository to work on.

A – Create a local copy of your subversion repository
Creating this local copy can easily be done as described by Massimo Iacolare, which I used as a guide.

1 – Create a local svn repository
You can use any local directory as the path to your local svn repository, I will be using the extension .svn to remind me that it is a svn repository. The converted Mercurial repository will not get an extension.

Unfortunately there is the first gotcha: Massimo seemed to be using an older version of svn that used db format 4. The current svn 1.8 uses db format 6 by default, and as Jeroen W. Pluimers found out, the current Mercurial does not support it yet. So, what can we do until the Mercurial developers fix this problem? Why, use db format 4, of course:

svnadmin create --compatible-version 1.7 [path\to\your\new\repository.svn]

I am not sure whether the steps 2 to 4 are necessary, it seemed to work fine without them. I’ll keep them here just in case I run into trouble later because I left them out.

2 – Enable writing on your new repository
Open the file [path\to\your\new\repository.svn]\conf\svnserve.conf and uncomment the line

[general]
password-db = passwd

This tells SVN which file stores the user credentials.

3 – Add a new user
Open the file [path\to\your\new\repository.svn]\conf\passwd and add a new user:

[users]
svnsync_user = svnsync

4 – Give your new user read/write permissions
Open the file [path\to\your\new\repository.svn]\conf\authz and add:

[/]
svnsync_user = rw

5 – Enable rev propchange (revision property change)
create a text file pre-revprop-change.bat in [path\to\your\new\repository.svn]\hooks containing:

exit 0

This can be done easily with

echo exit 0 > [path\to\your\new\repository.svn]\hooks\pre-revprop-change.bat

6 – Initialize the repository

svnsync init file:///[path/to/your/new/repository.svn] [REMOTE PATH]

Getting the local repository path right can be tricky. Pay close attention to the number of slashes and use forward slashes. e.g.

svnsync init file:///c:/some/path/here.svn https://svn.somesvnserver.com/svn/repository

7 – Synchronize
Once the repository is initialized, you can synchronize it as often as you like:

svnsync sync file:///[path/to/your/new/repository.svn]

Be aware, if your repository is big, the first synchronization may take very long.
After the synchronization has been done once, you can keep it in sync by just repeating step 7.

B – convert your local Subversion repository to a Mercurial repository

This is a one step action:

hg convert [path/to/your/new/repository.svn] [path/to/your/hg/repository]

If you omit the second parameter, hg convert will assume [path/to/your/new/repository.svn-hg] which is probably not what you want, but you can easily rename the directory later on.

The DelphiZXingQRCode unit, ported from ZXing by Debenu, allows to easily add QR Code generation to your Delphi VCL applications.

While the DelphiZXingQRCode was designed to support VCL applications (and be used in newer as well as in older Delphi versions), it can also easily be “upgraded” for Fire Monkey applications – be it desktop or mobile (Android, iOS).

DelphiZXingQRCode -> FireMonkey Support

To FireMonkey-enable the DelphiZXingQRCode unit a few changes to the source code were required.

The unit uses “contnrs” (System.Contnrs.pas) unit which implements TObjectList (used by the unit) and other container like classes. Under FireMonkey for mobile, more specifically under ARC, the classes contained in System.Contnrs.pas cannot be used because they are not ARC compliant.

Equivalent classes are to be found in System.Generics.Collections.pas (ARC compliant) where generics versions of TObjectList is defined.

Therefore, the first change is to replace “uses contnrs, …” with “uses System.Generics.Collections, …”

This also requires to make changes like: from “Blocks: TObjectList;” to “Blocks: TObjectList<TBlockPair>;” – that is to use strongly typed generics list classes.

Further, there are lots of “ansistring” and “widestring” types used for parameters in various functions inside the unit. If you want to go mobile, those are not supported and you should use “string”. More info here: Migrating Delphi Code to Mobile from Desktop.

Therefore, the second change to the unit would be to replace “widestring” with “string” and “ansistring” with “array of byte” (or something else as explained in the article).

Single Pixel Drawing (and Other Canvas Drawing) FireMonkey Style

In the VCL, the TCanvas class allows accessing single pixels through the “Canvas.Pixels()” property. In FireMonkey this is not supported and you have to use the SetPixel property of a TBitmapData instance.

Once the qr code is generated, to convert it to a bitmap image, in FireMonkey:

var
  QRCode: TDelphiZXingQRCode;
  Row, Column: Integer;
  pixelColor : TAlphaColor;
  vBitMapData : TBitmapData;
  rSrc, rDest : TRectF;
  s : widestring;
begin
  QRCode := TDelphiZXingQRCode.Create;
  try
    QRCode.Data := edtText.Text;
    QRCode.Encoding := TQRCodeEncoding(cmbEncoding.ItemIndex);
    QRCode.QuietZone := StrToIntDef(edtQuietZone.Text, 4);
    QRCodeBitmap.SetSize(QRCode.Rows, QRCode.Columns);
    for Row := 0 to QRCode.Rows - 1 do
    begin
      for Column := 0 to QRCode.Columns - 1 do
      begin
        if (QRCode.IsBlack[Row, Column]) then
          pixelColor := TAlphaColors.Black
        else
          pixelColor := TAlphaColors.White;

        if QRCodeBitmap.Map(TMapAccess.maWrite, vBitMapData)  then
        try
          vBitMapData.SetPixel(Column, Row, pixelColor);
        finally
          QRCodeBitmap.Unmap(vBitMapData);
        end;
      end;
    end;
  finally
    QRCode.Free;
  end;

  //refresh image control imgQRCode is a TImage
  {code below}
end;

Note: compare this with the VCL approach of TDelphiZXingQRCode usage.

VCL’s Canvas.StretchDraw to FMX’s Canvas.DrawBitmap

There’s no StrecthDraw in FMX’s Canvas class. There’s DrawBitmap. StretchDraw by default does no antialiasing. FMX does. So I had to play a little until I was able to make it work correctly.

I’ve decided to use TImage and not TPaintBox as I was simply not able to make TPictureBox in FireMonkey draw what I wanted

Using TImage, the code to get/display the generated QR Code is as follows:

  //refresh image. imgQRCode is a TImage

  imgQRCode.Bitmap.SetSize(QRCodeBitmap.Width, QRCodeBitmap.Height);

  rSrc := TRectF.Create(0, 0, QRCodeBitmap.Width, QRCodeBitmap.Height);
  rDest := TRectF.Create(0, 0, imgQRCode.Bitmap.Width, imgQRCode.Bitmap.Height);

  if imgQRCode.Bitmap.Canvas.BeginScene then
  try
    imgQRCode.Bitmap.Canvas.Clear(TAlphaColors.White);

    imgQRCode.Bitmap.Canvas.DrawBitmap(QRCodeBitmap, rSrc, rDest, 1);
  finally
    imgQRCode.Bitmap.Canvas.EndScene;
  end;

Aliasing – Do Not Need It!

By default, in FMX, when using DrawBitmap to resize it, antialiasing is used by default. There are two properties you need to set to ensure a bigger copy of your (small) qr code is drawn pixel-copy-perfect.

begin
  imgQRCode.DisableInterpolation := true;
  imgQRCode.WrapMode := TImageWrapMode.iwStretch;
end;

In a FireMonkey Desktop application, this works as expected.

On FireMonkey Mobile it does not – the resized image is still blurred (antialiasing used).

That’s it. QR Codes generation in FireMonkey – both desktop and mobile!

Comments are welcome (even more if you know how to resize a bitmap in FireMonkey on mobile without antialiasing)!

One more for the weekend (:

I wrote about Some links on the Delphi compiler and the LLVM Compiler Infrastructure Project about a year and a half ago which caused a short discussion on the embarcadero forums. A few month later Robert Love showed his views in a response to Tim Anderson writing about Clang and LLVM in the C++ side of the toolchain. Tim Anderson wrote more about LLVM in the Delphi tool chain  in September 2012, then it went quite for a while.

Since then the LLVM tool chain has integrated itself into both the C++ and Delphi toolchains and Wired wrote about LLVM.

Gunsmoker – who works at EurekaLog– wrote up some interesting comments in Rusian (I hope the English Google translation is good enough).

In my view, the LLVM tool chain opens a lot more possibilities (shared back-end for Delphi and C++, coverage of more platforms, better optimization), but is also a lot slower and makes the debugging part a lot harder as the debugger is – symbol wise – much further away from the compiler than in the traditional setting (hence the 3 levels of debugging information that got introduced in Delphi XE5 and the compatibility problem that came with it).

I’m wondering what other users in the Delphi community think about the LVVM chain: is it working good enough for you? Should it be integrated further into the Windows/OSX parts of the chain?

–jeroen

Another update for available for Delphi XE5 and C++Builder XE5, the Update 2 is has lots of bug fixes covering several areas, specially on FireMonkey for Android, iOS, Windows and Mac.

The Update is available for registered users and you can find on the following links. Just a friendly remind that you need to Uninstall your current Delphi XE5 in order to install XE5 Update 2.

• Delphi XE5: http://cc.embarcadero.com/reg/delphi
• C++Builder XE5: http://cc.embarcadero.com/reg/c_builder
• RAD Studio XE5: http://cc.embarcadero.com/reg/rad_studio

Below the complete list of bugs fixed on this Update.

Andreano Lanusse | Technology and Software Development
Follow me on Twitter: @andreanolanusse

Thanks Uncle Bob Martin for posting this.

I’ve been trying (with increasing success: it takes time to get this all right) to practice XP (through various name changes) as much and wide as possible since almost 14 years, and only the last few years it is starting to be common practice for many more people.

take a moment to reflect back on 1999. A time when Kent Beck wrote a ground-breaking book. A book that changed everything. Look back and remember: Extreme Programming; and recognize it as the core of what we, today, simply think of as:

Good Software Practice.

–jeroen

via: Extreme Programming, a Reflection | 8th Light.

So I won’t forget to read these:

• Paul Foster – Google+ – XE5 – Fun with external Java libraries So, having been…
• Above but as a PDF version, thanks Fun with external Java libraries on XE5 by Paul Foster | The Podcast at Delphi.org..
• JNI – the old way of doing it and the Delphi OO way – Chee Wee’s blog: IT solutions for Singapore and companies worldwide.
• Porting the Delphi Android ARM JNI framework to Win32/x86 – Chee Wee’s blog: IT solutions for Singapore and companies worldwide.
• STACK.

Some of my own work on this back in the Delphi 7 days:

• Access to Java jar from Delphi – Stack Overflow.
• java – How to use JNI in Delphi 7 – Stack Overflow.

–jeroen

One rather annoying aspect of FMX’s evolution has been a restriction on control sizes. The most notorious case is probably TGroupBox, which in XE4′s iOS support was bizarrely matched to Safari’s toolbar (i.e., a standard control with a non-standard height), rendering the thing useless. Nevertheless, the general rationale for fixed sizing is not ridiculous – different platforms have different standard sizes for buttons, toolbars and so forth, so it makes sense for FMX to assist the developer in ensuring these conventions are respected. Even so, the implementation taken has been distinctly sub-optimal in my view – in particular, I would have much preferred an AutoSize property that defaults to True. As things stand, standard sizes are instead hardcoded in internal style code and trump even the Align property.

For example, here’s a right-aligned TSpeedButton with its StyleLookup set to ‘composetoolbutton’ and parented to a TListBoxItem, running on an Android tablet. I’ve taken the screenshot as I am pressing the button down – notice how this clearly shows it to be taller than its parent:

Happily, this dubious behaviour can be prevented by overriding the control’s AdjustFixedSize method however. To implement this fix in the form of an interposer class, declare the following immediately before the form type:

type
  TSpeedButton = class(FMX.StdCtrls.TSpeedButton)
  protected
    procedure AdjustFixedSize(const Ref: TControl); override;
  end;

Next, implement the method like so:

procedure TSpeedButton.AdjustFixedSize(const Ref: TControl);
begin
  SetAdjustType(TAdjustType.None);
end;

Fix added, a speed button’s Align property will now be properly respected:

I got a great call the other morning. A Delphi developer from a few versions back was considering upgrading to XE5, but he wanted to know if FireDAC was recommended for database access, or if he would need a 3rd party library.

I remember working on some data driven Delphi applications when the drill was you always bought a 3rd party database access library. There are lots of great database access libraries to choose from, which is one of the great things about Delphi: all the technology partners!

In XE5 the BDE is officially deprecated (and has been for a while), but it still ships (maybe not for much longer though). dbExpress is still there, and so is dbGo and IBX, and they are all good, specialized database access libraries. But with the full integration of FireDAC in XE5, it is the recommended database access library, and for good reason.

FireDAC is a universal data access library: you use the same components to connect to a huge variety of databases. The usage pattern is similar to the BDE, and it is fully bidirectional. It also has a large collection of specialized features for dealing with specific databases, and local, in memory data.

If you are still on the BDE, check out the FireDAC migration guide or any of the other great FireDAC documentation. Cary Jensen just did a fabulous webinar on FireDAC including a fabulous 70 page whitepaper.

Of course you are still welcome to continue using 3rd party libraries, and some of them may offer some other specialized features. That is one of the great things about Delphi, C++Builder and RAD Studio: It comes with great features in the box, but you can expand on those with 3rd party libraries.

If you still aren’t on XE5, you still have a little time to take advantage of the special offers.

Back when XE3 was current I blogged about retrieving the default FMX styles for Windows and OS X, a process less transparent than in XE2 when the standard styles were distributed as *.style files. Roll onto mobile support in XE4 and XE5, and the default styles are if anything even more hidden. Nevertheless, it is possible to recover them and get human-readable *.style files:

1. Find the resource name; for Android this is currently ‘androidstyle’ (see FMX.Controls.Android.pas), for iOS one of ‘iphonestyle’, ‘ipadstyle’ or ‘iphonepadstyle_Modern’ (= iOS 7; see FMX.Controls.iOS.pas).

2. Create a blank new mobile project, and in the form’s OnCreate event, load and output the desired resource to a file. For example, for Android you might do this:

uses System.IOUtils;

procedure TForm1.FormCreate(Sender: TObject);
var
  FN: string;
  Stream: TResourceStream;
begin
  FN := TPath.Combine(TPath.GetHomePath, 'FMX default.style');
  Stream := TResourceStream.Create(HInstance, 'androidstyle', RT_RCDATA);
  Stream.SaveToFile(FN);
  ShowMessage('Saved to ' + FN);
end;

3. Run the app on a device.

4. Manually copy over the extracted file to your development PC or VM.

5. Back in your dummy project, add a TStyleBook component to the form, and double click it to open the style book editor.

6. Click the ‘Load’ button and locate the extracted *.style file.

7. Click the ‘Save’ button and overwrite the extracted *.style file.

The reason for step (7) is because the style will be extracted in a binary format, and resaving in the style book editor will output to a textual one. More specifically, it will convert from the DFM binary format to the DFM textual one with just a simple header added – FMX being based on the VCL’s streaming system as much as the VCL itself.

Removing platform restrictions

If between running the dummy app on the device and loading the extracted style file into the style book you changed the active target platform, the style book editor will complain:

To prevent this happening in future, once you have reselected the ‘correct’ target platform (Android in my case) and now successfully loaded the style file, select the style’s ‘description’ component in the Structure pane and press Delete:

Having clicked Apply (or Apply and Close), the style will also now load when you select a different platform (just remember that to make a style book active, the form’s StyleBook property needs to be assigned). Here for example is the Android style used when running on Windows:

While XE5 update 2 introduced a special ‘mobile preview’ style for testing mobile projects on Windows, you can’t beat having the style that will actually be used on a device I think.

Hello everyone in 2014 :)

First of all, I would like to present a small game I did during a weekend "gamejam" at the end of November 2013:

Darkest Before the Dawn

The game is free to download for Android, Linux or Windows. Of course the game uses our Castle Game Engine for everything. The complete game code and data are available in our SVN repository.

Next, we have news about the engine development:

1. Yes, you have heard right: the engine supports Android and iOS (iPhone, iPad).

   The rendering is done using an OpenGL ES 2.0 renderer. Most of the rendering features work (and the rest is in-progress :). Rendering 3D shapes with shaders, textures, lighting of course works. Note that mobile shaders use the Gouraud shading for speed. Rendering 2D images (TGLImage) is also done. Since TGLImage is used underneath by all our 2D controls — most of 2D GUI works (except fonts, for now...).

   You can compile the whole engine for OpenGLES (as opposed to normal desktop OpenGL) by defining symbol OpenGLES in base/castleconf.inc file. This symbol is defined automatically when we compile for Android or iOS, but you can also test OpenGLES renderer on normal systems like Windows and Linux (it's a nice way to test your mobile game on a desktop system).

   We can initialize OpenGLES context using the EGL library. This is useful to initialize OpenGLES on Android or Xlib (with glX+EGL) or Windows (with wgl+EGL).

   The Android port uses NativeActivity, available since Android 2.3. It requires FPC 2.7.1 to cross-compile code to Android ARM, see FPC wiki about Android. Integration with Android includes using Android's log facility (just use WritelnLog from CastleLog unit) and using Android's assets (URLs like assets:/my_texture.png are supported, and ApplicationData returns assets:/ to read data from apk).

   You can develop cross-target games (for Android, iOS, or standalone — normal OSes like Linux or Windows) using the engine. This means that a single source code can be used to compile multiple versions of the game. We also have plans to make a "build tool" for the engine to auto-generate the necessary files for the compilation on given target (although it's unsure if this will be ready for next release). See Planned: build tool wiki page, and drop a comment if you're interested!

2. Engine can be compiled and used as a shared library (castleengine.dll on Windows, libcastleengine.so on Linux), with API accessible from C or C++. We provide a C header in src/library/castlelib.h for this purpose. See code in src/library/ and tests in examples/library/ .
3. The default TWalkCamera inputs are now equal to TPlayer inputs, in particular they honour common AWSD combo.
   • You can move using AWSD by default (e.g. in view3dscene).
   • Space / c keys make jump / crouch. We no longer have separate inputs for jump / crouch (when gravity works) or flying up / down (when gravity doesn't work).
   • This avoids switching the meaning or left / right arrows in mouse look mode in view3dscene.
   • This makes keys in all our programs and games more consistent. And everyone knows AWSD, while previous shortcuts for strafing (comma and dot) were quite uncommon.
   • Of course, all TWalkCamera inputs remain configurable. So, if you really liked previous key shortcuts, you can restore them for your application.
4. TextureBackground support, making it possible to use MovieTexture as skybox sides. The rendering of Background and TextureBackground uses new simplified code, that can utilize our texture cache and works on OpenGLES too.
5. Notes about transformation hierarchy added to the documentation.
6. Context resource sharing (so that many windows/controls work OK, sharing textures and fonts and such) implemented for CastleWindow Xlib+GLX and GTK backends.
7. Support for png and gz formats without any external libraries (using FpRead/WritePng and PasZlib underneath). This is particularly useful for Android and iOS, where linking with external libraries is not so easy.
8. CastleEnumerateFiles API much changed and renamed to CastleFindFiles. It supports searching for files inside Android assets too (although, unfortunately, not recursive — because of NDK API limitations).
9. --hide-menu option implemented for view3dscene. Useful e.g. for fullscreen presentations, where you may want to hide all UI.

I forgot who pointed me at this, but recently I came across a reference to the Good Ideas, Through the Looking Glass paper by Niklaus Wirth (by many known as the “father” of Pascal, though he has done a lot more - for instance the WSN - , still is involved with the ETH in Zürich, and turns 80 on February 15h).

Back when it appeared in the 2005/2006 timeframe I missed it, and I’m glad to have bumped into just for the historic perspective he offers. I can understand some will disagree with parts of his conclusions and observations, that’s why I like that MetaFilter has a nice page with discussion about it and a link to the PDF version of the paper.

I also like that Niklaus kept active in the field of computer science for so long, similar to Donald Knuth. There is a lot to having a great historic perspective to things.

–jeroen

via: Good Ideas, Through the Looking Glass | MetaFilter.

When I’m head-down in a ‘long hours’ contract I tend to miss quite a bit of Delphi-oriented news. Once in a while I look up and I find a whole host of interesting posts around the blog-world and this has been the case over this seasonal break.

I’ve been browsing around seeing what’s new and have collated the following list of stuff I found interesting. Anyone else who hasn’t been keeping up-to-date on news of late might possibly also find some stuff of interest in the list.

Happy New Year!

• Delphi XE5 Update 2
• Recent VCL enhancements
• New product features for old product users
• reFind for search/replace with PCRE
• Mobile coding topics
• DEP & ASLR in Windows projects

Delphi XE5 Update 2

If you're a user of Delphi XE5 or RAD Studio XE5, then unless you've been hiding under a rock you'll be very much aware that Update 2 was released a while back (10^th December, 2013). There are quite a few changes, so it's basically one of those uninstall/reinstall cycles. On the EDN page for Update 2 you can pull down the web installer, which downloads all the required bits over the web as it sees the need to, or pull down the rather larger full Update 2 ISO CD image. When I used the CD image I found that Hotfix 1 and Hotfix 2 (also mentioned on the same page) appeared to be already applied.

However as François Piette pointed out, we now also have a Hotfix 3 for Update 2. This addresses a few missing .OBJ files (compiled versions of C source files for the JPEG support). In the absence of a README file, I decided these files belonged alongside their corresponding source files in $(BDS)\source\vcl\jpg\src (e.g. C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\source\vcl\jpg\src).

Update 2 does incorporate a good number of fixes, including the really annoying one where the form designer keyboard shortcuts (various permutations of Ctrl, Shift and the cursor keys) were not supported by the FMX form designer (as Marco posted).

Here are links for the Release Notes and the What's New page for XE5 Update Pack 2.

One of the key features added in Update 2 was iOS development support for C++ programmers. David Intersimone made a handful of posts showing how to use this support, and they have been accompanied by and followed up with a variety of videos on the Embo YouTube channel:

• C++Builder XE5 iOS Preview slides, video
• What's New in C++Builder XE5 for iOS, video
• Building your first C++Builder multi-device application, post and video
• Using TabControls, Gestures and Actions in your C++Builder XE5 for iOS apps, post and video
• Using Image Effects Filters in your C++Builder for iOS apps, post and video
• Location enabling your C++Builder for iOS apps, post and video
• Mobile Code Snippets: IBLite on iOS, video
• Mobile Code Snippets: Date Picker for iOS, video
• Mobile Code Snippets: Sharesheet & Media Library Actions, video
• Mobile Code Snippets: Sending & Cancelling Notifications, video
• Mobile Code Snippets: Tap & Hold Interactive Gesture, video
• Mobile Code Snippets: Sending & Resetting Badge Numbers, video
• Mobile Code Snippets: Pinch & Zoom Interactive Gesture, video

Another neat feature slipped in is the Mobile Preview feature, which allows you to compile and test a good chunk of your mobile functionality within a Windows preview app. It's discussed by Marco here and Sarina DuPont here and documented here.

Recent VCL enhancements

Given Embo's focus on talking lots and lots about FMX over recent years it's easy to forget that the VCL is still being enhanced. Indeed so easy that when XE5 was released, the home page made nary a mention of VCL! Anyway, in an attempt to redress the balance DavidI emitted a blog post that talks about the benefits of VCL in Delphi XE5.

In there he mentions support for 64-bit Windows, full Unicode support, FireDAC, the REST client support, VCL styles, LiveBindings, Metropolis for Windows 8-like apps, and sensor support.

Some additional posts on the REST client support are:

• No time to rest: Endless possibilities with REST for VCL and FM by JT
• Using FDMemTable with REST in your VCL apps by Sarina DuPont
• Riding the waves over the holidays with REST by Sarina DuPont

On the subject of FireDAC, if you missed it you can catch the replay of Cary Jensen’s webinar on the subject, entitled: No App is an Island: Universal Enterprise Data Connectivity for the Multi-Device World with FireDAC. Also available on that page are a hefty white paper by Cary to back up the webinar and links to some FireDAC videos.

And for additional Unicode information, check the list of resources collated by Malcolm Groves (and others in the comments) in his post Resources for Unicode in Delphi.

New product features for old product users

I discovered that Embo have made some pages that talk about new features in releases since certain commonly used old versions. For those trying to find out how much merit there might be in upgrading to the current XE5 release from an old version these pages could prove pretty useful. So we have:

• What RAD Studio XE5 or Delphi XE5 can offer to users of Delphi XE2, Delphi XE3 and Delphi XE4
• What RAD Studio XE5 or Delphi XE5 can offer to users of Delphi 2009, Delphi 2010 and Delphi XE
• What RAD Studio XE5 or Delphi XE5 can offer to users of Delphi 2006 and Delphi 2007
• What RAD Studio XE5 or Delphi XE5 can offer to users of Delphi 7

Warren Postma has a post citing a variety of reasons to upgrade: Modernize your codebase: Inspiration to Ditch your Ancient Delphi Version. Do read through them.

reFind for search/replace with PCRE

Here’s a tool I didn’t notice appear in Delphi XE5. It’s a command line find/replace tool that uses Perl-compatible regular expressions (PCRE). It’s documented in the XE5 docwiki and uses a rule file to control the process of running over a bunch of source files (and form files) making specified changes.

The tool comes from FireDAC (née AnyDac) and was designed to help migrate BDE components and code over to [Any|Fire]DAC equivalents, but of course can be applied to any search/replace scenario.

Embo’s Stephen Ball posted on the topic of source migration from Delphi 5 to Delphi XE5, which is where I first bumped into the tool. I’ve since seen it referenced on posts on Mick’s Mix and Marco’s blog.

Mobile coding topics

We've had a good spate of posts on how to do various things in Delphi mobile apps.

Here are some Android-specific ones:

• How to create an overflow menu by Sarina DuPont
• Installing and running Android apps from the command-line by Jim McKeeth
• How to use a broadcast receiver to auto-start an app on device boot by Danny Wind (using my broadcast receiver approach from my service app sample)
• FireMonkey, Android, Windows and PostMessage, or how to use the messaging system on Windows and Android with common code, by François Piette
• D.P.F. Delphi Android Native Components (Open Source) by Babak Yaghoobi, and posted about by Chris Rolliston
• An overview of how the Delphi Java bridge works for importing Android APIs by Chee Wee
• How to deal with ShowModal requirements on Android by Marco Cantu

Here is an iOS topic:

• D.P.F. Delphi iOS Native Components (Open Source) by Babak Yaghoobi

And here are some that cover both Android and iOS:

• How to produce an Android-like Toast message across iOS and Android by Roland Kossow, which uses my Android Toast import unit
• Creating a slide-out drawer by José León
• Deploying/accessing local files on iOS and Android by DavidI
• Loading custom styles at runtime by Sarina DuPont

Additionally DavidI posted a useful set of resource links that came up in his Step Up to the Multi-Device App Platform webinar so do peruse them at your leisure.

DEP & ASLR in Windows projects

While looking into reFind I bumped into a new (to me) Delphi blog from Mick Grove called Mick’s Mix. A 2011 post on there reminded me of support added to Delphi 2007 and later to support DEP (Windows XP SP2 and later) and ASLR (Windows Vista and later).

DEP is Data Execution Prevention, which helps avoid hacked data bytes being executed. This is done in 32-bit apps using AMD’s NX (no-execute page protection) processor feature and Intel’s XD (Execute Disable Bit) processor feature.

ASLR is Address Space Layout Randomization and helps foil buffer overrun exploits by randomising the load address of DLLs. Thus ASLR is only really pertinent to DLLs or packages.
[ Update: thanks to Ericlaw for pointing out that setting the DynamicBase flag in an executable project randomises the location of heaps and other data structures, as well as enabling other mitigations. In other words, ASLR should really be enabled on all projects as should DEP. ]

According to a post by MSDN blogger Michael Howard, and echoed by a post by Hallvard Vassbotn, Delphi 2007 added support for ASLR and DEP by the small operation of adding this after the uses clause in the project file:

{$SETPEOPTFLAGS $140}

This sets 2 flags in the DllCharacteristics field of the IMAGE_OPTIONAL_HEADER section of the PE file that your DLL will be emitted as by the linker.

IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE and IMAGE_DLLCHARACTERISTICS_NX_COMPAT are defined by Microsoft’s MSDN documentation as having the values 0x0040 and 0x0100 respectively.

IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE is defined as: the DLL can be relocated at load time.

IMAGE_DLLCHARACTERISTICS_NX_COMPAT is defined as: the image is compatible with data execution prevention (DEP).

Neither of these constants is defined in Delphi’s Winapi.Windows.pas, but for readability you could alternatively write this below the DLL project’s uses clause:

const
  IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE = $0040;
  IMAGE_DLLCHARACTERISTICS_NX_COMPAT = $0100;

{$SETPEOPTFLAGS IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE or
                IMAGE_DLLCHARACTERISTICS_NX_COMPAT}

For ASLR in DLLs and packages you can alternatively use the undocumented {$DYNAMICBASE ON} directive (as mentioned by Michael and Hallvard), which has the same effect as setting the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE PE opt flag. Thus this would be a viable equivalent:

const
  IMAGE_DLLCHARACTERISTICS_NX_COMPAT = $0100;

{$SETPEOPTFLAGS IMAGE_DLLCHARACTERISTICS_NX_COMPAT}
{$DYNAMICBASE ON}

Note that in more recent product releases you can also pass these optional PE header flags using a linker switch. In the Linking section of the Project Options dialog you can pass the combined decimal flags value to the Set extra PE Header optional flags field, so $140 would need a value of 320 to be passed in.

You can see that the flags have been noted by looking at the properties of your project when running using a tool such as Process Explorer from SysInternals.

Last time around I blogged about how to extract the default XE5 mobile styles into *.style files – in a nutshell, you need to create an app that extracts the desired style resource to a file, then open the file in the stylebook editor, delete the ‘Description’ resource, and resave. In that post I went on to suggest using the extracted files in TStyleBook components. There is however a better way – provide a custom FMX.MobilePreview unit instead (NB: for all about the standard mobile previews – introduced in XE5 update 2 – check out either Marco Cantù’s blog post or the documentation).

To do this, create a new unit and, modeling on the standard FMX.MobilePreview.pas, add the following code:

unit FMX.MobilePreview;
{
  Use actual Android style
}
interface

implementation

{$IFDEF MSWINDOWS}

{$IF CompilerVersion <> 26}
  {$MESSAGE Error 'Custom FMX.MobilePreview.pas expects XE5!'}
{$IFEND}

uses
  System.Types, System.SysUtils, FMX.Styles, FMX.Graphics, FMX.Platform;

var
  OldInitProc: TProcedure;

procedure InitializeStyle;
begin
  if Assigned(OldInitProc) then
    OldInitProc();
  //!!!change path to whereever you have put the resaved *.style file
  TStyleManager.SetStyle(TStyleManager.LoadFromFile('C:\Delphi\LibXE5\Android.style'));
end;

initialization
  OldInitProc := InitProc;
  InitProc := @InitializeStyle;

finalization
  TStyleManager.SetStyle(nil);
  TCanvasManager.UnInitialize;
{$ENDIF}
end.

If you save the unit as FMX.MobilePreview.pas, compile and ensure the DCUs are in the global search path, you can have the IDE pick it up rather than the standard FMX.MobilePreview.pas. Alternatively, save it under a different name and just amend your project files to use it rather than FMX.MobilePreview.

That said, if you do this, something still won’t quite be right – namely, the font:

This is because in the current FireMonkey code, the default font is a property of the platform rather than the style. As such, the font used here is a regular Windows one rather than Roboto, the default font on Android. Fixing this discrepancy is easy however – back in the custom unit, first add the following class immediately after the uses clause:

type
  TFMXSystemFontService = class(TInterfacedObject, IFMXSystemFontService)
  public
    function GetDefaultFontFamilyName: string;
  end;

function TFMXSystemFontService.GetDefaultFontFamilyName: string;
begin
  Result := 'Roboto';
end;

Secondly, unregister the standard IFMXSystemFontService implementation before registering our own by adding the following lines at the top of the unit’s initialization block:

  TPlatformServices.Current.RemovePlatformService(IFMXSystemFontService);
  TPlatformServices.Current.AddPlatformService(IFMXSystemFontService, TFMXSystemFontService.Create);

In all, the code for unit should now look like this:

unit FMX.MobilePreview;
{
  Use actual Android style
}
interface

implementation

{$IFDEF MSWINDOWS}
{$IF CompilerVersion <> 26}
  {$MESSAGE Error 'Custom FMX.MobilePreview.pas expects XE5!'}
{$IFEND}
uses
  System.Types, System.SysUtils, FMX.Styles, FMX.Graphics, FMX.Platform;

type
  TFMXSystemFontService = class(TInterfacedObject, IFMXSystemFontService)
  public
    function GetDefaultFontFamilyName: string;
  end;

function TFMXSystemFontService.GetDefaultFontFamilyName: string;
begin
  Result := 'Roboto';
end;

var
  OldInitProc: TProcedure;

procedure InitializeStyle;
begin
  if Assigned(OldInitProc) then
    OldInitProc();
  TStyleManager.SetStyle(TStyleManager.LoadFromFile('C:\Users\CCR\Downloads\Android FMX (resaved, and minus description).style'));
end;

initialization
  TPlatformServices.Current.RemovePlatformService(IFMXSystemFontService);
  TPlatformServices.Current.AddPlatformService(IFMXSystemFontService, TFMXSystemFontService.Create);
  OldInitProc := InitProc;
  InitProc := @InitializeStyle;

finalization
  TStyleManager.SetStyle(nil);
  TCanvasManager.UnInitialize;
{$ENDIF}
end.

Run the mobile preview again, and the font is now how it should be: