It's a blong, blong, blong road...

Installer tip

2021-04-08T08:10:00.001-07:00

I'm really enjoying RAD Studio 10.4.2, but my journey with it got off to a less than wholesome start. I'd installed from the .iso download and put just a basic Windows platform support in. Shortly thereafter I wanted more target platforms installed so I chose Tools, Manage Platforms... and was disturbed to see this message:

O NOES!!11111!1!!!one!! (or some other geeky response)

Fortunately there was no corruption. This post is simply to pass on the tip of what to do if you happen to see this, instead of following the knee-jerk reaction of immediately uninstalling and reinstalling.

The issue here is misinformation. It's not necessarily corrupted at all - the installer displays this message if it cannot find the installation database file. When you installed RAD Studio the location of the installer file is written to the registry within this key:

HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\CatalogRepository

The value ServicePath in that key points to a .gof file, in my case F:\radstudio_10_4_esd_104203a.gof. The thing is, I installed from a .iso file, which I mounted to a drive (F:) at the time and had since unmounted, ∴ that path no longer reached anything. Unfortunately the installer responded inappropriately: misinformation.

I gather this issue will be fixed for the 10.5 installer, but hopefully this saves someone the trouble of an uninstall and reinstall at some point.

SAPI (Microsoft Speech API) problems with the IDE

2021-04-07T16:06:00.004-07:00

Every few months or so someone sends me an email telling me they've speech-enabled their application with SAPI (the Microsoft Speech API) after having read my old coverage (specifically that for SAPI 5.1) from conferences in 2002 and before. It's always good to hear that stuff you've worked on is being found useful, even long after you did it, in this case frighteningly close to 2 decades ago (Ͼ˳Ͽ)..!!!

Sometimes the communications are asking how to do specific things with SAPI - unfortunately those are typically a dead end, as I haven't used SAPI in anger for a long while.

Sometimes, though, people are stuck on the basics and I was recently contacted by someone with a fairly current version of RAD Studio saying they couldn't get started at all. It turns out that the current version of SAPI, SAPI 5.4, cannot be imported into RAD Studio!

Uh-oh. Time to investigate...

The steps to import SAPI components into the IDE is as follows (and is documented here):

Choose Component, Import Component... (as mentioned in the documentation)
Select Import a Type Library and press Next
Choose the Microsoft Speech Object Library that is defined in sapi.dll:

Press Next and choose a target Palette Page:

Press Next, select Install to New Package and press Next again
Now choose a value for Package name (and optionally for Description) and press Finish:

At this point the package will be created and a type library import unit is added to it and the IDE will try to build the package. Immediately something is flagged up:

Click Yes and the package will start building proper. This is where it all falls apart:

Hmm, is there a massive FUBAR in the type library importer? Sure looks like that could be the case....

However, upon closer inspection the issue actually comes up thanks to the SAPI type library defining its own versions of the already-defined-in-Delphi interfaces IStream and ISequentialStream. In the SAPI versions they have extra methods, references to which then fail to compile thanks to those methods not being imported.

Why are those 'known' interfaces not imported? Well, the idea is to avoid ambiguity with having multiple definitions, but that's not important as... we can override this omission!

In your RAD Studio bin folder (e.g. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin) you will find a file called tlibimp.sym. This is the configuration file for the type library importers (both the one in the IDE we just used and also the command-line utility TLibImp.exe). The content of this configuration file affect the way type libraries get imported to help cover various trouble areas. In this case we need to remove some settings to get the SAPI type library imported.

Here is a part of tlibimp.sym:

;;===================================================================;;
;; Names listed in this section are skipped by the importer
;; Built-in Interfaces, such as IUnknown and IDispatch are listed
;; here
;;===================================================================;;
[BuiltInInterfaces]
{00020400-0000-0000-C000-000000000046}=IDispatch
{00000000-0000-0000-C000-000000000046}=IUnknown
{0000000C-0000-0000-C000-000000000046}=IStream
{0C733A30-2A1C-11CE-ADE5-00AA0044773D}=ISequentialStream

We need to comment out the IStream and ISequentialStream lines to get a successful import. Once those 2 lines have semicolons inserted at their start we can try again.

Remove the emitted import unit SpeechLib_TLB.pas from the package still open in the IDE, then delete that unit from disk and close the package project.

Now you can go through the steps above again, but this time instead of selecting Install to New Package you select Install to Existing Package. After pressing Next you press Browse and locate the original DCLSAPI54.dpk project file, which by default will have been saved in the default Delphi projects folder (Embarcadero\Studio\Projects within your Documents folder tree).

This time the package will build and you will be told of the component wrappers now installed in the IDE:

If you want to import the SAPI type library from a RAD Studio Command Prompt you can run this command:

tlibimp -P -Yh+ -Yr+ -HpsActiveX C:\WINDOWS\System32\Speech\Common\sapi.dll

Note that the SAPI 5.x sample applications from the 2002 conference paper have been updated and are available along with an updated import package at these URLs:

Deleaker: memory / resource leak detection and identification

2020-10-20T11:20:00.002-07:00

As I've made clear many times in conference talks I’m a big fan of FastMM4, the full version Delphi’s built-in memory manager (I haven’t yet tried out FastMM5, which is fully rewritten but now has either a GPL or a commercial license). FastMM4 is great for identifying memory leaks, memory corruption, interface misuse and so on, and locating the source of the problem via a call stack. However it is true that the business of working through the FastMM4 reports is somewhat manual – reports and call stacks are sent out via debug strings or log flies and then you have to pore over the details and work things backward to the source of the problem. It does the job, but takes a back seat once the details have been discovered.

Some while back I got pointed in the direction of another leak detection tool, Deleaker from Softanics, of which I hadn't heard at that point. It’s taken me a while to clear my desk sufficiently to check it out but I’m pleased to have done so, as it’s a very nice and helpful tool.

I should mention up front that this is a commercial tool, like FastMM5 (when not used with the GPL license) and unlike FastMM4, Delphi LeakCheck, MemCheck ¹ and TCondom ². It costs $99 for a home license and $399 for a single developer license.

Some key points about Deleaker:

It is not just a tool for EMBT development languages: it supports Delphi, C++Builder, Visual C++ and Qt Creator
It’s not just a memory leak detector, but also supports resource leak detection for a pleasing array of resource types
It is not just a library, but offers a full UI experience, either integrated into the IDE (RAD Studio, Visual Studio, Qt Creator) or standalone, or even controlled through a command-line utility for use in Continuous Integration setups
It supports Win32 and Win64 targets

If you and/or your development team happens to dabble in C++Builder or Visual C++ then this tool would be a common weapon to deploy against leaks of all sorts.

The list of entity types that can be tracked looking for leaks is impressive:

Memory blocks allocated by heap functions, virtual memory, OLE memory: BSTR, SAFEARRAY, etc.
GDI objects: HBITMAP, HDC, HPEN, etc.
User32 objects: HICON, HCURSOR, etc.
Handles: file handles, events, mutexes, etc.
File views
Activation context cookies
Fibers
Critical sections
Environment strings
FLS (fiber-local storage) slots
TLS (thread-local storage) slots
Atoms

The typical way a Delphi or C++Builder developer would use Deleaker is using the IDE integration – there is a Deleaker menu added between Run and Component in the main menu. This menu allows you to enable or disable Deleaker’s interest in your project, set some options via a dialog and display the Deleaker window (the UI is the same in the standalone tool as it is in the IDE integration). When not debugging the window looks like this (note that when using this from within RAD Studio this is a dockable window, so you can tuck it away in your preferred area of the IDE’s UI):

Here you get a flavour of what is on offer. You can see we have support for taking and comparing snapshots, which is the mechanism we use to identify leaks in the application. There is a button to invoke the resource usage graph, which allows you to see a dynamic representation of resource consumption over the last 60 seconds.

Let’s do a simple test on a simple memory leak by some code like this:

procedure TForm1.Button1Click(Sender: TObject);
begin
  var P: PByte;
  GetMem(P, 1024 * 1024);
end;

Running this up and battering Button1 shows this in the resource graph. The initial slope up was the application startup and the addition rise was the memory allocations caused by the button presses.

OK, that gives a view of consumption and in a real application potentially indicates an issue, so now we can use snapshots to look for a potential problem.

The idea is to take an initial snapshot (using the Take Snapshot button) as a baseline, then shortly thereafter take another snapshot and compare the two. You can then see all the allocations that have not been deallocated and look for any you weren’t expecting.

When you press Take Snapshot Deleaker briefly freezes the information and collates a whole bunch of information it requires. This includes building up call stacks for each allocation that has not been freed. Deleaker understands about the symbol information format used by Delphi and C++Builder. But additionally, since it also operates within Visual Studio it understands Microsoft’s symbol format and has support for using the Microsoft Symbol Servers. This means that where necessary call stacks will include detailed information about Microsoft OS DLLs.

This animated GIF shows Deleaker acquiring its data for the first snapshot.

Note that the symbols shown towards the bottom of the screen at the end of the animation are not representative of what you will actually see. Current versions of Deleaker will "demangle" these "mangled" symbol names to provide a more readable stack trace.

After the first snapshot I press Button1 and then take a second snapshot. Now I have Snapshot #1 and Snapshot #2. The Compare with… button can then instigate the comparison between the current snapshot and another one:

This now shows the differences between the two.

Here we see a single unfreed allocation of Heap memory of size 1048576 (which is 1024 x 1024) and Deleaker shows the source file and line number of the allocation as well as the call stack leading up the allocation.

Double-clicking on any entry in the call stack (either your code or RTL/VCL code) will take you to the relevant location in the relevant source file (or you can use the Show Source Code button).

In leaks coming just out of your own code the fact that MS symbols are available is neither here nor there. By default Deleaker doesn’t even trouble you with them in the call stack: the Show Full Stack checkbox is unchecked above. However if you need the extra detail then you can enable that option. Here is an unfreed memory allocation coming from a callback routine being invoked by the Windows API EnumWindows with full stack shown:

This time I’ll leak a Delphi object: a TList. If used as before the Allocations list shows that there is an unfreed allocation of a Delphi object.

However if we go to the Delphi Objects view we can see that the unfreed item is confirmed as a TList:

Of course if a more complex object is leaked, such as a component like a TButton, which itself creates a number of objects for its own purposes, then the list of unfreed objects becomes larger, but all these have the same call stack:

So far we’ve just looked at heap allocations, be they of basic memory or of object instances. One of the compelling features of Deleaker is that it also tracks various Windows resources not tracked by many other utilities (see list from earlier). Here, for example is a GDI handle leak:

const
  pattern: array[0..3] of cardinal = (10, 1, 1, 1);
var
  lb: TLogBrush;
  pen, oldpen: HPEN;
begin
  lb.lbStyle := BS_SOLID;
  lb.lbColor := RGB(255, 0, 0);
  pen := ExtCreatePen(
    PS_COSMETIC or PS_USERSTYLE, 1, lb, length(pattern), @pattern);
  if pen <> 0 then
    try
      oldpen := SelectObject(Canvas.Handle, pen);
      try
        Canvas.MoveTo(0, 0); Canvas.LineTo(ClientWidth, ClientHeight);
      finally
        SelectObject(Canvas.Handle, oldpen);
      End;
    finally
      // DeleteObject(pen); // Oops! We forgot to deallocate the handle!
    end;
end;

In this case the snapshot comparison shows up 3 unfreed allocations for a block of heap memory and two HPENs (pen handles) with the Leak type set to <All Leaks>. Note that the Leak type dropdown could be set to GDI objects to focus in on the HPENs.

Looking at the call stacks for each I can readily see the one I forced:

Incidentally the resource usage graph will track whatever resource type you wish. Here it is showing my test app consuming more and more HPENs as I keep pressing my button.

During my experimenting with Deleaker I have bumped into several bugs and shortcomings and have passed them all along to Artem from Softanics, who is usually quick to respond. One issue had already been fixed by the time I reported it and another was fixed quite promptly. A couple of shortcomings (Delphi mangled symbol names not demangled, and RTL/VCL source files not being automatically located) were also addressed in version 2020.27.0.0. This responsive experience was reassuring.

I like Deleaker – the IDE integration of the UI (especially the call stack entry support for double-clicking to see the source code) makes it much more straightforward to work with that FastMM4. But of course for all that convenience there is a price tag.

Whether you can justify spending out for the sake of convenience will be a personal decision, but if you can I think you will be happy you did. Additionally, if you fear you are leaking resource handles and are having trouble tracking down how this is happening then making use of this sort of tool will expedite the resolution of such issues.

1. OK, that hasn’t been updated in some years...

2. Yeah, this one is also somewhat stale, and required a cached Google page as the EDN page it was on is no longer available

Delphi and the WinRT API

2020-09-06T08:33:00.005-07:00

WinRT

The WinRT (Windows Runtime) API was introduced with Windows 8, although it’s fair to say that most of us have tried our level best to forget that particular Windows release and pretend it never happened. Anyway, Microsoft has been trying to convince us that new Windows APIs will be introduced in the WinRT API and what we normally refer to as the Windows API might well remain as it is. We’ll see how true that becomes. The WinRT API reference can be found documented here.

The nice thing about WinRT is that it is not another step on the .NET journey; indeed it is nothing to do with .NET whatsoever. WinRT is implemented as native code and it is made available to whatever language wishes to consume it by language projections. Microsoft offers a C# language projection to consume it in .NET but it also offers a native C++ language projection (C++/WinRT).

Each WinRT class implements various interfaces to offer up methods and properties to call. There may also be static methods (i.e. class methods) and factory methods through which you can create an instance of the class. The Microsoft language projections make all the methods implemented through all the supported interfaces directly available once you create an instance of a WinRT class.

WinRT metadata

Anyone else can make their own language projections by analysing the API metadata (which are available in .winmd files in the C:\Windows\System32\WinMetadata folder). Metadata files are rather like COM type libraries in that they describe all the WinRT classes and methods etc., but they are actually files that share the same format as Win32 executables and .NET assemblies: PE files. You can find detailed information on these files from Microsoft here. Microsoft’s C++ .winmd file parser is open-sourced and available on github.

WinRT and Delphi

Embarcadero folks started looking at how to consume the WinRT API back in 2011 and Thom Gerdes wrote a few posts on how got on. He talks about these metadata files in this old post available on the Wayback Machine.

So, do we have a Delphi language projection? Well, kinda... We have import units that pull in a good chunk of the WinRT API, but things aren’t quite as transparent and trivial to use as they are in C++and C#. However, depending on how persistent we are we can get results. Indeed there are some uses of the WinRT API in the Delphi / C++Builder RTL; it is used for Windows desktop notifications and for share contracts.

This post looks into how we might use the WinRT API directly to perform a simple task, namely to trigger a Windows notification message. This might seem an odd thing to do, given the RTL already covers this quite nicely in the TNotificationCenter class but it serves as a simple, visual example.

If you want you can also jump right to a sample from Marco Cantu that does the same thing, but that sample has more code in that somewhat camouflages the detail of what is required for the job. Marco’s code is on github and is mentioned a bit in the post A tale of 3 APIs: VCL integration with WinAPI, COM & ShellAPI, WinRT, which itself is a post summarising a webinar of the same title available for replay.

The WinRT import units were added to the RTL in RAD Studio 10 Seattle, so far as I can tell. You can find them in this subfolder of the installation folder: source\rtl\win\winrt. These were extended in 10.1 Berlin, and extended again in 10.3 Rio. In the 10.2 Tokyo timeframe Al Mannarino wrote a post on using the WinRT support.

WinRT and toast notifications in Delphi

To create a toast requires the toast content to be represented in XML. Something like this will do the trick:

var LToastXml := '<toast duration="short">' +
                   '<visual>' +
                     '<binding template="ToastText02">' +
                       '<text id="1">Windows 10 Notification</text>' +
                       '<text id="2">RAD Studio 10.4 Sydney Update 1</text>' +
                     '</binding>' +
                   '</visual>' +
                 '</toast>';

To pass this into a toast notification we need to load it into a Windows.Data.Xml.Dom.XmlDocument class. In the Winapi.DataRT.pas unit there is a representation of this class in the proxy class TXml_Dom_XmlDocument, which looks like this:

  // Windows.Data.Xml.Dom.XmlDocument
  // WinRT Only
  // WhiteListed
  // Implements: Windows.Data.Xml.Dom.IXmlDocument
  // Implements: Windows.Data.Xml.Dom.IXmlNode
  // Implements: Windows.Data.Xml.Dom.IXmlNodeSerializer
  // Implements: Windows.Data.Xml.Dom.IXmlNodeSelector
  // Implements: Windows.Data.Xml.Dom.IXmlDocumentIO
  // Implements: Windows.Data.Xml.Dom.IXmlDocumentIO2
  // Statics: "Windows.Data.Xml.Dom.IXmlDocumentStatics"
  // Instantiable: "Xml_Dom_IXmlDocument"
  TXml_Dom_XmlDocument = class(TWinRTGenericImportSI<Xml_Dom_IXmlDocumentStatics, Xml_Dom_IXmlDocument>)
  public
    // -> Xml_Dom_IXmlDocumentStatics
    class function LoadFromUriAsync(uri: IUriRuntimeClass): IAsyncOperation_1__Xml_Dom_IXmlDocument; overload; static; inline;
    class function LoadFromUriAsync(uri: IUriRuntimeClass;
      loadSettings: Xml_Dom_IXmlLoadSettings): IAsyncOperation_1__Xml_Dom_IXmlDocument; overload; static; inline;
    class function LoadFromFileAsync(&file: IStorageFile): IAsyncOperation_1__Xml_Dom_IXmlDocument; overload; static; inline;
    class function LoadFromFileAsync(&file: IStorageFile;
      loadSettings: Xml_Dom_IXmlLoadSettings): IAsyncOperation_1__Xml_Dom_IXmlDocument; overload; static; inline;
  end;

There is a static Create method available in a proxy class such as this, which is expected to create the corresponding WinRT class and return an interface reference to the instantiable class Xml_Dom_IXmlDocument.

Disappointingly, while this works with many WinRT proxy classes it does not work with this one. This is because the Xml_Dom_IXmlDocument interface, which is in the WinAPI.CommonTypes.pas unit rather than the Winapi.DataRT.pas unit has lost an important attribute. It should have an attribute defined like this:

[WinRTClassNameAttribute(SXml_Dom_XmlDocument)]

where SXml_Doc_XmlDocument is defined like this in Winapi.CommonNames.pas:

SXml_Dom_XmlDocument = 'Windows.Data.Xml.Dom.XmlDocument';

But alas all the interfaces in Winapi.CommonTypes seem to have lost attributes like this. As a consequence a function like this one does not work at runtime:

unit XMLHelper;

interface

uses
  Winapi.CommonTypes;

function GetXmlDocument: Xml_Dom_IXmlDocument;

implementation

uses
  Winapi.DataRT;

function GetXmlDocument: Xml_Dom_IXmlDocument;
begin
  // This fails because Xml_Dom_IXmlDocument in Winapi.CommonTypes does not have this attribute
  // as the other interfaces involved in XmlDocument from Winapi.DataRT do:
  // [WinRTClassNameAttribute(SXml_Dom_XmlDocument)]
  // Might work in 10.5...? If we cross our fingers...
  Result := TXml_Dom_XmlDocument.Create
end;

end.

It triggers an exception due to the lack of attribute, as the relevant code therefore does not know which WinRT class to instantiate.

By the way, I have made enquiries and I am reliably informed that this issue is known within Embarcadero and is recorded in an internal JIRA.

All that notwithstanding, it turns out that we can do what that proxy class wanted to do for ourselves, manually filling in the missing information. Here’s an alternative implementation of the same function:

unit XMLHelper;

interface

uses
  Winapi.CommonTypes;

function GetXmlDocument: Xml_Dom_IXmlDocument;

implementation

uses
  System.Win.WinRT,
  Winapi.WinRT,
  Winapi.CommonNames;

function GetXmlDocument: Xml_Dom_IXmlDocument;
begin
  var LWinRTClassName := TWindowsString.Create(SXml_Dom_XmlDocument);
  var LWinRTClassNameHString: HString := LWinRTClassName;
  var LXmlDocumentInsp := TWinRTImportHelper.CreateInstance(TypeInfo(Xml_Dom_IXmlDocument), LWinRTClassNameHString);
  Result := LXmlDocumentInsp as Xml_Dom_IXmlDocument;
end;

end.

This code takes the aforementioned WinRT class name and creates a HSTRING version of it. HSTRING is a string handle and is the string type of choice in the WinRT API (documentation available here).

Some RTL helper can take the type information for the target instantiable interface along with the WinRT class name and do the ‘magic’ required to create the WinRT object instance and return us an IInspectable interface reference to it. This interface reference will gladly offer up the sought Xml_Dom_IXmlDocument interface when asked.

If we wanted to do the WinRT object instantiation manually, using Windows native routines then we can swap out the RTL helper for a WinRT API primitive RoActivateInstance. As you can see it actually slightly reduces the required typing:

function GetXmlDocument: Xml_Dom_IXmlDocument;
begin
  var LWinRTClassName := TWindowsString.Create(SXml_Dom_XmlDocument);
  var LXmlDocumentInsp: IInspectable;
  RoActivateInstance(LWinRTClassName, LXmlDocumentInsp);
  Result := LXmlDocumentInsp as Xml_Dom_IXmlDocument;
end;

OK, so now we have a couple of options for instantiating a WinRT XML document and the helper can be called:

var LXmlDocument := GetXmlDocument;

In addition to the XML defining the toast notification we also need to use the ToastNotificationManager to create a ToastNotifier object via which we will raise the toast notification. We maybe want to react to the user clicking the toast notification so we might want an event handler involved as well.

uses
  System.Hash,
  System.Win.WinRT,
  Winapi.UI.Notifications,
...
const
  AppId = 'Blong.WinRT.';

function GetAppUserModelID: string;
begin
  Result := AppID + THashBobJenkins.GetHashString(ParamStr(0))
end;
...
  var LWSAppID := TWindowsString.Create(GetAppUserModelID);
  var LToastNotifier := TToastNotificationManager.Statics.CreateToastNotifier(LWSAppID);
  DoToast(LXmlDocument, LToastXml, LToastNotifier, OnToastActivated);
...
procedure TfrmMain.OnToastActivated(Sender: IToastNotification; const Args: IInspectable);
begin
  ShowMessage('Hello from Delphi!');
end;

That sets us up passing everything into the DoToast routine. It looks like this:

procedure DoToast(const XmlDoc: Xml_Dom_IXmlDocument; const ToastXML: string;
  const ToastNotifier: IToastNotifier; ActivatedEventHandler: TToastActivatedEvent);
begin
  (XmlDoc as Xml_Dom_IXmlDocumentIO).LoadXml(TWindowsString.Create(ToastXml));
  // If we want to view the XML we can do this:
  //var LWSXML := (XmlDoc as Xml_Dom_IXmlNodeSerializer).GetXml;
  //var LXML := TWindowsString.HStringToString(LWSXML);
  var LToastNotification := TToastNotification.Factory.CreateToastNotification(XmlDoc);
  var LDelegateActivated := TToastActivated.Create(ActivatedEventHandler);
  LToastNotification.add_Activated(LDelegateActivated);
  ToastNotifier.Show(LToastNotification);
end;

The first statement loads in the XML to the XML document. You’ll notice that since we are working from an interface reference, then in order to call other methods in the WinRT class we have to use the relevant interface reference type that defines the methods we wish to use. The XML document is then passed along while creating a ToastNotification object.

The passed in event handler method is handed to a new delegate object that is given to the ToastNotification as a handler for the Activated event. Finally the ToastNotifier is used to display the notification.

The only thing left not filled in from what we’ve seen so far is the delegate class, which looks like this:

type
  TToastActivatedEvent = procedure(Sender: IToastNotification; const Args: IInspectable) of object;

  // Here we have 2 interfaces implemented for the delegate
  TToastActivated = class(TInspectableObject,
    TypedEventHandler_2__IToastNotification__IInspectable,
    TypedEventHandler_2__IToastNotification__IInspectable_Delegate_Base)
  private
    FToastActivated: TToastActivatedEvent;
  public
    constructor Create(EventHandler: TToastActivatedEvent);
    procedure Invoke(Sender: IToastNotification; Args: IInspectable); safecall;
  end;
...
constructor TToastActivated.Create(EventHandler: TToastActivatedEvent);
begin
  inherited Create;
  FToastActivated := EventHandler;
end;

procedure TToastActivated.Invoke(Sender: IToastNotification; Args: IInspectable);
begin
  if Assigned(FToastActivated) then
    FToastActivated(Sender, Args)
end;

Notice the dual interfaces implemented in this delegate class. This is 'a thing' that you have to do with Delphi interfaces that represent WinRT instantiated template interface types. The interface type that describes itself as the base type has the IID that you need to be bringing in for the delegate to work, but the other type (inherited from the base one) defines the method(s) you need to implement...

If you run this sort of code you do indeed get a desktop notification sweeping in from the bottom right edge of the screen:

Hmm, but something is missing….. The general look of these notifications is that, at the very least, they show the application icon. Where is it?

Well, there is a requirement that must be met in order to get this to appear as discussed in this – you need to create a shortcut (as in a .lnk file). This shortcut file must have been set up with an Application User Model ID (more information here) assigned, which is the app-specific hashed string returned by the GetAppKey function above. This is all illustrated with some C++ code in this Microsoft page, How to enable desktop toast notifications through an AppUserModelID. If we implement a routine to ensure a suitable shortcut exists (code below), called on app start, then the notification does manage to pick up the app icon.

uses
  System.SysUtils,
  System.Hash,
  Winapi.Windows,
  Winapi.ShlObj,
  Winapi.ActiveX,
  Winapi.KnownFolders,
  Winapi.PropKey,
  Winapi.PropSys;

const
  AppId = 'Blong.WinRT.';

function GetAppUserModelID: string;
begin
  Result := AppID + THashBobJenkins.GetHashString(ParamStr(0))
end;

function CreateShortcut: Boolean;
var
  Path: PChar;
  LBufferPath: array [0..MAX_PATH] of Char;
  LShellLink: IShellLink;
  LAppIdPropVar: TPropVariant;
  LFindData: TWin32FindData;
begin
  Result := False;
  if Succeeded(SHGetKnownFolderPath(FOLDERID_Programs, 0, 0, Path)) then
  begin
    var ShortcutPath := string(Path) + '\' + ChangeFileExt(ExtractFileName(ParamStr(0)), '.lnk');
    if FileExists(ShortcutPath) and
       Succeeded(CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_INPROC_SERVER, IShellLink, LShellLink)) and
       Succeeded((LShellLink as IPersistFile).Load(PChar(ShortcutPath), 0)) and
       Succeeded(LShellLink.GetPath(LBufferPath, MAX_PATH, LFindData, 0)) and
       (LBufferPath = ParamStr(0)) then
        Result := True
    else
      if Succeeded(CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_INPROC_SERVER, IShellLink, LShellLink)) then
      begin
        LShellLink.SetPath(PChar(ParamStr(0)));
        LShellLink.SetWorkingDirectory(PChar(ExtractFilePath(ParamStr(0))));
        var LPropertyStore := LShellLink as IPropertyStore;
        ZeroMemory(@LAppIdPropVar, SizeOf(LAppIdPropVar));
        if Succeeded(InitPropVariantFromString(PChar(GetAppUserModelID), LAppIdPropVar)) then
          try
            if Succeeded(LPropertyStore.SetValue(PKEY_AppUserModel_ID, LAppIdPropVar)) and
               Succeeded(LPropertyStore.Commit) then
            begin
              var LSaveLink := True;
              if FileExists(ShortcutPath) then
                LSaveLink := System.SysUtils.DeleteFile(ShortcutPath);
              if LSaveLink then
                Result := Succeeded((LShellLink as IPersistFile).Save(PChar(ShortcutPath), True));
            end;
          finally
            PropVariantClear(LAppIdPropVar);
          end;
      end;
  end;
end;

Note that because the RTL supports Windows 10 desktop notifications (aka toast notifications), then it does all this stuff as well (look in System.Win.Notification.pas). The GetAppUserModelID function is much the same as TNotificationCenterWinRT.GetAppNotificationKey and CreateShortcut is very similar to TNotificationCenterWinRT.CreateShortcut.

I am hoping to come back to this general subject soon to look at doing more with WinRT, but this is time-dependent and I have a few other things to write about first. But hopefully this has given a general idea of how you can make use of WinRT API from a Delphi application.

25 Delphi Tips for 25 Years of Delphi

2020-02-14T06:21:00.000-08:00

It seems funny to think Delphi is 25 years old, and yet sure enough the celebrations are ongoing for the 25th Anniversary of its unveiling on 14th February 1995.

As it happens I've been part of the Delphi world for around 26 years now, as I used to work at Borland and was involved with testing and experimenting with and working with the pre-release versions.

What can I say other than Happy Birthday, Delphi? You've been a good friend to me over this last quarter of a century and I've been happy to be part of your world.

Some number of posts ago I wrote up 10 Tips for Delphi Users. When I checked I was horrified to find this was 7 years ago! (My, my, how time flies when you're having fun...) Anyway, I thought I'd take that list and build upon it, expanding it up to 25 tips for Delphi users, which is what we have here. So without further ado let's get straight into the list.

1) Running apps from network shares

Sometimes people like to put executables on network drives and run them from there – it allows potentially many users to launch a single executable. However if the program is running and the network connection breaks there is a more than reasonable chance that the program will crash is a quite ghastly manner, understandably enough.

Given users are at liberty to launch there apps like this it may be an idea to make habit a simple step that alleviates the aforementioned crash scenario. You can have the Delphi linker set a special bit in a 32-bit Windows executable header to instruct Windows that in the event of being launched off a network drive the executable should first be copied to the local paging file and then be launched from there. This flag was introduced in Windows NT 4.0 and described in this old Microsoft Systems Journal article (recorded for posterity in the Internet Wayback machine now Microsoft has droped all its old MSJ content) by Matt Pietrek from 1996.

This is quite straightforward. You can do this with a compiler directive in the project file or you can change the linker setting (at least in recent versions of Delphi).

To change the project file, you must make sure that Windows (or Winapi.Windows, if you prefer) is in the uses clause and then add in this compiler directive after the uses clause:

{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP}

To set the linker option directly, open the project options dialog (Ctrl+Shift+F11), go to the Linking options, ensure you are looking at options for a 32-bit build configuration and then give a value of 2048 to the Set extra PE Header flags option. This is passed along to the compiler as the --peflags:2048 command-line switch and does the same thing.

You could work out the value to pass along yourself by looking in Winapi.Windows.pas and seeing that IMAGE_FILE_NET_RUN_FROM_SWAP has a value of $800, which in decimal in 2048.

To clarify some points that have come up in comments, this linker setting does not affect operation of the program in terms of how .ini files shipped alongside the .exe get loaded or what the value is returned by Application.ExeName.

2) Getting the type of an object when you only have its address

If we just have the address of an object, say in a pointer, how do we get its type? Well, we simply cast the address to a TObject and call its ClassName method. You can do the exercise in a Watch expression (Ctrl+F5) with the address directly, so long as you remember to allow side effects and function calls when adding it.

For bonus points you can identify the type in the CPU window’s memory pane rather than the Watch List window. Invoke the CPU window with Ctrl+Alt+C and pay attention just to the memory pane at the bottom left. In recent IDEs you can also just invoke a solitary memory pane using View, Debug Windows, CPU Windows, Memory 1 (Ctrl+Alt+E) or Memory 2 (Ctrl+Alt+2) or Memory 3 (Ctrl+Alt+3) or Memory 4 (Ctrl+Alt+4).

In the memory pane, firstly have the memory displayed in 8 byte chunks of data by right-clicking and choosing Display As, DWords.

Now right-click again and choose Go to address… (Ctrl+G) and enter a suitable expression based on the pointer value or object address. For this example let's say the object address is $27E2C20. This is an object reference – the address of an object’s instance data. So if we de-reference the pointer we’ll be at the start of the instance data. But the address of the class name string is a little way into the instance data, a distance given by the constant vmtClassName, so the required expression will be:

PInteger($27E2C20)^+vmtClassName

As mentioned, we’re now looking at the address of the class name, which is stored as a short string. To follow (de-reference) this address, right-click on it and choose Follow, Offset to Data or press Ctrl+D. This takes us to the information we seek: TFoo.

If you wish you can change the display back to bytes (right click, Display As, Bytes) and then the short string is more obvious – you can see the length prefix byte for the 4 character string is indeed 4.

3) Inspecting an item in a TList

The old TList class is still a useful beast, even if in many cases we should be using the newer generic TList. TList is useful when the list will potentially contain objects of different types, with suitable backup code that knows to check the type and cast appropriately.

In the debugger, if you want to inspect an item in a TList things can be a bit of a challenge. When you inspect your TList variable (Alt+F5) you get a debug inspector that hints at the items contained therein in its FList field.

If you right-click on FList and choose Descend (or Ctrl+D, to make this inspector inspect that field) or Inspect (or Ctrl+I, to launch a new inspector showing that field) you’ll see the addresses of the items in the list.

These aren’t much use though; being as this is the type-unsafe general TList these values are just pointers. Indeed if you look in the definition of TList you’ll see this FList field is a TPointerList – an array of pointers.

So what do we do to inspect the item underlying a pointer variable? Well, we cast the pointer to the right type and inspect that. To work out what type that is, as Tip 2 above suggests, we cast the address shown in the inspector to a TObject and call its ClassName method.

This tells you the type. Now you can bring up an inspector for the currently unhelpful pointer by selecting it in the inspector and pressing Ctrl+I, or maybe just double-clicking it.

Then you can apply the typecast by right-clicking and choosing Type Cast... or pressing Ctrl+T, and entering the target type of TFoo (in this example’s case). And then you have what you sought:

4) Loop failure iteration detection

You’ve doubtless encountered this scenario while debugging. There’s an issue in a loop. The loop executes *loads* of times but you need to look into the problem so you need to know how many times round the loop the problem occurs. Stepping through the loop, or using a breakpoint and pressing F9 or clicking on the last line of the loop and pressing F4, counting in your head – all such options are mind-numbing and hugely prone to losing count or messing up in some regard, so how about letting the system work it out for you?

Place a breakpoint at the end of the loop with a massive pass count – say 1000000. Now run the app and make the problem occur. Now look in the breakpoints window and check the current pass count – it will tell you how many times the breakpoint has been passed without actually breaking.

Once you know how many iterations it has been through, modify the properties of the breakpoint and set the pass count to that value. Restart the program and the when the breakpoint triggers the error will occur on the next iteration of the loop. Nice!

5) Breakpoint logging

Breakpoints had their advanced properties added many, many versions ago. You can use advanced breakpoint properties for a variety of cunning debugging scenarios, but a simple usage is to enable cheap logging without writing additional code statements.

Wherever you want to log some information, add a breakpoint and bring up the breakpoint properties. Press the Advanced button, set the breakpoint to not actually break and then specify the log message. For bonus points you can also choose to have an expression evaluated and (optionally) logged at the same time.

This log information will be added to the Event Log window during your debug session in the same way that OutputDebugString messages are, but with the benefit of not having written any code. If you have the IDE set to save your project desktop then the breakpoints will be saved when you close the project and reappear next time you open it.

6) Leaving RTL assembler code

When stepping through code with Debug DCUs enabled you often inadvertently end up in RTL assembly code. In most instances Shift+F8 (Run, Run Until Return) will run the rest of the code through and take you back to where you were so you can try F7 again.

Shift+F8 doesn’t always work. For example if you use F7 on a call to a dynamic method you end up in the System unit’s _CallDynaInst routine. This doesn’t exit in the normal manner, but by jumping off to the located method address stored in the ESI register.

The best way forward here is to click on the JMP ESI line, press F4 to run up to that point and then press F7 – that will take you into the dynamic method that was called.

7) Find declaration while debugging

Seasoned Delphi developers know that you can locate the definition of a symbol by right-clicking it in the editor and choosing Find Declaration. Rather annoyingly there is no shortcut listed next to it, but it is commonly known that if you hold down Ctrl and wave your mouse around the editor, anything that the IDE thinks it can locate the definition/declaration of turns into a hyperlink – this Ctrl+click hyperlink feature is Code Browsing and links to the Code Browsing History keystrokes of Alt+← and Alt+→ that allow you to go back and forth though the links you’ve clicked.

The problem with Ctrl+click is that it doesn’t work in a debug session. Many times it would be handy to find the definition of a symbol in a debug session but Ctrl+click just doesn’t cut it. Fortunately, however, Alt+↑ *does* work in a debug session (yay!)… (or at least should do – it generally does for me). Why Alt+↑ isn’t listed in the editor context menu against Find Declaration baffles me. It’s a very little-known but useful shortcut.

8) Non-destructively locally disable a compiler option

Often-times a build configuration has range-checking enabled to ensure problems show up when they occur as tangible issues rather than vague Access Violations through memory overwrites way down the line during an execution. That said, it can still be important to selectively turn off range-checking for specific small sections of code that are valid, but will flag up range-check errors thanks to, say, the pointer types involved.

Clearly you can turn range-checking (or overflow-checking or whatever) off and on using local compiler directives, as in:

{$R-}
//code that requires range-checking off
{$R+}

but what about if you then build the code with a build configuration that has range-checking globally disabled? This use of compiler directives means the file in question will have range-checking *enabled* from that point onwards, despite the intent being to have it disabled throughout the project.

This is where this tip comes in. You can selectively change a compiler option using code like this, where this example disables range-checking if it was enabled, and then ensures it gets enabled again if appropriate:

{$IFOPT R+}
  {$DEFINE RANGE_CHECKING_WAS_ON}
  {$R-}
{$ENDIF}
//code that requires range-checking to be disabled
{$IFDEF RANGE_CHECKING_WAS_ON}
  {$R+}
{$ENDIF}

Here we define a conditional symbol if we toggle range-checking off, and we use that symbol’s existence to decide whether to enable range-checking later.

9) Building a Delphi project at the command-line

For quite a few versions now, Delphi has used the MSBuild format for its project files and project group files. This means you can use MSBuild to build your projects and project groups, using appropriate MSBuild command-lines to pass in options or specify build targets (the targets include clean, make and build). So if you have a project Foo.dproj and you want to clean up the previously produced binaries (compiled units and executable output) and then build it in Release and Debug configurations for Win32 and Win64 you could run these commands in a RAD Studio Command Prompt:

msbuild -t:clean -p:Config=Debug -p:Platform=Win32 Foo.dproj
msbuild -t:build -p:Config=Debug -p:Platform=Win32 Foo.dproj
msbuild -t:clean -p:Config=Release -p:Platform=Win32 Foo.dproj
msbuild -t:build -p:Config=Release -p:Platform=Win32 Foo.dproj
msbuild -t:clean -p:Config=Debug -p:Platform=Win64 Foo.dproj
msbuild -t:build -p:Config=Debug -p:Platform=Win64 Foo.dproj
msbuild -t:clean -p:Config=Release -p:Platform=Win64 Foo.dproj
msbuild -t:build -p:Config=Release -p:Platform=Win64 Foo.dproj

See also my post on building, installing and launching an Android app from the command line for additional Android-specific details.

10) Formatting entire projects

Recent versions of Delphi have offered pretty printing, as it used to be called, or source formatting as the process is now described. It’s invoked by Edit, Format Source (or Ctrl+D) and can be fully customised in the Tools, Options dialog. Your custom settings can be saved into formatter profile files.

It’s less well known that the formatter is also available through a command-line tool. You can use this to run it across all files in a project directory tree.

Assuming you’ve saved your custom IDE formatter options in a formatter profile called Formatter_MyProfile.config then you start by running up a RAD Studio Command Prompt. Now issue some commands along these lines and it’s all done for you:

set CONFIG="Formatter_MyProfile.config"
set LOG=Format.log
del %LOG%
formatter -delphi -config %CONFIG% -r –d . > %LOG%

11) Case toggle

If you are not a touch typist and occasionally type a whole bunch of code in with CAPS LOCK on you should become familiar with the keystroke that toggles the case of a marked block: Ctrl+O, U.

12) Disable Error Insight to lower blood pressure

I’ve said this before in talks and in writing. I’m very happy to say it again. Please, *please*, don’t suffer the shame of Error Insight and its hopeless and hapless efforts in working out what might compile and what might not. Yes, it gets the simple ones right. But any vaguely interesting project that you work within is pretty much guaranteed to be besmirched with lots of red squiggles over perfectly good code and perfectly locatable units in the uses clause all within a fully compilable code base. The fact that Error Insight continues to be enabled by default, despite the growing problem of its inaccurate problem detection is really rather surprising. I urge you to disable Error Insight by going to Tools, Options… and then locating the Code Insight options within the User Interface and then Editor nodes on the tree of categories on the left.

Yes, yes, there are reasons why it gets it wrong – it’s not using the exact same parsing code as the compiler does and doesn’t know all the things that the compiler does. But this has been the case for years, and it still offends my eyes with its tenacity of squiggling over code that has just compiled cleanly.

Ease your annoyance at Error Insight by turning it off. Then pick any of the plethora of Error Insight bugs logged on the Quality Portal and vote for it/them.

One day, maybe one day soon, Error Insight will function again and will a useful programming ally. But until then it deserves no place in any self-respecting programmer's IDE.

Seriously though, on very large projects, disabling anything that executes and isn’t useful/productive is a benefit. When working with clients’ large projects I disable Error Insight, Tooltip Help Insight and automatic Code Completion.

13) IDE Insight shorter shortcut

A great IDE navigation feature called IDE Insight was introduced in RAD Studio 2010. It was inspired by the ability to search for things in Windows by pressing the Start button and simply typing what you wanted.

In the IDE there is similar functionality to find any window, option, preference, file (recent or current), project (recent or current), form, property, menu command, new item, desktop, code template or component (if the form designer is active). IDE Insight is commonly invoked by Ctrl+. (Ctrl and period), indeed that keystroke was introduced in that feature introduction post linked above. Note that rather than popping up in a separate window as it did when introduced, IDE Insight now manifests as a drop down list from an edit field embedded in the RAD Studio caption bar.

However as a means of saving 50% of the keys required to trigger IDE Insight I'd like to ensure you know that F6 does the same thing - it also fires IDE Insight. So there we have a productivity improvement in accessing a productivity improvement :)

14) Synchronising declaration and implementation

When RAD Studio 10 Seattle brought some of the Castalia features on-board into the IDE I missed a really useful one for a couple of years. It is common to implement a routine, e.g. declaring a method with its parameter list in a class definition and implementing it in the implementation section of the unit. Furthermore it is not uncommon to realise you need slightly different parameters in the parameter list.

Having 2 parameter lists to edit is a bit of a bind. Or at least it used to be! This is what the new(-ish) feature called Sync Prototypes is for. As soon as you update one of the routine signatures (or its prototype) then you simply invoke Sync prototypes with Ctrl+Shift+Alt+P and the other one will be updated to match. It doesn't matter whether you edit the one in the interface section or the one in the implementation section - Ctrl+Shift+Alt+P will update the other.

15) Hiding non-visual components

One drawback of Delphi's form designer is that both visual components and non-visual components are placed on the form's UI area. The problem is that as you start using more and more non-visual components in the designer (and don't elect to partition them off onto non-visual data modules) it becomes harder and harder to see the underlying UI of the form.

At last we have a means to mitigate this glaring issue. Another feature added by RAD Studio 10 Seattle was the option to Hide Non-Visual Components, which can be triggered on the form designer using the Ctrl+H shortcut. You can also find the option in the menu and context menu, on one of the toolbars and, for good measure, in the Tools, Options... dialog - see the docwiki page for details.

16) Working out from where a message box was called

The following scenario might be a rarity for you, but for me it happens surprisingly frequently.

While debugging an application a message box pops up and I need to know its provenance - where in the code was it invoked from? Searching the code base for the message string might work, but the message may be dynamically constructed so it's certainly not a given that would work. I tend to use the following technique to help me get to the point of origin.

First of all pause the application with the Run, Program Pause menu item or equivalent toolbutton.

At this point you might think the call stack would help out but alas not. As we see here the call stack is barren:

However the crucial piece of information here is that the debugger is looking at the wrong thread in terms of what we are interested in. If you switch to the Threads window (Ctrl+Alt+T) you can see that the active thread in terms of what the debugger is looking at is the last one in the list.

This thread is of no interest to us. We need the main thread, the UI thread, which is the first in the list. Double-click on that first thread and the call stack is immediately replete with lots of entries:

If you scan down from the top you will start to see entries suspiciously looking related to message box work and eventually (and hopefully) you come to entries related to your code. In the case below the first entry in "user code" (my code) is TForm2.Five. If you double-click that entry you will be taken to the relevant code, with the editor highlighting the point we will return to (after the invocation) in red (by default), Sure enough the red line is just after my call to ShowMessage.

17) Listing out DLL exports

When you need to find what routines are exported from a DLL you can use the TDump.exe utility, or alternatively TDump64.exe. Either work fine in producing a lot of information on an executable file, .exe or .dll. To just list out the PE exports use the -ee command line switch, e.g.

If you are working with Android apps and want to get the exported symbols from a .so library file then TDump et al fall short. However you will already have the NDK installed with comes with a lot of Linux-y utilities that can do this sort of thing.

Assuming you set an environment variable NDK_ROOT to point at your Android NDK folder and then set another variable NDK_TOOLS to be the subfolder of NDK_ROOT's value containing all the pre-built tools that work on Android binaries then we can run some vaguely concise commands.

Incidentally, once in a command prompt these commands (with path modified to suit your installation) will set up the variables as described:

set NDK_ROOT=%PUBLIC%\Documents\Embarcadero\Studio\20.0\PlatformSDKs\android-ndk-r17b
set NDK_TOOLS=%NDK_ROOT%\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin

nm is a utility to list file symbols, objdump is a utility to dump information from various types of object (binary) files and readelf is a utility to dump information about ELF files (ELF being the format for executables in Unix-land, the Executable and Linkable Format). To invoke these utilities and get the exported symbols from a .so file we can use any of these commands:

%NDK_TOOLS%\arm-linux-androideabi-nm.exe -gD libandroid.so
%NDK_TOOLS%\arm-linux-androideabi-objdump.exe -T libAndroid.so
%NDK_TOOLS%\arm-linux-androideabi-readelf.exe -W --dyn-syms libAndroid.so

Here is some sample output:

18) Save additional global desktops for better working arrangements

RAD Studio ships with 4 Desktops to work with, with one set to become active in a debug session (Debug Layout). Normal editing starts in the Default Layout and those who yearn for days gone by can choose Classic Undocked to make the IDE look a little bit like Delphi 7.

The Startup Layout is a nice option to switch to as a convenient way to undock all the tool windows taking up most of the editor space: Object Inspector, Structure, Project Manager and Tool Palette. With those shrunk down to the edges of the main window you can see much more of your code lines.

This tip is really just to make sure you know you can lay out the IDE windows any way you like and save new Desktops. For example for developing you might want to undock the Object Inspector, Structure pane, Project Manager and Tool Palette, position them on your second monitor, thereby having a near full-screen editor but still having the other tool windows available. You might also want the Message window (View, Tool Windows, Messages or Shift+Alt+M) visible but shrunk back to the bottom of the editor.

Whatever your preferred window layout you can organise things as you like and then save it as a new Desktop to select as and when you choose:

19) Better editor font

RAD Studio still installs with Courier New as its default editor font.

That's a bit "old hat" these days so here are a few options that don't cost anything. Choose your favourite!

Since Windows Vista we have a nicer monospaced IDE-friendly font called Consolas built right into Windows:

For a longstanding programmer's font you could try Source Code Pro:

If you want something more tailored to modern IDEs then you could try Hack:

Alternatively a new player in the field is JetBrains Mono:

20) Alternate IDE profiles

Sometimes I feel the IDE is way too big and full of stuff I have no interest in. But I don't want to disable anything just in case. Under these circumstances we do have the option to set up a whole new IDE profile within the registry that we can use to play and experiment with cutting down the 'bloat' in the IDE, and also to set various different default options that we might want to try.

The IDE supports various command-line switches as documented in the docwiki. When you run RAD Studio no command-line switches are used. If you have the full RAD Studio then your Start menu group for RAD Studio will contain a Delphi shortcut and a C++Builder shortcut. These pass a personality command-line switch, either -pDelphi or -pCBuilder, when starting bds.exe.

Another command-line switch that we can use to specify a registry profile is -r. If I set up a shortcut to start bds.exe with a -r TinyBDS command-line switch (or run it from a command prompt with that switch) then it will not use the default HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0 registry path but instead will use HKEY_CURRENT_USER\Software\Embarcadero\TinyBDS\20.0, creating the new profile with a full set of defaults if necessary.
Now, to remove 'bloat' we pick and choose IDE packages that we feel aren't giving us what we want and disable them. How do we do that? Well the IDE packages are all listed in this registry key (for my sample TinyBDS registry profile): HKEY_CURRENT_USER\Software\Embarcadero\TinyBDS\20.0\Known IDE Packages. There is also a subkey for the Delphi personality and a subkey for the C++Builder personality.

To disable a package we either move the entry from this Known IDE Packages key and move it into the sibling Disabled IDE Packages key, or we edit the package description and prefix it with an underscore. Either way it's a bit fiddly, so why don't we find a tool to help us?

In Code Central there is just such a tool, uploaded by the ever helpful Ray Vecchio. Download this IDE ad-in package source code, start up your IDE in the experimental registry profile, open the package, compile and install it.

Now make sure you really started the IDE to use the new, experimental, expendable registry profile before you go and mess up your normal, default installation profile. Don't say I didn't warn you!

To use the add-in choose Tools, Options... and select Third Party, Package Editor, Packages. Now you can go to the tabs labelled Known IDE Packages\Delphi and Known IDE Packages and check all the packages you feel like disabling. When you are done press Save, exit the IDE and restart it against the same registry profile. If you've been too gung go the IDE might not start, in which case you'll need to try again with another registry profile.

While testing this out to slim down my current Win32/64-targeting and VCL-only IDE I disabled these packages in Known IDE Packages\Delphi:

delphifmxmobile260.bpl
delphifmxide260.bpl
delphierrorinsite260.bpl - this one goes back to Tip 12 (see above)
delphiandroidservices260.bpl

and these in Known Packages:

gdbdebugcore260.bpl
gdbdebugide260.bpl
ios32debugide260.bpl
ios64debugide260.bpl
tgide260.bpl
DeviceManager260.bpl
GuidedTour260.bpl
MultiDevicePreview260.bpl
LivePreview260.bpl
MirrorHub260.bpl
android64debugide260.bpl
androiddebugide260.bpl
delphiandroid260.bpl

It may be that I can also remove some of the profile and SDK related packages, I haven't tried yet. What I do know is that when I start Delphi now (bds.exe -pDelphi -r TinyBDS) it feels much quicker :)

21) Switch to FastMM4 for additional features

Long ago when Delphi 2006 came out the original Delphi memory manager was retired and replaced with the open source FastMM, written by Pierre Le Riche. Well, to be precise it was replaced with a cut down version of FastMM, the current version of which is FastMM4.

FastMM improves upon the abilities of the original Delphi memory manager in typical application scenarios does a great job. That is, assuming you are looking at a Win32 or Win64 application - FastMM is used for Win32 and Win64. For other platforms the underlying POSIX memory manager is used.

If it turns out your application has specific requirements that make FastMM not behave as well as you'd like there are other memory managers out there that target specific usage scenarios; go and search them out.

One of the benefits offered by FastMM is it includes the ability to spot when your application has leaked memory and can tell you on exit, and this is enabled by assigning True to the ReportMemoryLeaksOnShutdown System unit variable. Once you've done this (as the first statement in your project file code block) any leaks get reported thus:

This is good inasmuch as you know you have one or more memory leaks, but then leaves you high and dry. Where are they?!

Fortunately the full version of FastMM improves things greatly on this score. If you download the full FastMM4 and add the FastMM4 unit as the first unit used in your project file and re-run you now get this message:

Open FastMM4's FastMM4Options.inc file and locate the comment that says Option Grouping you can see where various symbols can be defined for Release and for Debug builds. In the Debug build section ensure that FullDebugMode and EnableMemoryLeakReporting are defined. Now make sure the FastMM_FullDebugMode.dll file is available in the folder your Debug build executable is created into and re-run. On exit it now says:

If you locate that specified file and open it you will see similar information to what was on the message box:

If you scroll further up the file you will see more detailed information about each leak, for example the string list leak is announced like this, complete with a call stack:

This now arms us with much more information that we had with the default version of FastMM used by Delphi so we can head directly to the source of the leak and fix it.
The full FastMM also offers options for detecting heap corruption, interface misuse and more besides. Do yourself a favour and start using it if you haven't already done so.

Note that what we are looking at here are handy benefits of the full version of the default memory manager. There are other leak detection tools and utilities that offer more than we get with FastMM4. I hope to look at one or two of them in the near future, but in the mean time reap the rewards of FastMM4.

Useful links in the docwiki include:

22) Rebuild RTL source

If you need to make a tweak to a VCL or FMX file, this is feasible and (in some senses) reasonably common. You either copy that file, or maybe the whole VCL or FMX source directory (C:\Program Files (x86)\Embarcadero\Studio\20.0\source\vcl or C:\Program Files (x86)\Embarcadero\Studio\20.0\source\fmx) to somewhere else, add that location to your project source path, make your tweaks and rebuild.

Rebuilding the RTL is slightly trickier due to the System.pas unit being something of a 'special case'. If you want to rebuild the Win32 or Win64 RTL, or even the OSX RTL then there is a build batch file supplied in the RAD Studio installation that can assist.

As before copy the RTL folder, C:\Program Files (x86)\Embarcadero\Studio\20.0\source\rtl, to somewhere else and make your tweaks. Then start a RAD Studio Command Prompt, use CD to navigate to that RTL copy folder and run buildrtl.bat passing it a debug or a release command line parameter. If you want to build the RTL in a regular command prompt rather than a RAD Studio command prompt then modify where the batch file goes looking for RSVars.bat, which it calls if it can find it, to set the same environment variables up.

I'll leave you there to pore over the contents of the batch file, which seems to be a little out of date now we have support for rather more platforms than Win32, Win64 and OSX, but it may be of use.

23) Rebuild RTL Android Java source

Deeper down that the Pascal RTL source files, on occasion intrepid Android developers need to tweak the Java files that underlie RAD Studio's FireMonkey foundations. Sometimes a bug needs fixing, or an extension needs to be added to the raw GireMonkey Android activity to achieve a certain goal.

Rebuilding those Java files can be done, but it's not necessarily obvious how to do it. This is why I went through the whole process recently in a dedicated post: Rebuilding the Delphi & C++Builder Android Java files. If you ever need to change the Java files you now know where to go for instructions on how to do it.

24) RTL Easter Eggs

When you have had a hard day's programming and are looking for a little light relief, try perusing through the RTL, VCL and FMX source code seeing what you can find. As the ex-Borland R&D wizard Danny Thorpe used to say: "Use The Source, Luke". Sometimes you'll learn of new features and functions. Other times you might happen upon something that prompts a wry smile. Here are a couple of examples.

Have you encountered the EProgrammerNotFound exception class type, defined in System.SysUtils? I think I will be using that from time to time in the future.

Also, the TDeviceClass enumerated type in System.Devices.pas, which as well as sensible members such as Phone, Tablet and Watch also has some more interesting members: Elf (no relation to the ELF Unix executable file format), Dwarf and Wizard as explained in the docwiki:

25) IDE Easter Egg

Invoke the About box with Help, About..., then hold down Alt whilst typing TEAM. This produces a scrolling team list of members of the development team. You can also hold Alt+KUDOS for a list of those who have contributed to the product:

Double-click on any name in the development team list and you get some team pictures:

If you hold Alt and type GUNGLA you get to see Tequila Joe Monkey on a surfboard:

And why is this? Well, who knows? But a little monkey business is a good way to wrap this post up.

The Enter key and the OnKeyDown/OnKeyUp events on Android

2020-02-12T01:55:00.000-08:00

A problem surfaced on Stack Overflow recently from a Delphi developer, Tom Byrnes, who discovered that on Android, the Enter (or Return) key no longer triggers the OnKeyDown and OnKeyUp events. This was unfortunate as Tom wanted to code to run in (one of) those handlers.

The problem had been reported as RSP-27496 but alas it had been closed at the time Tom was hunting for a solution (to my mind closed wrongly).

What to do?

Well, after some valiant fighting with the problem accompanied with the inevitable wailing and gnashing of teeth, Tom found a workaround of sorts. Setting the TEdit control's ReturnKeyType property Go, Search or Send allows the OnKeyDown event to fire for the Enter key. Good stuff! But not ideal....

I sent a note to a relevant party within EMBT and after reviewing the report it has since been re-opened. That's a start.

To try and be a bit more helpful I'd like to offer a solution to having the Enter key get OnKeyDown and OnKeyUp events triggered. This involves editing one of the Java files that underpins the Delphi Android FireMonkey. implementation

The default RAD Studio installation for 10.3.3 is to C:\Program Files (x86)\Embarcadero\Studio\20.0. If we assume an environment variable BDS is set to that value (as it is in a RAD Studio Command Prompt) then the Java source files can be found in:

%BDS%\source\rtl\androiddex\java\fmx\src\com\embarcadero\firemonkey

The file of interest is in a subfolder and is:

text\FMXEditText.java

so to put it another way:

%BDS%\source\rtl\androiddex\java\fmx\src\com\embarcadero\firemonkey\text\FMXEditText.java

In this file just over halfway down is a routine called onEditorAction, which needs a slight tweak. It's only a short subroutine, but if you examine the logic you'll appreciate that it contains a condition with some logic in the if section and some more logic in the else section.

The required change is to remove the else section and leave the logic currently contained there to run unconditionally. I don't want to copy out code from the RTL to avoid transgressing any inappropriate boundaries, but if the code currently looks like this:

public void onEditorAction(int actionCode) {
    if (condition) {
        // if block
    } else {
        // else block
    }
}

we want to alter it to look like this:

public void onEditorAction(int actionCode) {
    if (condition) {
        // if block
    }
    // else block
}

Assuming this is all done, what next?

Well the next step is to rebuild all the Java files and replace the compiled Java archives with the updated re-compiled ones. Fortunately I can help out there. I posted yesterday a full command script that will do just this exact job, so please make use of that to follow the required steps to get the fix.

Once you have run the script to generate new Java archives and re-built and re-run your Android app your events should trigger on Android when you press the soft Enter key.

One final thing: don't forget to backup the original Java archive files before running the script as mentioned in the post!

C++Builder's Android location sensor woes

2020-02-11T08:41:00.000-08:00

There is an unfortunate problem with RAD Studio 10.3.3 for anyone using C++Builder building Android applications. However it has a quite straightforward resolution, so let's look at what the issue is.

If you make a new Multi-Device Application in C++Builder and build it, all will be well, of course. The basics work very nicely.

If you now drop a TLocationSensor component on the form and try to build now, the result will be different. Compilation goes fine. Linking looks like it is going fine.... until it fails with a rather unhelpful message:

[ldandroid Error] "ld" exited with code 1.

Let's look at how we can get more useful feedback from this rather opaque and somewhat 1990s error message and see how to resolve the underlying problem.

If you examine the Message window closely you will see immediately above that error message there is an expandable item that says:

> ldandroid command line

No need to expand it, just right-click on that entry and choose Copy. Paste that into a text editor (preferably something better than Notepad). Depending on the editor and the options enabled within it you'll be looking at something approximately like this:

You'll notice that we have a command-line broken into multiple shorter lines with a prefix line that is not part of the command-line proper. You'll need to delete the top line, then conjoin all the subsequent lines into one long command line, leaving you with a single long line, which when wrapped in my same editor looks like this:

Now launch a RAD Studio Command Prompt (hit the Windows Start button and start typing in RAD and it should be offered to you as an option).

Use the CD /D command to change to the drive and folder in which your project resides

Go back to the long command-line in your editor and copy it into the clipboard and then paste it into the command prompt window.

Pressing Enter. will run the same command outside the IDE giving you a more representative set of error messages that the IDE hasn't managed to parse and list for you.

Because of the long lines, another screenshot of the resultant command window isn't the best way to read the errors. Instead I have redirected the error output (the linker's stderr output) to a text file so I can paste it here making it easier to read. stderr can be redirected to file by adding this to the end of the command line:

2> a.txt

The content of the file is 9 errors. Each error consists of a line highlighting the problem module and a brief error message, and a line with a fuller message. The problem module in each case (so I don't need to repetitively include it) is:

c:\program files (x86)\embarcadero\studio\20.0\lib\Android\debug\librtl.a(Androidapi.Sensor.o)

The rest of the error message text looks like this:

In function `Androidapi::Sensor::ASensorManager_getInstanceForPackage(char const*)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor36ASensorManager_getInstanceForPackageEPKc[_ZN10Androidapi6Sensor36ASensorManager_getInstanceForPackageEPKc]+0x4): undefined reference to `ASensorManager_getInstanceForPackage'
In function `Androidapi::Sensor::ASensorManager_getDefaultSensorEx(ASensorManager*, int, bool)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor33ASensorManager_getDefaultSensorExEP14ASensorManagerib[_ZN10Androidapi6Sensor33ASensorManager_getDefaultSensorExEP14ASensorManagerib]+0x4): undefined reference to `ASensorManager_getDefaultSensorEx'
In function `Androidapi::Sensor::ASensorManager_createSharedMemoryDirectChannel(ASensorManager*, int, unsigned int)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor46ASensorManager_createSharedMemoryDirectChannelEP14ASensorManagerij[_ZN10Androidapi6Sensor46ASensorManager_createSharedMemoryDirectChannelEP14ASensorManagerij]+0x4): undefined reference to `ASensorManager_createSharedMemoryDirectChannel'
In function `Androidapi::Sensor::ASensorManager_createHardwareBufferDirectChannel(ASensorManager*, Androidapi::Sensor::AHardwareBuffer_*, unsigned int)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor48ASensorManager_createHardwareBufferDirectChannelEP14ASensorManagerPNS0_16AHardwareBuffer_Ej[_ZN10Androidapi6Sensor48ASensorManager_createHardwareBufferDirectChannelEP14ASensorManagerPNS0_16AHardwareBuffer_Ej]+0x4): undefined reference to `ASensorManager_createHardwareBufferDirectChannel'
In function `Androidapi::Sensor::ASensorManager_destroyDirectChannel(ASensorManager*, int)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor35ASensorManager_destroyDirectChannelEP14ASensorManageri[_ZN10Androidapi6Sensor35ASensorManager_destroyDirectChannelEP14ASensorManageri]+0x4): undefined reference to `ASensorManager_destroyDirectChannel'
In function `Androidapi::Sensor::ASensorManager_configureDirectReport(ASensorManager*, ASensor*, int, int)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor36ASensorManager_configureDirectReportEP14ASensorManagerP7ASensorii[_ZN10Androidapi6Sensor36ASensorManager_configureDirectReportEP14ASensorManagerP7ASensorii]+0x4): undefined reference to `ASensorManager_configureDirectReport'
In function `Androidapi::Sensor::ASensorEventQueue_registerSensor(ASensorEventQueue*, ASensor*, int, long long)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor32ASensorEventQueue_registerSensorEP17ASensorEventQueueP7ASensorix[_ZN10Androidapi6Sensor32ASensorEventQueue_registerSensorEP17ASensorEventQueueP7ASensorix]+0x16): undefined reference to `ASensorEventQueue_registerSensor'
In function `Androidapi::Sensor::ASensor_isDirectChannelTypeSupported(ASensor*, int)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor36ASensor_isDirectChannelTypeSupportedEP7ASensori[_ZN10Androidapi6Sensor36ASensor_isDirectChannelTypeSupportedEP7ASensori]+0x4): undefined reference to `ASensor_isDirectChannelTypeSupported'
In function `Androidapi::Sensor::ASensor_getHighestDirectReportRateLevel(ASensor*)':
Androidapi.Sensor:(.text._ZN10Androidapi6Sensor39ASensor_getHighestDirectReportRateLevelEP7ASensor[_ZN10Androidapi6Sensor39ASensor_getHighestDirectReportRateLevelEP7ASensor]+0x4): undefined reference to `ASensor_getHighestDirectReportRateLevel'

What we are looking at here are a bunch of symbols that are defined in the Delphi RTL file Androidapi.Sensor.pas as symbols to be imported from the Android library libandroid.so, but which are not actually present in the one being linked to from the NDK platform folder specified in your SDK definition, which is likely to be 22.

Huh?

OK, the important thing here is what we can do about the problem. The answer is that you need to take a copy of the files Androidapi.Sensor.pas and Androidapi.inc from C:\Program Files (x86)\Embarcadero\Studio\20.0\source\rtl\android\ and put them in your project folder (or somewhere you can reference).

Add the file to your project using the Project Manager's context menu (remembering to choose Pascal unit (*.pas) from the list of file type filters in order to see the Delphi unit.

Now open the unit in the editor and hunt down these 14 symbols. For each of them comment out the entirety of the definition (select the whole definition and press Ctrl+/):

ASensorManager_getInstanceForPackage
ASensorManager_getDefaultSensorEx
ASensorManager_createSharedMemoryDirectChannel
ASensorManager_createHardwareBufferDirectChannel
ASensorManager_destroyDirectChannel
ASensorManager_configureDirectReport
ASensorEventQueue_registerSensor
ASensor_isDirectChannelTypeSupported
ASensor_getHighestDirectReportRateLevel

You'll notice that these APIs are pretty much all commented as new in API 26 (though one seems to be missed, ASensorEventQueue_registerSensor). It is this fact that causes the issue. Your application is linking against the API 22 library, which does not expose these symbols and so they should not be present in the unit.

You should find that you can now rebuild your project successfully.

Rebuilding the Delphi & C++Builder Android Java files

2020-02-11T06:53:00.000-08:00

Some while back I posted a command script (or batch file as we used to call them) that could be used by RAD Studio 10.3 users if they felt the need to change any of the few Java files underlying Delphi's (and C++Builder's) Android RTL and FireMonkey code.

The script would rebuild all the Java files into the required fmx.dex.jar and fmx.jar archives and copy them into the relevant RAD Studio installation folders to be used on subsequent builds.

When I tried to use the script with RAD Studio 10.3.3 of course it didn't work as things have changed, different files need to be involved in the process. I have updated the script now to work with RAD Studio 10.3.3 and thought I'd share it in case anyone else needs to do this.

An obvious question is: Why would anyone else want to rebuild the Java Android RTL files? Well this is normally a necessary step if you find an issue in the code as Embarcadero ships it and you want to try to fix it or enhance it. Indeed the previous post on rebuilding the 10.3 Java files was all about patching the Java code to get Android Intent support working.

If you have no interest in tweaking the Java code or fixing any issues you encounter in the Java code then you probably won't be needing this script.

If you do need the script, remember to take a backup of your original compiled archives before you proceed. These are found in:

C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\debug\fmx.jar
C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\debug\fmx.dex.jar
C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\release\fmx.jar
C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\release\fmx.dex.jar

The script needs to be run from an administrative command prompt and before you run it you should double-check the various paths set up in the environment variables at the start are all valid on your system.

The script can be found below (apologies for any layout issues caused by longer lines than the narrow blog width); hat-tip and thanks to Tom Byrnes for test-driving it:

@echo off
cls

rem Android RTL Java files rebuilder for RAD Studio 10.3.3

setlocal enabledelayedexpansion

rem Set environment variables
rem *NOTE*: check these folders match your setup

set EMBT=Embarcadero\Studio\20.0
set BDS=%ProgramFiles(x86)%\%EMBT%
set JAVA_PATH=%ProgramFiles%\Java\jdk1.8.0_60\bin
rem This is the default path for the Android SDK when installed from the .iso installer
set SDK_PATH=%PUBLIC%\Documents\%EMBT%\PlatformSDKs\android-sdk-windows
if not exist "%SDK_PATH%\" (
  rem This is the default path for the Android SDK when installed from the web install (aka ESD install)
  set SDK_PATH=%PUBLIC%\Documents\%EMBT%\CatalogRepository\AndroidSDK-2525_20.0.36039.7899
)

rem Set more environment variables based on those above

set DX_PATH=%SDK_PATH%\build-tools\28.0.2
set ANDROID_JAR=%SDK_PATH%\platforms\android-26\android.jar
set BDS_LIB=%BDS%\lib
set BDS_DEBUG_LIB=%BDS%\lib\android\debug
set BDS_RELEASE_LIB=%BDS%\lib\android\release
set FMX_SRC_PATH=%BDS%\source\rtl\androiddex\java\fmx
set CLASS_PATH=%ANDROID_JAR%
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\android-support-v4.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\cloud-messaging.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\com-google-android-gms.play-services-base.16.0.1.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\com-google-android-gms.play-services-maps.16.1.0.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\debug\com-google-android-gms.play-services-ads.17.2.0.jar
rem For adListener
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\com-google-android-gms.play-services-ads-lite.17.2.0.jar
rem For AbstractSafeParcelable
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\com-google-android-gms.play-services-basement.16.2.0.jar
rem For ReflectedParcelable
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\com-google-android-gms.play-services-basement.16.2.0.jar

echo.
echo Checking environment variables

if not exist "%BDS%\" (
  echo Path used to set BDS environment variable does not exist^^! Is RAD Studio installed elsewhere?
  goto :Error
)

if not exist "%JAVA_PATH%\" (
  echo Path used to set JAVA_PATH environment variable does not exist^^! Is the JDK installed elsewhere?
  goto :Error
)

if not exist "%SDK_PATH%\" (
  echo Path used to set SDK_PATH environment variable does not exist^^! Is the Android SDK installed elsewhere?
  goto :Error
)

if not exist "%ANDROID_JAR%" (
  echo Path used to set ANDROID_JAR environment variable does not exist^^! Is your android.jar in a different platform folder?
  goto :Error
)

echo.
echo Changing to the FMX source folder
echo.

pushd %FMX_SRC_PATH%

echo Getting fully qualified list of all Java source file we need to rebuild
echo.

if not exist bin\classes mkdir bin\classes
if not exist bin\debug mkdir bin\debug
if not exist bin\release mkdir bin\release
dir src\android\bluetooth\*.java /s /b > JavaSources.txt
dir src\android\telephony\*.java /s /b >> JavaSources.txt
dir src\com\*.java /s /b >> JavaSources.txt

echo Ensuring FMX source path ends in a '\'
echo.

set LAST_CHAR=%FMX_SRC_PATH:~-1%
if not "%LAST_CHAR%"=="\" set FMX_SRC_PATH=%FMX_SRC_PATH%\

echo Making Java source file paths relative to current directory
echo.

if exist JavaSources2.txt del JavaSources2.txt
for /F "tokens=*" %%A in (JavaSources.txt) do (
  set STR=%%A
  set "STR=!STR:%FMX_SRC_PATH%=!"
  echo !STR!>>JavaSources2.txt
)

echo Compiling all the FMX Java code into class files with debug info
echo.

"%JAVA_PATH%"\javac -g -d bin\classes -classpath "%CLASS_PATH%" -encoding UTF-8 -g @JavaSources2.txt
if errorlevel 1 (
  echo.
  echo Problem encountered during Java compilation
  goto :Error
)

echo.
echo Creating jar containing the new compiled FMX Java classes with debug info
echo.

"%JAVA_PATH%"\jar cf bin\debug\fmx.jar -C bin\classes .
if errorlevel 1 (
  echo.
  echo Problem encountered during Java archiving
  goto :Error
)

echo Creating DEX jar containing the new compiled FMX Java classes with debug info
echo.

call %DX_PATH%\dx --dex --output=bin\debug\fmx.dex.jar --positions=lines bin\debug\fmx.jar
if errorlevel 1 (
  echo.
  echo Problem encountered during DEXing
  goto :Error
)

echo Compiling all the FMX Java code into class files without debug info
echo.

"%JAVA_PATH%"\javac -g:none -d bin\classes -classpath "%CLASS_PATH%" -encoding UTF-8 @JavaSources2.txt
if errorlevel 1 (
  echo.
  echo Problem encountered during Java compilation
  goto :Error
)

echo.
echo Creating jar containing the new compiled FMX Java classes without debug info
echo.

"%JAVA_PATH%"\jar cf bin\release\fmx.jar -C bin\classes .
if errorlevel 1 (
  echo.
  echo Problem encountered during Java archiving
  goto :Error
)

echo Creating DEX jar containing the new compiled FMX Java classes without debug info
echo.

call %DX_PATH%\dx --dex --output=bin\release\fmx.dex.jar --positions=lines bin\release\fmx.jar
if errorlevel 1 (
  echo.
  echo Problem encountered during DEXing
  goto :Error
)

copy bin\debug\* "%BDS_DEBUG_LIB%"
copy bin\release\* "%BDS_RELEASE_LIB%"

echo Tidying up...
echo.
if exist JavaSources.txt del JavaSources.txt
if exist JavaSources2.txt del JavaSources2.txt
rd /s /q bin

goto :End

:Error
echo.
echo Sorry, we had a problem :(
echo.

:End

echo Changing back to the folder we started in

popd

endlocal

Solution to iOS Delphi build failure

2019-01-08T11:44:00.001-08:00

Some Delphi users building iOS applications have been thwarted by a…, well let’s be polite and call it a bit of an annoyance, when building their applications. What should just be an informational message about a warning from the ld linker ends up becoming a build breaker. The failure message looks something like this example (taken from RSP-19759, reported in January 2018):

[DCC Error] E2597 ld: warning: unknown dwarf DW_FORM_strp (offset=0xFFFFCEE7) is
    too big in FBSDKShareKit.a(FBSDKAppInviteContent.o)
  ld: warning: unknown dwarf DW_FORM_strp (offset=0xFFFF6E38) is too big
    in C:\Dev\lib\ios\facebook\FBSDKShareKit.framework\FBSDKShareKit.a
    (FBSDKAppInviteContent.o)

The fact that ld is emitting a warning about something is neither here not there. Or rather it *should* be neither here nor there. Unfortunately when Delphi receives this warning it turns it into a fatal error.

Oh dear… (・_・、)

Delphi 10.3 Rio contains a change to address this issue…. ˚◡˚

Unfortunately, however, Embarcadero forgot to mention it to anyone ¯\_(ツ)_/¯

This post tries to fix that communications oversight by covering the details of the change, which is an important step as you do need to add in a new compiler / linker switch.

The iOS ld linker now supports a new option –bequiet, which stops Delphi being able to wrongly interpret the ld warnings (by silencing them).

To use the new option choose Project | Options… (Shift+Ctrl+F11) and do one of these two things:

select Building | Delphi Compiler | Compiling | Other Options and add --linker-option:-bequiet to Additional options to pass to the compiler, or
select Building | Delphi Compiler | Linking and add -bequiet to Options passed to the LD linker

You should now be able to build your project successfully without this little hindrance.

Good luck!

CodeRage 2018 (redux)

2018-12-08T14:16:00.001-08:00

This year at CodeRage 2018 I presented a session on Creative Delphi Debugging Techniques.

Other than my speaking volume being a bit quiet, it generated a number of very nice comments about the subjects covered so I thought it might be useful to mention that it is available for on-demand viewing as part of the CodeRage 2018 Replay.

There is free enrolment in the conference replay and my session, along with the session slides and sample files, can be found here.

If you watch it I hope you turn up your PC volume and get a lot out of it to hopefully help with your debugging exercises!

RAD Studio 10.3 Rio’s Android Intent support (or current lack thereof)

2018-12-08T12:32:00.001-08:00

Sometimes when a new product is released there are a few ‘teething issues’. That certainly seems to be the case with RAD Studio 10.3 Rio. Both Delphi and C++Builder are hitting a few problems on various fronts. Now, it is true that internally in the product there has been a lot of change in the IDE, the VCL and FireMonkey, and perhaps it is therefore unsurprising a few slip-ups will have occurred.

It is, however, quite annoying when you fall foul of these slip-ups and have to wait for a fix….

The issue I want to address in this post is the breakage in the Android support for registering an interest in knowing about certain Intent objects received by the app. This is normally achieved by a call to MainActivity.registerIntentAction, as pseudo-documented here (when it was introduced in RAD Studio 10 Seattle) and here (in reference to a sample app) on Embarcadero's docwiki and illustrated here in my article on NFC usage.

This new Intent support worked nicely in RAD Studio 10 Seattle, 10.1 Berlin and 10.2 Tokyo. Not so in RAD Studio 10.3 Rio. You get a crash when trying to register a new Intent that you want to act upon.

This issue has already been reported twice, once here as RSP-21841 and again here as RSP-22877. I’ve had direct contact from someone using my NFC ode who has hit this problem. The cause of the problem was an oversight in a change made to the Java code underlying the FMX Android integration during a refactoring exercise. This is highlighted in the RSP-21841 report by Dave Nottage.

In short an array used to hold the list of registered Intents is now set up as an immutable array instead of a mutable array and this leads to the following unsavoury response to any call to MainActivity.registerIntentAction:

So, while we await an official fix for this can we generate an unofficial fix? Yes! And what’s more it doesn’t take much effort.

The steps below assume a default installation with default folders and so on. You’ll need to change any folders that you customised.

1) First things first, download and install Code Central download 30869: December 2018 Missing Files Patch for 10.3. That then gives is the full set of Android Java files within RAD Studio.

Now we are going to correct the error and rebuild fmx.jar and fmx.dex.jar, which contain the errant code.

2) Make a backup of fmx.jar and fmx.dex.jar from these two folders (so 4 files in total being backed up):

C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\debug
C:\Program Files (x86)\Embarcadero\Studio\20.0\lib\android\release

The next step is to fix the broken Java source code. The source file in question is in the Program Files (x86) folder tree and so can’t be edited normally. You need to run a text editor (for example RAD Studio or Notepad++) as administrator in order to be allowed to do that.

3) Anyway, open up C:\Program Files (x86)\Embarcadero\Studio\20.0\source\rtl\androiddex\java\fmx\src\com\embarcadero\firemonkey\FMXNativeActivity.java.

3a) Now locate the declaration of the field mRegisteredIntentActions, which is currently declared and (wrongly) initialised like this:

private List<String> mRegisteredIntentActions = Arrays.asList( NotificationInfo.ACTION_NOTIFICATION, NotificationPublisher.ACTION_GCM_NOTIFICATION);

Change this to:

private List<String> mRegisteredIntentActions;

3b) Next find where the onCreate method calls it inherited version with this statement:

super.onCreate(savedInstanceState);

Precede that with these three statements:

mRegisteredIntentActions = new java.util.ArrayList<String>(); mRegisteredIntentActions.add(NotificationInfo.ACTION_NOTIFICATION); mRegisteredIntentActions.add(NotificationPublisher.ACTION_GCM_NOTIFICATION);

That’s the code sorted out.

4) Now that’s done you should save the batch script shown at the end of this post in a text file somewhere (it doesn’t matter where) called BuildFMX.bat. Note that it’s important to ensure the file is stored as either a .bat file or a .cmd file if you prefer – if your Windows File Explorer is still left with its default options you won’t see file extensions and it’s easy to go wrong… I’ll work on the assumption you have saved it into a folder called C:\Scripts as C:\Scripts\BuildFMX.bat
Please ensure that all the paths used to set up variables at the start of the script are valid for your system. They certainly work on mine, and mine was a fresh default Delphi installation on a clean VM. In particular, check these are correct:

BDS
JAVA_PATH
SDK_PATH - for me with my ISO install this path needs to be:
C:\Users\Public\Documents\Embarcadero\Studio\20.0\PlatformSDKs\android-sdk-windows
but I gather you may perhaps find your SDK is installed to:
C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\AndroidSDK-2525_20.0.32429.4364
ANDROID_JAR - it may be that you have a different platform folder containing your android.jar file

[ Apologies for the lack of eye-pleasing syntax highlighting in the rendering of the script – I don’t really have time to sort out the blog gadgets to make it display nicer, so it’ll just have to do! ]

5) The final job is to run the batch file BuildFMX.bat. Since it needs to generate and update files in the protected Program Files (x86) folder you will need to run up an administrative command prompt. The easiest way to do this is to press the Windows key (ÿ), type cmd and press Ctrl+Shift+Enter. This will run cmd.exe as Administrator.

Change to the folder where you stored the batch file, e.g.:

cd C:\Scripts

Now run the script:

BuildFMX

You should see this:

Just clean your project (right click the output file in the Project Manager and choose Clean) and things will be back as they should be – you can register to respond to Intents as you might’ve expected to be able to all along.

Here’s the batch script to be saved into a batch file [ BTW, hat tip to my friend coma_g for employing his Ninja batch script skills to fix my for loop ]:

[ Updated 10/12/2018: added error checking (and reporting) on the environment variables, as this has tripped up one or two people ]

[ Updated 11/12/2018: changed the script to check both likely install paths for the Android SDK before bailing out ]

@echo off
cls

setlocal enabledelayedexpansion

rem Set environment variables
rem *NOTE*: check these folders match your setup

set BDS=%ProgramFiles(x86)%\Embarcadero\Studio\20.0
set JAVA_PATH=%ProgramFiles%\Java\jdk1.8.0_60\bin
rem This is the default path for the Android SDK when installed from the .iso installer
set SDK_PATH=%PUBLIC%\Documents\Embarcadero\Studio\20.0\PlatformSDKs\android-sdk-windows
if not exist "%SDK_PATH%\" (
  rem This is the default path for the Android SDK when installed from the web install (aka ESD install)
  set SDK_PATH=%PUBLIC%\Documents\Embarcadero\Studio\20.0\CatalogRepository\AndroidSDK-2525_20.0.32429.4364
)

rem Set more environment variables based on those above

set DX_PATH=%SDK_PATH%\build-tools\28.0.2
set ANDROID_JAR=%SDK_PATH%\platforms\android-26\android.jar
set BDS_LIB=%BDS%\lib
set BDS_DEBUG_LIB=%BDS%\lib\android\debug
set BDS_RELEASE_LIB=%BDS%\lib\android\release
set FMX_SRC_PATH=%BDS%\source\rtl\androiddex\java\fmx
set CLASS_PATH=%ANDROID_JAR%
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\android-support-v4.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\cloud-messaging.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\google-play-services-base-7.0.0.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\google-play-services-maps-7.0.0.jar
set CLASS_PATH=%CLASS_PATH%;%BDS_DEBUG_LIB%\google-play-services-ads-7.0.0.jar

echo.
echo Checking environment variables

if not exist "%BDS%\" (
  echo Path used to set BDS environment variable does not exist^^! Is RAD Studio installed elsewhere?
  goto :Error
)

if not exist "%JAVA_PATH%\" (
  echo Path used to set JAVA_PATH environment variable does not exist^^! Is the JDK installed elsewhere?
  goto :Error
)

if not exist "%SDK_PATH%\" (
  echo Path used to set SDK_PATH environment variable does not exist^^! Is the Android SDK installed elsewhere?
  goto :Error
)

if not exist "%ANDROID_JAR%" (
  echo Path used to set ANDROID_JAR environment variable does not exist^^! Is your android.jar in a different platform folder?
  goto :Error
)

echo.
echo Changing to the FMX source folder
echo.

pushd %FMX_SRC_PATH%

echo Getting fully qualified list of all Java source file we need to rebuild
echo.

if not exist bin\classes mkdir bin\classes
if not exist bin\debug mkdir bin\debug
if not exist bin\release mkdir bin\release
dir src\android\bluetooth\*.java /s /b > JavaSources.txt
dir src\android\telephony\*.java /s /b >> JavaSources.txt
dir src\com\*.java /s /b >> JavaSources.txt

echo Ensuring FMX source path ends in a '\'
echo.

set LAST_CHAR=%FMX_SRC_PATH:~-1%
if not "%LAST_CHAR%"=="\" set FMX_SRC_PATH=%FMX_SRC_PATH%\

echo Making Java source file paths relative to current directory
echo.

if exist JavaSources2.txt del JavaSources2.txt
for /F "tokens=*" %%A in (JavaSources.txt) do (
  set STR=%%A
  set "STR=!STR:%FMX_SRC_PATH%=!"
  echo !STR!>>JavaSources2.txt
)

echo Compiling all the FMX Java code into class files with debug info
echo.

"%JAVA_PATH%"\javac -d bin\classes -classpath "%CLASS_PATH%" -encoding UTF-8 -g @JavaSources2.txt
if errorlevel 1 (
  echo.
  echo Problem encountered during Java compilation
  goto :Error
)

echo.
echo Creating jar containing the new compiled FMX Java classes with debug info
echo.

"%JAVA_PATH%"\jar cf bin\debug\fmx.jar -C bin\classes .
if errorlevel 1 (
  echo.
  echo Problem encountered during Java archiving
  goto :Error
)

echo Creating DEX jar containing the new compiled FMX Java classes with debug info
echo.

call %DX_PATH%\dx --dex --output=bin\debug\fmx.dex.jar --positions=lines bin\debug\fmx.jar
if errorlevel 1 (
  echo.
  echo Problem encountered during DEXing
  goto :Error
)

echo Compiling all the FMX Java code into class files without debug info
echo.

"%JAVA_PATH%"\javac -d bin\classes -classpath "%CLASS_PATH%" -encoding UTF-8 @JavaSources2.txt
if errorlevel 1 (
  echo.
  echo Problem encountered during Java compilation
  goto :Error
)

echo.
echo Creating jar containing the new compiled FMX Java classes without debug info
echo.

"%JAVA_PATH%"\jar cf bin\release\fmx.jar -C bin\classes .
if errorlevel 1 (
  echo.
  echo Problem encountered during Java archiving
  goto :Error
)

echo Creating DEX jar containing the new compiled FMX Java classes without debug info
echo.

call %DX_PATH%\dx --dex --output=bin\release\fmx.dex.jar --positions=lines bin\release\fmx.jar
if errorlevel 1 (
  echo.
  echo Problem encountered during DEXing
  goto :Error
)

copy bin\debug\* "%BDS_DEBUG_LIB%"
copy bin\release\* "%BDS_RELEASE_LIB%"

echo Tidying up...
echo.
if exist JavaSources.txt del JavaSources.txt
if exist JavaSources2.txt del JavaSources2.txt
rd /s /q bin

goto :End

:Error
echo.
echo Sorry, we had a problem :(
echo.

:End

echo Changing back to the folder we started in

popd

endlocal

CodeRage 2018

2018-12-02T07:59:00.001-08:00

Just when I thought conference season was over, CodeRage 2018 came rapidly into view!

I like CodeRage – there’s always a good range of session subjects to choose from, and alwyas a range of good speakers to listen to.

I’ve had sessions at a few CodeRage conferences over the years, CodeRage 7, CodeRage 8, CodeRage XI and CodeRage XII. I’m pleased to continue that trend with a session at CodeRage 2018 – the official web page is at https://www.embarcadero.com/coderage-2018 and the registration page is at http://forms.embarcadero.com/CodeRageRegistration18.

This year I’m presenting my session on Creative Delphi Debugging Techniques. This session has been received positively when I’ve presented a trimmed down version of it to audiences at various conferences around Europe so I thought it would be an ideal session to present in full at CodeRage 2018 and have it available online ongoing.

I’ll be online on Wednesday 5th December at 5pm CST (UTC-6), which is 11pm GMT and the session will last 90 minutes (an hour and a half!). If you can stop by my session I’d really appreciate it, and hopefully you’ll pick up a few tips about some of the Delphi debugger features and possibly lose some of the fear of the CPU window… (yes, we’ll be spending some time in the CPU window!).

Have a fantastic CodeRage 2018!

RAD Studio 10.3 Rio supports Android runtime permissions

2018-11-22T03:55:00.001-08:00

RAD Studio 10.3 Rio has just been released for General Availability, as you’ll have doubtless learned from the spree of blog posts on the subject. This is a great new release with a lot of bug fixes and some nice updates to product behaviour and features.

One feature that seems to have not received its fair share of attention in the documentation is the support for the Android 6.0 (and later) runtime permissions model. This caused a bit of frustration earlier in the year when Google changed the Play Store submission rules so that from August 2018 new apps have to follow this new permissions model and from November 2018 app updates also new apps have to.

RAD Studio 10.3 enhances the basic Android support to ensure that Android apps built with Delphi or C++ now understand and can support this new model, which may require a bit of change to your application logic.

In essence, instead of all permissions being granted on application installation, so-called dangerous permissions now need to be requested at runtime where the user can grant or deny them as they see fit. Additionally the user can change their mind in the app settings and toggle the permissions at any time.

The Android RTL has been enhanced with a framework to support requesting permissions at runtime and being notified of the user’s decision, and potentially offering a little explanation for the need for the permission.

As mentioned the documentation for this framework falls a little short right now (at product launch), but hopefully will improve over time. To try and plug the gap I’ve written an article showing how the permission framework can be used, both in Delphi and in C++. If interested in learning more about the Android runtime permission framework introduced in RAD Studio 10.3 Rio, please follow one of these links:

Finally, while I have your attention on things Android, I would like to draw your attention to the Android-specific release notes for RAD Studio 10.3. You should read these to be sure of getting on with your first Android project with the new product release. It needs and uses a later Android SDK and NDK and you mat encounter some teething niggles on installation. These notes should help you!

Conferences in Europe

2018-09-06T12:05:00.001-07:00

Exciting times – conference season is upon us again and I’m excited to be heading off to a couple of them to talk to Delphi developers around Europe about subjects I’m passionate about.

First off, and it’s nearly here, is the Barnsten Delphi Conference 2018 in Utrecht in the Netherlands on Tuesday, September 18th. This is a one day event with a busy agenda. After the opening keynote from Delphi Product Manager Marco Cantú, I’ll be doing a plenary session on creating debugging techniques before the sessions split into 2 parallel tracks. In among these parallel sessions I’ll talk about Android API access and you can also choose from sessions by (among others) Bruno Fierens, Bob Swart, Danny Wind and Marco Cantú (again). These sessions are mostly in English, though a couple are not. This looks to be a great value day of Delphi expertise.

Later in the Autumn (or maybe it’s Winter by then…?) EKON 22 takes place from November 5th to 7th (Monday to Wednesday, with Wednesday being Workshop day). Again Marco Cantú will be doing the keynote and then we have lots of sessions in 3 parallel tracks, many in German, many in English. I’m presenting my Creative Debugging Techniques session first thing on the Tuesday. Other speakers include Stefan Glienke, Bruno Fierens, Marco Cantú (again), Andrea Magni, Ray Konopka and Cary Jensen (among others). You can peruse the full agenda here.
If you are thinking of going to EKON 22 you can get Early Bird discounted pricing until September 27th (see the registration page). Unfortunately I didn’t get to post about this before the Very Early Bird pricing ended, but Early Bird discount pricing is a good deal!

I hope to see some of you in Utrecht or Dusseldorf!

CodeRage XII session files – Directly Using The Android API

2017-11-07T15:27:00.001-08:00

My CodeRage XII session on Directly Using the Android API has been aired on the Internet. If you saw it I hope it came across reasonably well (interruptions notwithstanding) and might prove useful to you in your endeavours with Android.

As promised, the slides and samples are now available at this link. Do enjoy, now ˚◡˚ [ Update: the broken link has been fixed ]

Apologies for the interrupted video transmission during the conference. Rest assured that as soon as Jim can manage it, pretty much all the CodeRage videos will be made available for replay. As soon as mine is available I shall be updating this post with the link and also linking to it on ~~my Conference Talks web page~~. You can see it at your leisure now here at Embarcadero Academy.

CodeRage XII session

2017-11-07T01:05:00.001-08:00

A whole 5 years ago (!) I did a session for CodeRage 7 on accessing the Android API. This was not long after RAD Studio XE5 introduced support for developing Android applications, and Delphi’s Android support was in its first stage.

5 years on and CodeRage XII is starting today. I’ll be doing an updated talk on the same subject covering all that’s new in RAD Studio 10.2 at 3pm CST today, Tuesday 7th November 2017. I hope you can join me!

A full timetable of sessions is available in this PDF download in case you’re having trouble working out which sessions to attend.

Sad for me (due to working on-site meaning I won’t be able to catch them – alas they won’t be made available as replays!) but hopefully fabulous for many of you (if you can attend the sessions) is the inclusion in the list of speakers of a couple of legends in their areas:

Robert Martin (aka Uncle Bob Martin), author of Clean Code, 7am-9am 7th November 2017.
Steve McConnell, author of the classic Code Complete (among others), 12pm-1pm 8th November 2017.

These are well respected industry luminaries and Malcolm Groves, among others, has a lot to say about them.

Enjoy CodeRage XII!

‘What if?’ scenario analysis in the CPU window

2017-10-29T15:42:00.001-07:00

Last Tuesday, 24th October I did some sessions at EKON 21, one of which was on Creative Debugging Techniques. During the session there was a section where I was trying to demonstrate an idea or technique that happened to fully involve the CPU window. Unfortunately a series of finger fumbles on my part meant I couldn’t show what I wanted to show, albeit I think the point was made.

Anyway, I mentioned that maybe I’d write up that little snippet into a blog post, just to prove that it really does work as I suggested it does, and so here it is.

Oh, apologies up front for all the animated GIFs below- it seemed the most expeditious way to make sure I could really convey some of the points.

So the context was ‘What if?’ situations and testing out such scenarios during a debug session.

Clearly the primary tool for testing out ‘What if?’ scenarios is the Run, Evaluate/Modify… (Ctrl+F7) dialog. This dialog’s Modify button allows you to alter the value of the expression you have evaluated to find out how code behaves when the expression has a value other than what it actually had.

That’s a good and very valuable tool. But the case in point in the EKON 21 session was a bit different.

Consider a scenario where you are in the midst of a lengthy debug session, one that you’d really rather not reset and start again. Also consider that from some observations made in the debug session you have realised that a certain function B that is called from function A ought in fact not to be called. You want to test how well things pan out with B not being called.

In an entirely fabricated ultra-academic example, let’s use this code here, where A is TMainForm.WhatIfButtonClick and B is CommonRoutine.

procedure TMainForm.WhatIfButtonClick(Sender: TObject);

{$REGION '"What if?" scenarios'}

var
   S: string;

begin
   S := 'Hello world';
   Caption := S;
   CommonRoutine;
   Color := Random($1000000);
{$ENDREGION}

end;

One solution to this is to move the instruction pointer to skip the call to B just as B is about to be called. This can be done in a number of ways in Delphi. Set a breakpoint on the call to B and when it hits do one of the following four options to achieve this:

1) Set next statement menu item

Right-click on the statement that follows the call to B and select Debug, Set Next Statement, a menu item added in Delphi 2006 and described by Chris Hesik in this old 2007 blog post (from the Internet Archive WayBack Machine).

2) Drag the instruction pointer editor gutter icon

Drag the instruction pointer icon in the editor gutter to point at the following statement. This drag and drop support for the instruction pointer symbol was added in Delphi 2010.

3) Change the instruction pointer in the CPU window

Invoke the CPU window (View, Debug Windows, CPU Windows, Entire CPU or Ctrl+Alt+C), or at the very least the Disassembly pane (View, Debug Windows, CPU Windows, Disassembly or Ctrl+Alt+D). Right click on the next statement and choose New EIP (or Ctrl+N).

4) Update the EIP register in the CPU window

Invoke the CPU window (View, Debug Windows, CPU Windows, Entire CPU or Ctrl+Alt+C). Note the address of the instruction you want to execute next. Right-click the EIP register in the Registers pane and choose Change Register… (Ctrl+H) and enter the new value as a hexadecimal number, i.e. with a $ prefix. An alternative to Change Register… is to choose Increment Register (Ctrl+I) a sufficient number of times to get the value to match the target address.

OK, so all of those achieve the goal on that single invocation of routine A, but what about the case where A is called lots of times – lots and lots of times? This idea falls down in that situation and so we might seek out an alternative option.

Maybe we can get rid of the call to B entirely for this run of the executable. Yes, maybe we can and indeed that was just the very technique I tried to show, but made a couple of silly mistakes by not paying attention to what exactly was on the screen. Mea culpa.

There are a couple of approaches to getting rid of the call to B from the code present in A. One is to replace the first few bytes of that statement with an instruction that jumps to the next statement. The other is to replace the entire statement with opcodes corresponding to ‘no operation’, i.e. the no-op opcode NOP. Let’s look at both approaches.

Both these approaches involve changing existing machine instructions in memory. With that end goal comes a rule, and the rule is that you can’t successfully change a machine instruction that your program is currently stopped at in the debugger or that the debugger has a breakpoint on. In other words, if you want to change the call to CommonRoutine to be something else this must be done when the program is stopped at a different instruction in the debugger and there must be no breakpoint on that instruction.

This is simply a side effect of the way debuggers implement breakpoints and statement stepping - they replace the first byte of the instruction to break at with $CC, the byte value, or opcode, for the assembly instruction INT 3. When execution continues the $CC is swapped back for the original value.

So if you change the instruction at the current EIP when the execution has stopped in the debugger, when you ask it to move on your first byte will get replaced, just by the mechanics of your debugger doing its day job. This will most likely cause a very much unwanted opcode combination leading quickly to an application crash. [ One of my EKON fumbles was to instantly forget this previously well known (by me) fact and promptly get a crashed debuggee. ]

Your best bet is to put a breakpoint on the preceding instruction, and then modify/replace your target instruction. Make sure there is no breakpoint on the target instruction.

When you look in the CPU window you can see the assembly instructions that correspond to the Pascal statement above it.

In the case of the call to CommonRoutine the assembly code is:

mov eax,[ebp-$04]
call TMainForm.CommonRoutine

The machine code bytes (opcodes) that represent those 2 instructions are $8B, $45, $FC and $E8, $11, $F8, $FF, $FF respectively. The 3 bytes for the first instruction are stored at locations starting at $5D1287 and the 5 bytes for the second instruction start at $5D128A.

The statement following the call to CommonRoutine starts at address $5D128F, 8 bytes on from $5D1287.

1) Overwriting an instruction with a jump instruction

The goal is to write some opcodes into memory starting at address $5D1287 that represent an assembly instruction to jump 8 bytes forward. If we look at the documentation for the x86 JMP instruction, a small jump is 2 bytes of instructions encoded as $EB coupled with the jump distance from the end of the jump instruction. So 8 bytes minus the 2 byte instruction is 6, so $EB $06. [ One of my fumbles in the EKON session was to misread the $EB as $E8, which is a CALL opcode. ]

So, to change the current code for new instructions we have to move our attention away from the Disassembly pane to the Memory pane. You can either use the one embedded into the Entire CPU view or open up one of four standalone memory panes using an item from the submenu View, Debug Windows, CPU Windows:

Memory 1 (Ctrl+Alt+E)
Memory 2 (Ctrl+Alt+2)
Memory 3 (Ctrl+Alt+3)
Memory 4 (Ctrl+Alt+4)

By default the memory pane will be settled on address $401000, the start of the application’s Code segment (according to first piece of information in a detailed .map file, as generated by the linker).

You should reposition to the target instruction by using Go to Address… (Ctrl+G) from the context menu and entering (in this examples case) $5D1287. You’ll see the ‘familiar’ 8 bytes we saw for the instructions right there on the first line:

To change these 6 bytes to be bytes representing our jump instruction you can select Change (Ctrl+H) from the context menu and enter the values: $EB $06.

You can also simply start typing those values directly into the Memory pane and the Enter New Value dialog will pop up.

This changes the first 2 bytes of that instruction and the Disassembly pane echoes this by showing the JMP instruction.

As you’ll note, however, there is a bit of “noise” after this for the remaining 6 opcodes: some junk that is jumped over.

[ Update 30/10/2017 – thanks to The Arioch for welcome interjections. It should be noted that in this case after trampling over the first 2 opcodes the remainder of the previous set of opcodes still “make sense” to the disassembler. So much so that the very next Delphi statement is still shown and is still translated directly into its constituent opcodes.

It is, however, often the case that having bulldozed over a couple of essentially arbitrary opcodes, what’s left is a bit of a mess, and puts things “out of kilter”, leaving subsequent Delphi statements not showing in the disassembly pane thanks to what opcodes have come before.

As a simple example, not necessarily demonstrating the ultimate confusion that can be caused, here’s some code:

If we wish to skip the ShowMessage call we need to workout the JMP opcodes.

Run a copy of Windows Calculator, go into programmer mode (Alt+3), and calculate $5D1686 – $5D167C to get the gap from ShowMessage to the following statement. Then subtract 2 to take off the size of the small JMP instruction. This gives a final result of 8, so we enter new opcodes of $EB $08 and what’s then showing in the disassembly pane is this:

The disassembly of the call to CommonRoutine has gone rather up the spout, even though the opcodes for it are actually still quite intact.

End of update ]

To clean this up we could fill in the remaining 6 bytes with opcode $90, which corresponds to NOP, the assembly no-op instruction:

This shows as:

[ Another of my EKON fumbles was to enter too many $90 bytes having miscounted the required bytes, or perhaps forgetting that I need to subtracted the size of the jump instruction. This rather messed up the following instruction, which should have been left intact. This got another crash. ]

Or you could fill with data byte $FF – just data:

2) Overwriting an instruction with NOP opcodes

This is just an extension of the last points in the option above. In a memory pane that has been located on the start of the target instruction, just change all the bytes of the instruction to the NOP opcode, $90. We have 8 bytes here, so use the Change submenu item (Ctrl+H):

There we go, that’s what I meant to show in that 5 minute section of the session – apologies for the poor demonstration but hopefully this makes up for it ¯\_(ツ)_/¯

Remote debugger recalcitrance

2017-10-17T12:07:00.001-07:00

My development machine in my main week day job does not have some custom hardware that a nearby test machine does. It doesn’t make sense to load up the development environment onto the test machine for various reasons, so I am a fairly irregular user of remote debugging against my Win32 application.

As it happens the client language is C++Builder (classic compiler), but I expect this issue to apply equally to Delphi (I’d be interested to know from anyone who can confirm one way or another).

Remote debugging works quite nicely via PAServer. It is certainly straightforward in comparison to the games we had to play some years back – PAServer seems to have simplified the setup quite nicely.

Granted, stepping is pretty slow, but then there’s quite a lot going on and a certain amount of information for PAServer retrieve from the remote debugger (rmtdbg250.exe) and then to send back to PAClient and to the IDE, so I can take that.

What gets my goat, though, is what happens when the program ends. Often I have to kill the application (Ctrl+F2, or Run, Program Reset), but often the application exits quite naturally.

More often than not I can’t make a change in the code and have F9 successfully compile and run up the app remotely again. I get this:

[PAClient Error] Error: E0009 Cannot create file "\\?\C:\Program Files (x86)\Embarcadero\PAServer\19.0\scratch-dir\some_subfolder\project_name\project_name.tds". The process cannot access the file because it is being used by another process

As it turns out this is indeed true. There are two copies of the remote debugger, rmtdbg250.exe (in the case of RAD Studio 10.2.x) running, at least one of which has a handle open on the TDS symbol file.

This is quite annoying, as I have to use Task Manager to show me the two remote debuggers and manually kill them. In the grand scale of things, there are worse things, of course. But over a number of deploy/debug cycles this does get annoying.

Maybe I need to revert to directly running the Remote Debug Server?

Anyway, in lieu of a good reason for this and in the absence of good behaviour from the remote debuggers I’ve had to expedite the clean-up process by way of another command script (aka batch file). This gets the process IDs (PIDs) of the remote debuggers and has Windows kill them. It has to do this twice though, as the first time round one of the pesky debugger instances always survives the cull.

Anyway, on the off-chance it is of any use to others, here is the script, which I call KillDebuggers.bat. Apologies for its slightly prolix nature – I like to keep alternative approaches around just to remind myself of how I can do things.

@echo off
rem When remote debugging, this batch file is useful to kill the 

rem remote debugger instances that refuse to die naturally
setlocal
rem First round
echo.&echo First round of Wipe Out The Debuggers&echo.
call :sic_em_boy
rem Second round
echo.&echo Second round of Wipe Out The Debuggers&echo.
call :sic_em_boy
endlocal
goto :EOF
:sic_em_boy
set CMDLINE=tasklist /FO TABLE /NH /FI "IMAGENAME eq rmtdbg250.exe"

rem This gives output lines like:
rem rmtdbg250.exe 776 Console 2 6,456 K
rem The PID is token 2, if we consider this as white space delimited

rem However if no debuggers are running we get:
rem INFO: No tasks are running which match the specified criteria.
rem In that message token 2 is "No"
for /f "tokens=2 delims= " %%A in ('%CMDLINE%') do (
  if %%A == No (
    echo No debugger found!
  ) else (
    taskkill /PID %%A
  )
)
rem Or we could simply say:
rem taskkill /IM rmtdbg250.exe

exit /B

If anyone has any input on this issue, please get in touch via the comments.

Project corruption bug

2017-10-16T12:26:00.001-07:00

Long ago there was an issue with the RAD Studio IDE (Delphi and C++Builder both). It meant that when changing certain project options or switching build configurations, the (XML format) project file would get saved with an extra errant (empty) XML element in it, causing subsequent compilations to baulk, complaining about: ProjectExtensions appears multiple time in project. If you build from the command line the error looks like: [MSBuild Error] MSB4079 The <ProjectExtensions> element occurs more than once.

The extra line in the file, were you to open it in a text editor and take a look, will be rather like this:

<ProjectExtensions />

If you peruse some of the entries in Embarcadero’s Quality Central portal, such as this, this or even this, then you’ll see that Embarcadero made some changes in XE6 that improved matters (done against Quality Central bug 109016, no longer accessible since QC went offline some while back, but in this list of XE6 fixes), but clearly has not dismissed the problem entirely. Various customers do continue to hit it, albeit not very reproducibly.

This set of affected customers does include myself. I was hitting this issue very regularly in C++Builder XE3 and this then continued (perhaps less frequently, I’m not sure) in more recent versions of the product.

I think one of the reasons the issue doesn’t get more coverage is that the IDE appears generally not to mind when the project file gets an extra ProjectExtensions element inserted. Indeed it may well be the case that the internal IDE state is more correct than what gets written to the file so generally it will be command-line builds that fail more than IDE builds, with the errant file element often getting removed during subsequent saves of the project.

Whatever the specifics, the IDE issue is most definitely still present, but it is seems to be proving extremely tricky to get a reproducible test case to submit, as it seems to be subject to the whims of the weather, almost.

For me this is quite frustrating. I use an automated build system and it is a fairly regular occurrence that after checking in a changed project file (say after bumping the version number a bit) the build system will see the repository change, pull out the updates and set off a new build. Then shortly thereafter I’ll be notified of a build failure, and I’ll see it’s another occurrence of the broken project, which I then need to fix with a text editor and check in again.

In order to save my sanity I now use the reFind.exe command (the Regular Expression find and replace tool added in XE5) on the build server. The automated build system we use (Jenkins in our case, which I personally think is absolutely fabulous!) pulls out changed files from the version control repository, runs reFind to fix any possibly broken projects and then builds from there on it.

Here’s an example of a call to reFind, which lives in RAD Studio’s bin directory:

refind project_name.dproj /L "/P:^\s*<ProjectExtensions\s/>\s*$\r\n" "/R:"

This does a multi-line search to locate any lines that contain only an empty ProjectExtensions element (plus optional whitespace where that may be found) and replaces it with nothing, i.e. deletes it.

[ Update – 17/10/2017

It should perhaps be explicitly noted that my suggested use of reFind works quite nicely on an automated build server, where command-line builds are the order of the day. However, if you try the same trick on your development machine and the project happens to open in the IDE, well you perhaps won;t be surprised to see the IDE spot the change to the project file and immediately pop up and invite you to let it reload. That might be a bit annoying every time you run a command-line build. So apply some thought and judgement to where you use the reFind trick.

End Update ]

[ Update 2 – 17/10/2017

Just for completeness, if you just want to find out if your project has the ProjectExtensions issue you can use this grep call (grep.exe is also supplied in the RAD Studio bin directory, but its implementation of regular expressions is not quite the same as reFind’s):

grep -e "^[ \t]*<ProjectExtensions[ \t]*/>[ \t]*$" project_name.dproj

End Update ]

Some of the jobs that I have set up in Jenkins send custom emails, in addition to the normal “build failure” emails. I wrote a little command line tool that uses Blat to send emails under certain criteria, such as when a build completes with a new version number. Yes, I could have used Indy quite straightforwardly to do the same, but I just rustled up a batch file to drive Blat instead.

Anyway, I mention this as I suspect I’ll try and use it also to send an email if reFind is seen to have found an errant ProjectExtensions element in the project file. Being notified that there is an issue in the project file for me to fix as and when I decide to is preferable (IMHO) to the build breaking and forcing my hand there and then.

Of course all of this may be at odds to your own point of view. You may well consider a broken project file to warrant immediate repair, and welcome a build failure with open arms, but this is not the case in my setup. Horses for courses, and all that. I thought I’d just share the idea while I was in a sharing mood.

tl;dr – reFind is a nifty search and replace tool: check it out!

Delphi build/install/launch Android app from the command-line

2017-10-14T08:19:00.001-07:00

Quite some while back I answered a question on Stack Overflow, which explained how to build a Delphi project from the command line and also how to deploy it. The context of the question was Andriod development

In the case of an Android application deploying it has absolutely nothing to do with installing the resultant .apk file onto your Android device, despite what your personal interpretation of the word may be. Oh no, most definitely not.

Instead, deployment is about packaging up all your various files - your compiled Android library (a .so file), all the images, splash screens, icons, custom files, databases, application manifest file and so forth – all into an .apk file. In other words as far as the Delphi IDE is concerned, deploying a Delphi project means going from a .so native ARM library to an installable .apk file.

Clearly when you press F9 or Ctrl+Shift+F9 to run your application the IDE works out how to install your .apk on the currently connected and selected device, but that is subsequent to the IDE’s notion of the deployment step.

So, installation notwithstanding, that SO answer shows how to make/build and deploy a Delphi project, such as an Android project, from a RAD Studio command prompt:

To recap on it this does a build:

msbuild Foo.dproj /p:Config=Debug /p:Platform=Android /t:Build

This does a make, which only compiles files that have changed:

msbuild Foo.dproj /p:Config=Debug /p:Platform=Android /t:Make

This step, assuming you have done a deployment at least once in the IDE and thereby have had a Foo.deployproj file generated, will do the deployment:

msbuild Foo.dproj /p:Config=Debug /p:Platform=Android /t:Deploy

If you have the .deployproj file you can combine the two steps in this one command (excuse any line wrapping this blog theme applies):

msbuild Foo.dproj /p:Config=Debug /p:Platform=Android /t:Make;Deploy

[Update – 16/10/2-17:

I also bumped into the property that controls the Target Configuration, which can be Development or Application Store for Android. The BT_BuildType can either be Debug or AppStore for Android (for iOS there is also AdHoc. So if you want to build a signed app ready for upload to the Google Play store you could run:

msbuild Foo.dproj /p:Config=Release /p:Platform=Android /t:Make;Deploy /p:BT_BuildType=AppStore

End Update ]

So anyway, history to one side, I was wondering if there was another MSBuild target that did the installation, or if this was some custom code in the IDE, not exposed through MSBuild. My investigation suggests the latter to be the case, but I wanted a convenient command-line way to make, deploy and install the Android application (and even possibly launch it!).

The best option I could rustle up at short notice was a batch file (or command script, if you prefer). Save the file below as BuildAndInstall.bat or BuildAndInstall.cmd, set up any of the paths etc. that need personalising to your system.

Again, please excuse unsolicited line wrapping…. There is probably a nifty way to get this code into a horizontally scrollable div or similar, but I don’t have the time to do the research just now….

@echo off

rem Syntax
rem  Arg 1 = project name
rem  Arg 2 (optional) = build configuration
rem  Arg 3 (optional) = package name

set ANDROID_SDK=%PUBLIC%\Documents\Embarcadero\Studio\19.0\PlatformSDKs\android-sdk-windows
set ADB=%ANDROID_SDK%\platform-tools\adb.exe
set FQ_PROJECT=%~f1
set PROJECT_DIR=%~p1
set PROJECT_NAME=%~n1
set PACKAGE_NAME=com.embarcadero.%PROJECT_NAME%
set CONFIG=Debug

if X%1 == X goto syntax

if not exist %1 (
  echo Cannot locate project %FQ_PROJECT%
  goto :EOF
)

if not X%2 == X (
  if "%2" == "Release" set CONFIG=Release
)

if not X%3 == X (
  set PACKAGE_NAME=%3
)

pushd %PROJECT_DIR%

echo.&echo Building %1&echo.

msbuild %PROJECT_NAME%.dproj /p:Config=%CONFIG% /p:Platform=Android /t:Make || goto build_error

echo.&echo Deploying %1&echo.

msbuild %PROJECT_NAME%.dproj /p:Config=%CONFIG% /p:Platform=Android /t:Deploy || goto deploy_error

echo.&echo Installing Android package&echo.

%ADB% install -r Android\%CONFIG%\%PROJECT_NAME%\bin\%PROJECT_NAME%.apk || goto install_error

echo.&echo Launching Android app&echo.

%ADB% -d shell am start -a android.intent.action.MAIN -n %PACKAGE_NAME%/com.embarcadero.firemonkey.FMXNativeActivity || goto launch_error

popd

echo.&echo Done!

goto :EOF

:syntax

echo BuildAndInstall syntax:
echo.
echo   BuildAndInstall ^<DelphiProjectFile^> [^<Configuration^> [^<AndroidPackageName^>]]
echo.
echo where:
echo.
echo ^<DelphiprojectFile^> is a Delphi project.dproj file
echo ^<Configuration^> is the required build configuration, Release or Debug, which defaults to Debug
echo ^<AndroidPackageName^> is the Android package name for the project, in case it is different from com.embarcadero.project
goto :EOF

:build_error

echo Problem encountered while build the Android lib%PROJECT_NAME%.so native library
goto :EOF

:deploy_error

echo Problem encountered while creating the %PROJECT_NAME%.apk Android package
goto :EOF

:install_error

echo Problem encountered while installing %PROJECT_NAME%.apk
goto :EOF

:launch_error

echo Problem encountered while launching %PROJECT_NAME%.apk
goto :EOF

If you young pups reading this are all into relatively modern PowerShell scripting or traditional Windows scripting, then this throwback to the world of DOS may fall uneasily on the eye, but it works and there is a lot of power available in DOS scripting commands.

[ Update – 16/10/2017: I initially forgot to mention that you’d be wise to run this from a RAD Studio Command Prompt for the version of RAD Studio that you want to build your project. This ensures that the Windows search path is set up to find the correct compilers etc. Alternatively, at the top of my batch file you can do the equivalent of running a RAD Studio Command Prompt by inserting:

CALL C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\rsvars.bat

If you choose this latter option then you can use any old command prompt you like.

End Update ]

Now you can install and run an Android project with a command-line of:

BuildAndInstall Foo.dproj

if you want the release build, use:

BuildAndInstall Foo.dproj Release

If you’ve changed the package name (specified as package in the project options Version Info page) from the default com.embarcadero.Foo then to launch the app you’ll need to pass the package name on the command line:

BuildAndInstall Foo.dproj Debug com.blong.Foo

Don’t forget that you will have to choose Project, Deploy libProjectname.so in the IDE menus once before this will work.

I hope this is of use to someone….

EKON 21

2017-10-14T08:12:00.001-07:00

I’m delighted to say that later this month I’ll be over in Cologne speaking at EKON 21, which runs from 23rd to 25th October, 2017 and is being held in Cologne in Germany. I’m doing three Delphi-related talks on some of my favourite subjects: creative debugging, Android API usage and IDE tips/techniques.

Unfortunately, though, being as all three talks are in the same day, Tuesday 24th October, I’m not sure I’ll get to see much of the other great talks on offer, which is a shame for me.

It’s great to be heading back to EKON – I haven’t been over to Germany for a conference since long ago in 2004 at the joint BorCon Europe 2004 / EKON 8 conference in Frankfurt.

In 2004 I was into interoperability between unmanaged code (Win32 and COM) and .NET code, as well as building .NET profiling tools. This year my Android talk is not a million miles from those old interoperability talks, looking at how to reach out from unmanaged Delphi Android ARM code to managed Java code, for various purposes and reasons.

The debugging talk continues my efforts to help Delphi developers get better value for money from their debugger and debugging tools. This is a mission I’ve been on since the start of this century after having been inspired after watching Danny Thorpe do an excellent session at a BorCon in the late 90s, showing how to really utilise the CPU window and not see it simply as a source of horror.

The IDE tips talk is also an evolution of a session I’ve done on and off over the course of this century, trying to share knowledge of the IDE, code editor and so on that will help you do your job just that bit faster.

These talks are all based around Delphi although the concepts (and in some cases the specifics) are equally as applicable to C++Builder. I spend a lot of my working day working with C++Builder with a few regular clients and it is still a goal of mine to start getting more C++Builder information onto this blog.

If any readers are going to EKON 21, I hope to see you there and look forward to a great conference!

[ As seems to usually be the case, it’s been a much longer gap than I would like since I last put ~~pen~~ finger to ~~paper~~ keyboard for this blog. Mea culpa – I will endeavour to allot more time for this sort of thing, or more particularly for posts of general practical value ]

Debug logging in FireMonkey – CodeRage XI Lightning Talks

2016-11-22T03:15:00.001-08:00

During CodeRage XI I had a couple of Lightning Talks broadcast on a subject I’ve been intending to write up for quite a long time, but haven’t quite managed to achieve: how to emit debug log messages on the various FireMonkey platforms.

I made a 10 minute video for Delphi and one for C++ looking at all the target platforms, Win32/Win64, OS X/macOS, Android and iOS, showing the logging options and then looking at how to view log output.

Unfortunately I got a bit caught up in some work and didn’t publicise this ahead of the conference, so I think not many people were aware of them.

If you want to see the short videos after the fact, you can see them below or on YouTube:

Debug Logging in Delphi FireMonkey Apps

Debug Logging in C++ FireMonkey Apps

You can look at the supporting (short) slideshows on SlideShare (ignore the funky bullet point symbols – something was awry in the slide template when I made the slides):

Debug Logging in Delphi FireMonkey Apps

Debug Logging in C++ FireMonkey Apps

The simple sample projects are also available to download:

Android callbacks wrapped by FireMonkey

2016-09-09T16:13:00.001-07:00

A couple of years ago (exactly!) I posted on this blog about an article I’d written on accessing NFC tags from Delphi Android applications. At the time this was quite an involved exercise, requiring custom Java code to be compiled and linked in to the application in order to respond to the pertinent Android callback, Activity.onNewIntent. Indeed, Delphi versions XE5, XE6 and XE7 all have slightly differing capabilities, with each new release making certain Android operations rather easier.

While catching up on what’s new in recent releases of Delphi I realised a change had been snuck into Delphi 10 Seattle that makes the whole NFC exercise much more straightforward now in Delphi.

What this change means is:

No more custom Java code required!
No more linking in a custom Java library file
No more activity custom subclassing!
No more debugging obstacles!

This change seems to have gone in completely under the radar*, escaping the attention of the documentation department, so I thought it best that I brought it out into the open.

It turns out that the key activity callback that NFC foreground dispatch relies upon (Activity.onNewIntent) is now hookable from Delphi code (with the right know-how) and so all the Java shenanigans can be put behind us (at least in the context of NFC access). This callback is used in Android in all sorts of other scenarios as well, so if you find a requirement for responding to onNewIntent then Delphi 10 Seattle (and later) makes this something of a doddle.

I have updated the article to show the more direct means of accessing NFC from Delphi 10 Seattle and later and provided corresponding updated samples for Delphi 10 Seattle and Delphi 10.1 Berlin. You can find the full details and code there.

In short, though, new intents are picked up in the FireMonkey activity’s onNewIntent method and sent into the RTL cross-platorm messaging system. You can write message-receiving code to pick up new intents and process them, This intent messaging is done via an additional (and seemingly undocumented) use of the Android-specific TMessageReceivedNotification message.

If you are playing with NFC cards in your apps you can simplify the setup very nicely in the most recent versions of Delphi.

Just to round this topic (given the blog subject) off I’ll also mention that another activity callback, onActivityResult, is also covered by FireMonkey and has been since Delphi XE6. This is also wrapped up in the same messaging system, though this time with the TMessageResultNotification message.

I showed an example of how to use this to pick up information about a scanned barcode (scanned by the popular and open Source ZXing, or Zebra Crossing, barcode scanner app) in an article about launching various activity types back in April 2014: Launching activities and handling results in Delphi XE6 Android apps.

* Update [16/09/2016]: I have since discovered that both Delphi 10 Seattle and Delphi 10.1 Berlin ship with an Android intents demo that does in fact utilise this feature. The demo is located at:

Delphi 10 Seattle: %PUBLIC%\Documents\Embarcadero\Studio\17.0\Samples\Object Pascal\Mobile Snippets\AndroidIntents, documented here
Delphi 10.1 Berlin: %PUBLIC%\Documents\Embarcadero\Studio\18.0\Samples\Object Pascal\Mobile Snippets\AndroidIntents, documented here

The most up to date version of the demo can be found in the Delphi 10 Seattle Sourceforce repository or the Delphi 10.1 Berlin Sourceforge repository.

Speaking at the SDN Event

2016-09-01T02:10:00.001-07:00

All the preparations are nigh on complete and this evening I shall be on a short aeroplane ride to Holland (or The Netherlands, if you prefer) to present a couple of Delphi talks at one of the SDN’s big SDN Events – full agenda here. I’ll be in good company as also speaking on the Delphi track will be TMS Software’s Bruno Fierens and also Bob Swart.

I’ve spoken at User Groups regularly but this is the first opportunity for me to talk to Delphi developers from further afield at a conference since April 2015 when I was at the ADUG Symposium, speaking in Canberra and Melbourne.

SDN events are always friendly gatherings and I’ve spoken at a few of them over the years: 1997, 1999, 2002, 2005, 2006 and 2012.

This time around I will be speaking on two of my favourite subjects: creative debugging techniques and accessing the Android OS API. Naturally I’ll be using the latest and greates version of Delphi as a vehicle for the talks, and I’ll be trying to squeeze in as many technical tips, tricks and techniques as I can into the 2 hour-long sessions.

For those attending the event tomorrow (2nd September, 2016) I’ll see you there!

Live Templates (née Code Templates)

2016-06-23T09:38:00.001-07:00

Over the years since Delphi 3 various people have written about aspects of Code Templates and Live Templates, but not particularly recently. I find Code Templates fabulously helpful and Live Templates add some real power into the mix.

About six or seven months ago (November 2015) I did a User Group talk on Live Templates and it seemed to provoke some reasonable interest. Since then I’ve been trying to find a suitable time window to sit down and write it all up. At last I have had a couple of days to gather my thoughts and get it all down on (metaphorical) paper.

For the benefit of those who haven’t considered creating Live Templates to help their productivity, or who have forgotten about the feature over time, please feel free to peruse Code Templates and Live Templates over on my web site.