Since Delphi’s introduction of Android support with the release of XE5, there have been many questions posted hither and thither regarding whether and how you can build service applications with it. The pervading suggestion or suspicion is that maybe Delphi isn’t cut out to build such exotic Android creations.

Well, if your goal is to just build some sort of a service app I wouldn’t particularly recommend Delphi for the job right now, simply because it hasn’t got the wherewithal to support you in that endeavour in its current guise, and consequently it’s quite difficult. Really, if you just want to build a service app you’d probably have an easier time using Java or Oxygene for Java in conjunction with the Android SDK.

However if you are invested in building a Delphi Android app, are in the midst of building a FireMonkey application for mobile deployment, and need an Android service as part of that, well it’s quite possible. But as I may have mentioned, it’s neither particularly easy nor especially straightforward.

I am aware that I have (at this time of writing) yet to write up the business of adding Android menus to Delphi apps, employing a splash screen and launching Android activities and getting results back (as demo’d in my CodeRage 8 talk, albeit with code samples available in that linked post)*.

Now I can add to the list of things I have yet to write up the steps for creating a service application. If you take a look at this Google Play Store listing you’ll see I’ve built an app that, as well as a splash screen, also implements a service.

So yes, it’s quite feasible to build a service and a broadcast receiver in a Delphi app. That said, I’ve had to be a little creative on exiting the app to avoid a failure being evident on the screen.

As mentioned, these Android aspects that fall outside the standard simple business app paradigm haven’t factored into what is readily supported currently in Delphi’s Android support. Hopefully this will be improved as time goes on to allow all sorts of Android features and facets to be surfaced in Delphi Android code. In the mean time a certain degree of spelunking and skulduggery is needed to achieve certain ends.

I know quite a few people are clamouring for knowledge on how to build service apps. Hopefully in the near future I’ll write it up, but certainly in the nearer future I’ll release the code sample, once I’ve exhausted possibilities to clean up the wrinkle around app shutdown. That should satisfy the keener of you out there. In the mean time, be satisfied that it’s been proved to be possible at all.

Delphi automatically installs and runs your app for you, but sometimes it is nice to do manually from the command-line. Here are the commands you need. These all assume adb (Android Debug Bridge) is on your system path and you only have one Android device (or emulator) attached. They should work on both Mac and Windows.

See the end for notes on multiple devices or if you are running both an emulator and device.

First to install your app:

adb install path\ProjectName.apk

In this example path\ProjectName.apk is the full relative path to the apk. The apk usually has the same name as the project. If your apk is already installed, then use the following command to “reinstall” it, leaving the data intact:

adb install -r path\ProjectName.apk

The great thing about the -r is it works even if it wasn’t already installed.

Now if you want to uninstall your apk you can do that too:

adb shell pm uninstall -k com.embarcadero.ProjectName

Again, com.embarcadero.ProjectName is the default name of the package. If you changed it under Project Options -> Version Info -> Package, then use that value instead. BTW, the pm in there is the Android Package Manager.

One note, when Delphi deploys your app to run it, it performs an uninstall first. This results in all the data being cleaned out, which can be useful during development to be sure you don’t leave anything behind from the previous run. When a user updates an app from the App store, or installs it via most any other means, then it performs a reinstall, which leaves the data intact.

Now if you want to run it, things get a little more interesting. Now we use the Android Activity Manager (AM).

adb shell am start -n com.embarcadero.ProjectName/com.embarcadero.firemonkey.FMXNativeActivity

There are two parts to this. Before the slash is the package name, just like for uninstalling it. After the slash is the name of the Main Activity, which unless you’ve edited your AndroidManifest.template.xml (and some other fundamentals of your app) is always com.embarcadero.firemonkey.FMXNativeActivity. If you are trying to start an app written with another tool, then consult the AndroidManifest, but it is common for most tools to use MainActivity, so you can launch it like:

adb shell am start -n com.other.ProjectName/.MainActivity

If you want to stop your app after it is running, you just need the name of the package and the following:

adb shell am force-stop com.embarcadero.ProjectName

This can be useful to test what your app behaves like from a fresh restart, vs. just returning from the background.

The Android adb tool is very powerful. Most of these are using the shell command which actually allow you to pass commands to the modified Linux shell that runs inside Android. You can actually use “adb shell” to open a shell prompt and navigate your device like a remote machine.

If you have both an emulator running and a device attached then you can use the switch -d like

adb -d shell

and it directs it to the only device. If you use -e then it goes to the emulator.

When you have multiple devices then use -s and the device ID which can be obtained via the adb devices command.

There are so many other useful things you can do with adb. Check out the documentation.

The Delphi Wiki has a much more exhaustive Supported Android Devices list. It also includes the new Nexus 5 (running Kit Kat), Google Glass and Droid Razr M, to name a few. At the bottom of the list there are some BlackBerry devices listed too, all of which are either not tested, or not supported. Curious to see if any of those end up working

There is also a link to some easy to follow testing instructions if you want to test your own devices, including some scripts to help automate part of the process.

Looking at the list it is obvious that there are more supported devices than not. Most pass over 80% of the tests too, of course it is always nice to see specific devices verified.

After getting Delphi 2007 to work again I tried to do the same for Delphi 2005 and 2006.

Both versions require the dotNET framework 1.1 which is officially no longer supported on Windows 8 (and 8.1). According to Microsoft, you should contact your independent software vendor (ISV) to have the application upgraded to run on the .NET Framework 3.5 SP1 or later version. Good luck with that.

This is odd, because I could install and use both Delphi versions on Windows 8. The installations broke only when Windows was updated to 8.1, so Microsoft is BSing us here, at least partly.

Reinstalling the “dotNET Framework 1.1 Redistributable Package” failed with some unhelpful error message.

Praise the Google, I found a solution on this site. The .NET Framework Cleanup Tool resolved that problem. After running it, letting it clean up the mess the update apparently made of the dotNET Framework 1.1 and rebooting, I could reinstall it.

Delphi 2005 started again, complained about something regarding “Star Team” which I just ignored / disabled, and behold, the IDE seemed to work.

The same with Delphi 2006. It too complained about “Star Team” which I again just ignored / disabled. It also seemed to work.

Beware: I haven’t done much more than starting both IDEs and compiling GExperts with it. So there might still be issues.

When I updated to Windows 8.1 my Delphi 2007 installation broke. I could no longer open projects in the IDE and my command line compilation scripts also stopped working. It turned out that some files that were added by the installer to the dotNET framework were missing. In addition there is a known problem with Delphi 2007 on 64 bit Windows (starting with Vista).

This is the error message from the IDE:

followed by this one which is more readable:

(click on the picture to get it in full size)

This is the error message from my build script:

D:\src\MyProject.dproj(77,11):
error MSB4019: The imported project
"C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Borland.Delphi.Targets"
was not found. Confirm that the path in the  declaration is correct,
and that the file exists on disk.

You might notice that the error messages slightly vary: The IDE complains about a missing file in …\Framework\ while the build script complains about the same file in …\Framework64\. I’ll come back to that later.

So here is what I did to fix it:

1. I let Windows search for the missing file Borland.Delphi.Targets and it found it in

   C:\ProgramData\{B59CE2E6-B15A-4F23-BD0E-72BF2ADDC3C7}\core\7EFD2DA3\6C948720
   

   (Unfortunately I had already deleted the backup that was created by the Windows Update process.)
   After looking closer into this directory I found 4 files that match Borland.*.Targets. It stands to reason that Delphi will need them all in one way or another so I just copied all 4 of them to

   C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
   

   After I did that, the IDE no longer complained and also was able to compile the projects.

2. To get the command line compile working again there are three options:
   • Some older advice I found on the net said to also copy these files to

     C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
     

     I didn’t like that approach because the build process is 32 bit, so why should it involve the 64 bit dotNET framework at all?

   • I found that for some reason the rsvars.bat script contained the line

     @SET FrameworkDir=C:\Windows\Microsoft.NET\Framework64\
     

     followed by

     @SET PATH=%FrameworkDir%%FrameworkVersion%;%FrameworkSDKDir%;%PATH%
     

     The Delphi 2007 installer is probably using some outdated method to find the dotNET framework, which works only on 32 bit Windows. I guess this was fixed in later versions.
     So another option to fix the problem is to change the FrameworkDir to point to …\Framework\ rather than …\Framework64\.
     I didn’t really like that approach either so I went for option 3.

   • I changed my build script to work around this issue:

     [...]
     set OldPath=%PATH%
     call "%DelphiDir%\bin\rsvars.bat"
     SET FrameworkDir=%SystemRoot%\Microsoft.NET\Framework\
     SET PATH=%FrameworkDir%%FrameworkVersion%;%FrameworkSDKDir%;%OldPath%
     

     (The actual build script is a bit more involved because it allows to call several different Delphi versions depending on an environment variable.)

After this change the build script worked again.

I hope this helps others to fix that problem, but I wrote this post mostly to find this information later if I need it again. ;-)

Just in case you are wondering:

Delphi 2006 and 2005 don’t work either. They are missing an older version of the dotNET framework which was there in Windows 8 but vanished in the update process. Thanks Microsoft! But there is a solution.

Delphi 7 still works. Delphi 6 has some issue with not finding its registration information that I haven’t looked into yet.

After getting Delphi 2005/2006 and 2007 working again the last stumbling block was Delphi 6.

It used to work fine on Windows 8 but after the update to Windows 8.1 it always started the registration wizard for a new activation. Unfortunately this activation did not work, I tried it twice, just to be sure. So, again I turned to the Google and found Code Singh: Virtualising Delphi 6 PC (Activation Errors)

The problem described there looked a lot like the one I was having so since I had nothing to lose, I just deleted the registry entry

HKCU\Software\Borland\Delphi\6.0\LM

(I did not make a backup, what would have been the point?)

I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.

Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.

So, now I have got working Installations of Delphi 6 to XE4 again.

XE3 and XE5 are missing, but I hope that’s just a matter of installing them.

Two missing parts of the standard VCL Styles is the lack of the capacity to theme the popup menus and the standard Windows dialogs. I started to work a year ago in the dialogs area, but due to my limited time I was not able to finish that. But a few months ago I receive a very interesting mail from Mahdi Safsafi (SMP3) that show me his own work on this topic. So we decided merge the code of his project and the VCL Styles Utils. So finally the VCL Styles Utils project was updated to support standard dialogs, popup and system menus.

How it works?

The key is using a WH_CBT Hook, detecting the HCBT_CREATEWND and HCBT_DESTROYWND codes and then checking if the class of the window is #32770 (the class for a dialog box.) or the #32768 (the class for a popupmenu) from here you can replace the window procedure (WndProc) using the SetWindowLongPtr function with the GWL_WNDPROC index. Now we have the control of the messages sent by the windows dialogs and menus and we can iterate over the child controls and replace the window procedure again using the GWL_WNDPROC index. Finally depending of the class of the control (button, syslistview32, Combobox and so on) a Wrapper class (like the VCL does) is created to handle the messages related to the paint of the control.

Check the next source code which install the hook and process the Win32 controls

unit Vcl.Styles.SysControls;

interface

implementation

uses
  Winapi.Windows,
  System.Generics.Collections,
  System.SysUtils,
  Vcl.Controls,
  Vcl.Dialogs,
  Vcl.Styles,
  Vcl.Themes,
  Vcl.Styles.PopupWnd,
  Vcl.Styles.EditWnd,
  Vcl.Styles.StaticWnd,
  Vcl.Styles.ThemedDialog,
  Vcl.Styles.ToolbarWindow32Wnd,
  Vcl.Styles.SysListView32Wnd,
  Vcl.Styles.ButtonWnd,
  Vcl.Styles.UnknownControlWnd,
  Vcl.Styles.ControlWnd,
  Vcl.Styles.ComboBoxWnd,
  Vcl.Styles.ToolTipsWnd;

type
  TThemedSysControls = class
  private
  class var
    FBalloonHint: TBalloonHint;
    FPreviousSysBtn: Integer;
    FPreviousHandle: THandle;
    FHook: HHook;
  protected
    class function HookActionCallBack(Code: Integer; wParam: wParam;
      lParam: lParam): LRESULT; stdcall; static;
    procedure InstallHook;
    procedure RemoveHook;
  public
    constructor Create; overload;
    destructor Destroy; override;
  end;

var
  MenuItemInfoArray: array of TMenuItemInfo;
  TooltipsWndList: TObjectDictionary<HWND, TooltipsWnd>;
  PopupWndList: TObjectDictionary<HWND, TPopupWnd>;
  StaticWndList: TObjectDictionary<HWND, TStaticWnd>;
  DialogWndList: TObjectDictionary<HWND, TDialogWnd>;
  EditWndList: TObjectDictionary<HWND, TEditWnd>;
  ComboBoxWndList: TObjectDictionary<HWND, TComboBoxWnd>;
  UnknownControlList: TObjectDictionary<HWND, TUnknownControlWnd>;
  ToolbarWindow32WndList : TObjectDictionary<HWND, TToolbarWindow32Wnd>;
  SysListView32WndList : TObjectDictionary<HWND, TSysListView32Wnd>;
  BtnWndArrayList : TObjectDictionary<HWND, TButtonWnd>;
  ThemedSysControls: TThemedSysControls;

{ TThemedSysControls }

constructor TThemedSysControls.Create;
begin
  inherited;
  FBalloonHint := TBalloonHint.Create(nil);
  FBalloonHint.Style := bhsStandard;
  FBalloonHint.Delay := 1500;
  FBalloonHint.HideAfter := 3000;
  FPreviousHandle := 0;
  FHook := 0;
  InstallHook;
  PopupWndList:= TObjectDictionary<HWND, TPopupWnd>.Create([doOwnsValues]);
  TooltipsWndList:= TObjectDictionary<HWND, TooltipsWnd>.Create([doOwnsValues]);
  StaticWndList:= TObjectDictionary<HWND, TStaticWnd>.Create([doOwnsValues]);
  DialogWndList:= TObjectDictionary<HWND,TDialogWnd>.Create([doOwnsValues]);
  EditWndList:= TObjectDictionary<HWND, TEditWnd>.Create([doOwnsValues]);
  ComboBoxWndList:= TObjectDictionary<HWND, TComboBoxWnd>.Create([doOwnsValues]);
  UnknownControlList:= TObjectDictionary<HWND, TUnknownControlWnd>.Create([doOwnsValues]);
  ToolbarWindow32WndList:= TObjectDictionary<HWND, TToolbarWindow32Wnd>.Create([doOwnsValues]);
  SysListView32WndList := TObjectDictionary<HWND, TSysListView32Wnd>.Create([doOwnsValues]);
  BtnWndArrayList := TObjectDictionary<HWND, TButtonWnd>.Create([doOwnsValues]);
end;

destructor TThemedSysControls.Destroy;
begin
  RemoveHook;

  PopupWndList.Free;
  TooltipsWndList.Free;
  StaticWndList.Free;
  DialogWndList.Free;
  EditWndList.Free;
  ComboBoxWndList.Free;
  UnknownControlList.Free;
  ToolbarWindow32WndList.Free;
  SysListView32WndList.Free;
  BtnWndArrayList.Free;

  FBalloonHint.Free;
  inherited;
end;

class function TThemedSysControls.HookActionCallBack(Code: Integer;
  wParam: wParam; lParam: lParam): LRESULT;
var
  Msg: TMOUSEHOOKSTRUCT;
  C: array [0 .. 256] of Char;

  procedure HideSysToolTip;
  var
    hSysToolTip: THandle;
  begin
    For hSysToolTip := 65550 To 65600 do
      begin
        If IsWindowVisible(hSysToolTip) then
          begin
            GetClassName(hSysToolTip, C, 256);
            ShowWindow(hSysToolTip, SW_HIDE);
          end;
      end;
  end;

  procedure ShowToolTip(HintTitle: String);
  begin
    HideSysToolTip;
    if FPreviousSysBtn <> Integer(Msg.wHitTestCode) then
      begin
        FBalloonHint.HideHint;
        FBalloonHint.Title := HintTitle;
        FPreviousSysBtn := Msg.wHitTestCode;
        FBalloonHint.ShowHint(Msg.pt);
      end;
  end;

var
  CBTSturct: TCBTCreateWnd;
  sClassName : string;
begin
    if (StyleServices.Enabled) and not (StyleServices.IsSystemStyle) then
    begin
      if Code = HCBT_SYSCOMMAND then
        begin
          FBalloonHint.HideHint;
          FPreviousSysBtn := 0;
        end
      else
      if Code = HCBT_DESTROYWND then
      begin
        sClassName := GetWindowClassName(wParam);
          if sClassName = '#32768' then
          {PopupMenu}
          begin
            if PopupWndList.ContainsKey(wParam) then
              PopupWndList.Remove(wParam);
            //OutputDebugString(PChar('remove PopupWndList count '+IntToStr(PopupWndList.Count)));
          end
          else
          if sClassName = '#32770' then
          {Dialog}
          begin
            if DialogWndList.ContainsKey(wParam) then
              DialogWndList.Remove(wParam);
            //OutputDebugString(PChar('remove DialogWndList count '+IntToStr(DialogWndList.Count)));
          end
          else
          if sClassName = 'Button' then
          {Button}
          begin
            if BtnWndArrayList.ContainsKey(wParam) then
              BtnWndArrayList.Remove(wParam);
            //OutputDebugString(PChar('remove BtnWndArrayList count '+IntToStr(BtnWndArrayList.Count)));
          end
          else
          if (sClassName = 'ScrollBar') or (sClassName = 'ReBarWindow32') {or (sClassName = 'ToolbarWindow32')} then
          begin
            if UnknownControlList.ContainsKey(wParam) then
              UnknownControlList.Remove(wParam);
          end
          else
          if sClassName = 'SysListView32' then
          begin
            if SysListView32WndList.ContainsKey(wParam) then
              SysListView32WndList.Remove(wParam);
          end
          else
          if sClassName = 'ToolbarWindow32' then
          begin
            if ToolbarWindow32WndList.ContainsKey(wParam) then
              ToolbarWindow32WndList.Remove(wParam);
          end
          else
          if sClassName = 'Edit' then
          begin
            if EditWndList.ContainsKey(wParam) then
              EditWndList.Remove(wParam);
          end
          else
          if sClassName = 'Static' then
          begin
            if StaticWndList.ContainsKey(wParam) then
              StaticWndList.Remove(wParam);
          end
          else
          if sClassName = 'ComboBox' then
          begin
            if ComboBoxWndList.ContainsKey(wParam) then
              ComboBoxWndList.Remove(wParam);
          end
          else
          if sClassName = 'tooltips_class32' then
          begin
            if TooltipsWndList.ContainsKey(wParam) then
              TooltipsWndList.Remove(wParam);
          end
      end
      else
      if Code = HCBT_CREATEWND then
        begin
          CBTSturct := PCBTCreateWnd(lParam)^;
          sClassName := GetWindowClassName(wParam);
          //PopupMenu
          if Integer(CBTSturct.lpcs.lpszClass) = 32768 then
              PopupWndList.Add(wParam, TPopupWnd.Create(wParam))
          else
          //Dialog
          if Integer(CBTSturct.lpcs.lpszClass) = 32770 then
            begin
              if (CBTSturct.lpcs.cx <> 0) and (CBTSturct.lpcs.cy <> 0) then
                DialogWndList.Add(wParam, TDialogWnd.Create(wParam))
            end
          else
          if sClassName = 'Button' then
              BtnWndArrayList.Add(wParam, TButtonWnd.Create(wParam))
          else
          if (sClassName = 'ScrollBar') or (sClassName = 'ReBarWindow32') {or (sClassName = 'ToolbarWindow32')} then
              UnknownControlList.Add(wParam, TUnknownControlWnd.Create(wParam))
          else
          if sClassName = 'SysListView32' then
              SysListView32WndList.Add(wParam, TSysListView32Wnd.Create(wParam))
          else
          if sClassName = 'ToolbarWindow32' then
            begin
              if not UseLatestCommonDialogs then
                ToolbarWindow32WndList.Add(wParam, TToolbarWindow32Wnd.Create(wParam));
            end
          else
          if sClassName = 'Edit' then
              EditWndList.Add(wParam, TEditWnd.Create(wParam))
          else
          if sClassName = 'Static' then
            begin
              { This condition can solve the Edit animated cursor : see ColorDialog !! }
              if (CBTSturct.lpcs.Style and SS_ICON <> SS_ICON) and
                (CBTSturct.lpcs.Style and SS_BITMAP <> SS_BITMAP) and
                (CBTSturct.lpcs.Style and SS_GRAYRECT <> SS_GRAYRECT) and
                (CBTSturct.lpcs.Style and SS_GRAYFRAME <> SS_GRAYFRAME) then
                  StaticWndList.Add(wParam, TStaticWnd.Create(wParam));
            end
          else
          if sClassName = 'ComboBox' then
            ComboBoxWndList.Add(wParam, TComboBoxWnd.Create(wParam))
          else
          if sClassName = 'tooltips_class32' then
            TooltipsWndList.Add(wParam, TooltipsWnd.Create(wParam))
        end
    end;
  Result := CallNextHookEx(FHook, Code, wParam, lParam);
end;

procedure TThemedSysControls.InstallHook;
begin
  FHook := SetWindowsHookEx(WH_CBT, @TThemedSysControls.HookActionCallBack, 0, GetCurrentThreadId);
end;

procedure TThemedSysControls.RemoveHook;
begin
  if FHook <> 0 then
    UnhookWindowsHookEx(FHook);
end;

initialization

  ThemedSysControls:=nil;
  if StyleServices.Available then
    ThemedSysControls := TThemedSysControls.Create;

finalization

if Assigned(ThemedSysControls) then
    ThemedSysControls.Free;


end.

Menus

Standard TMainMenu with VCL Styles Enabled.

using the Vcl.Styles.SysControls unit

SysMenu with VCL Styles Enabled.

using the Vcl.Styles.SysControls unit

System menu with VCL Styles Enabled.

System menu using the Vcl.Styles.SysControls unit

Dialogs

Open Dialog With VCL Styles enabled

Open Dialog using the Vcl.Styles.SysControls unit

Even the shell menu inside of the dialog is themed

Others Dialogs

You can activate this functionality in your apps just adding the Vcl.Styles.SysControls unit to your project. Also a new sample project was added to test all the new features.

As always all your comments and suggestions are welcome.

At the time of writing my two sessions for CodeRage 8 are being broadcast around the Arpanet.

I’ve got two session this year, both related to Delphi mobile development, and both concerning how to reach out from the island that is the FM Application Framework (aka FMX aka FireMonkey) and gain access to the underlying mobile OS platform APIs.

The first session is Accessing the iOS API and looks at how Delphi-written iOS apps can talk to the CocoaTouch APIs and access additional iOS frameworks. We look at the Objective-C bridge and see how it is used to import iOS APIs, namely classes and protocols (Apple’s term for what we call interfaces), and how you can implement iOS interfaces and inherit from iOS classes. We also briefly look at how to pull in APIs that are not already imported by Delphi’s RTL. As a proof of concept we briefly see a Delphi iOS app that has no FMX code or units in it whatsoever, operating purely through the iOS APIs using the standard CocoaTouch model.

Files from the Accessing the iOS API session can be downloaded from here.

The second session is Accessing the Android API and looks at how Delphi-written Android apps can talk to the Android SDK classes. We look at the Java bridge and see how it is used to import Android APIs. We’ll also look at how to pull in APIs that are not already imported by Delphi’s RTL. We also look at how to add a splash screen to an Android app to cover up the startup time on anything other than the fastest devices, how to add Android menus to an app and how to launch external activities and get results back from them.

Files from the Accessing the Android API session can be downloaded from here. Take note that since several of the samples involve various required preliminary steps in order to function, as they step outside the comfort zone of Delphi XE5 RTM’s Android support, you should check the ReadMe.txt files supplied in the project directories of those projects.

[Update]

I plan to write up some of the subjects covered by these demos in further posts or articles as time and work schedules permit. However in the mean time I’ll respond to comments by expanding this post as necessary.

It appears that when the small Java source files get compiled, the Android dx tool expects them to be compiled by the JDK 1.6.x compiler as opposed to the JDK 1.7.x compiler. If you have JDK 1.7.x installed, you hit a problem with dx reporting:

bad class file magic (cafebabe) or version (0033.0000)

However, to avoid forcing a reinstall of JDK 1.6 you might like to modify my build.bat batch files and add in extra command line switches to the javac.exe command-lines. You need to insert this after the javac.exe command to force Java 1.6 byte code output, which is digestible by the Android dx command:

-source 1.6 -target 1.6

For anyone that’s been waiting for the replay videos from CodeRage to go up and has been getting impatient as the suggested 2 week window has come and gone, relief is now available as the replay videos are all there.

You can find them on YouTube on the Embarcadero TechNet page, or on the original CodeRage 8 session page.

Well, ok, maybe as I type one or two are still slowly dribbling onto the Internet and maybe the sessions page hasn’t quite got all the video links on board, but the majority are accessible in one way or another on YouTube at last.

I’ve updated my CodeRage 8 session files post to include the video links to my talks in case anyone wants to check them out. Enjoy!