When I’m head-down in a ‘long hours’ contract I tend to miss quite a bit of Delphi-oriented news. Once in a while I look up and I find a whole host of interesting posts around the blog-world and this has been the case over this seasonal break.
I’ve been browsing around seeing what’s new and have collated the following list of stuff I found interesting. Anyone else who hasn’t been keeping up-to-date on news of late might possibly also find some stuff of interest in the list.
Happy New Year!
It’s been a while now since I posted up the link to my Delphi service example on Google Play.
I mentioned at the time that it was not a trivial exercise and was somewhat imperfect in implementation (although I’d done my best to disguise this fact). Indeed you only really see an issue if you are looking at the logcat output from the app (either using the command-line adb logcat command, or using the deprecated DDMS tool or the replacement Monitor tool). Alas the app dies while endeavouring to tidy up for exit…
I also mentioned at the time that I was hoping to work out some scheme to remedy the situation before releasing the example source, something to do with pride or perfectionism or some such… Anyway, with the day job, the evening job, the prep work for last week’s Be-Delphi 3.0 event in Belgium my plans haven’t been accomplished and I have still to work out if it’s feasible to clean up the shutdown part of the sample. All my current efforts have come to little in resolving it.
So, given that there have been a number of requests for the source I have now made it available at this download link. This is the same as the sample online other than it has no splash screen. This example is free of a splash screen to simplify the example and leave it clearer. There are a couple of examples that incorporate a splash screen and have similar custom build steps available in my CodeRage 8 session files.
Please note that the archive has a Readme file in it, and you should take the time to read through this file carefully as it explains the non-standard build steps required to get the sample successfully built for deployment. If you don’t follow the Readme file, then you’re unlikely to get any joy with the sample at all.
For your convenience I include the text of the ReadMe file below.
As you will see, since Delphi has no catering for building Delphi services or broadcast receivers, I’ve had to go “round the houses” to do it, using Java stubs, and pertinent thread-switching between the Java and Delphi threads.
As you will also perhaps appreciate, I don’t recommend this as a productive way of building an Android service. However if you need to add a service to a Delphi Android application, then this approach allows you to do so.
But… as of the time of posting there is a still the small matter of a (slightly brushed under the carpet) death-by-tombstoning bug on shutdown. If any keen reader can work out a clean way of closing I’d be most obliged to hear of it!
[Update]
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
[Update 2 – Feb ‘15]
There has been a longstanding issue with my service sample, which I originally wrote for Delphi XE5.
The issue was that when updated and tested in Delphi XE7, it hung on startup with a black screen. This was rather disappointing.
Unfortunately I’ve been very much tied up with stuff and haven’t managed to get to looking into the problem up until now. Anyway, Aleksey N’s comment (below) put me onto the way of getting it to work. The OnCreate handler now triggers a timer to start the service, after the initialisation process.
The download sample project now incudes both a Delphi XE5 and a Delphi XE7 project. Enjoy!
Service example
===============
This project implements an Android service along with a couple
of broadcast receivers to catch and respond to intent messages
flung around the system. The service and receiver classes are
implemented as extremely shallow Java classes, which need to be
compiled and converted to an appropriate executable format
(dex), and then merged into the other dex code deployed with an
Android app.
The Java code calls into native Delphi code to implement
the "business end" of the service and receivers.
Build the Java support files:
----------------------------
In the project's java directory are some source files:
- java\src\com\blong\test\ActivityReceiver.java
- java\src\com\blong\test\SampleService.java
- java\src\com\blong\test\ServiceReceiver.java
These need to be compiled to .class files, archived into a .jar
file, converted from Java byte code to DEX (Dalvik Executable)
format and merged into the normally used (by Delphi's Android
deployment process) classes.dex.
To set this up, follow these steps:
- Ensure the useful subdirectory of Android SDK's build-tools
directory is on the system PATH (e.g. C:\Android\android-sdk-
windows\build-tools\18.0.1 or C:\Users\Public\Documents\RAD
Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522
\sdk\android-4.2.2)
- Ensure the Java Development Kit's bin directory is on the
system PATH (e.g. C:\Program Files (x86)\Java\jdk1.6.0_23\bin)
- Run a command prompt in the project's java subdirectory and
ensure you can successfully launch each of these:
- javac
- jar
- dx
- Review the build.bat file and ensure the environment
variables are set correctly:
- ANDROID needs to point to your Android SDK base
directory, e.g. C:\Users\Public\Documents\RAD Studio\12.0
\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk or
C:\Android\android-sdk-windows
- ANDROID_PLATFORM needs to point at an installed SDK
platform installation, e.g. %ANDROID%\platforms\android-15 or %
ANDROID%\platforms\android-17. Check for one that is installed.
- DX_LIB needs to point to the lib subdirectory under the
Android SDK build-tools directory, e.g. %ANDROID%\build-
tools\18.0.1\lib or %ANDROID%\build-tools\android-4.2.2\lib
- EMBO_DEX needs to point to the Delphi-supplied Android
classes.dex file, wrapped in quotes to take care of any spaces
in the path, e.g. "C:\Program Files (x86)\Embarcadero\RAD
Studio\12.0\lib\android\debug\classes.dex"
- Run build.bat
- You should now have a new file in the project directory tree
called java\output\dex\classes.dex
This file replaces the supplied classes.dex and has the Java
service and broadcast receiver compiled classes included in it.
Set the new classes.dex for deployment:
--------------------------------------
Open the project in the IDE
Choose Project | Deployment
Note that the classes.dex file from the project's
java\output\dex directory is set to be deployed.
You must ensure that the default classes.dex file is de-
selected. As you switch configurations, this de-selection will
be lost (the file will be re-set to be deployed) and will need
to again be de-selected. This is an IDE bug with Delphi XE5 RTM
and XE5 UP1 and is logged in Quality Central as bug 118472.
Register the service:
--------------------
This has already been done for this demo. It involves the
following:
- Open the Android manifest template,
AndroidManifest.template.xml, which is generated on first
compile, from the project directory
- Add in a description of the service in the application
element:
<service android:name="com.blong.test.SampleService" />
Build the Delphi Android application library:
--------------------------------------------
In the IDE choose Project | Compile ServiceApp (or press
Ctrl+F9)
Deploy the library to an Android application package (.apk):
-----------------------------------------------------------
In the IDE choose Project | Deploy libServiceApp.so
Install the app on the device:
-----------------------------
In the IDE choose Run | Run Without Debugging (or press
Ctrl+Shift+F9).
This will implicitly do the compile and deploy steps above, so
they are actually optional.
This step will uninstall the app if already installed and then
install the newly built version.
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!
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.
-source 1.6 -target 1.6I was put onto this treasure trove of old scanned manuals the other day: http://bitsavers.informatik.uni-stuttgart.de/pdf/borland. It contains a huge directory hierarchy of PDF scans of old product manuals from all sorts of vendors. And that’s scans of the whole manuals, not just the front covers.
Want to brush up on your Turbo Pascal 7 language? Or review the details of the Turbo Pascal Graphix Toolbox (all the Turbo Pascal manuals are here, while Turbo C manuals are here and Borland C++ manuals are here)? Or recollect the specific of Sidekick Plus (Sidekick manuals are here)? Or be reminded how Turbo Prolog worked (Turbo Prolog manuals are here)?
All this and more are there as PDFs. And not just old Borland manuals. Oh no, browse up the directory tree and you can find oodles of stuff on say, the Apple Lisa (Apple’s manuals start here and the Lisa manuals are here).
What a great resource for those who like to look back from time to time :o)
Take a browse through and see how many product manuals you’ve forgotten all about.
Ahhh, product manuals. Those were the days!
Oh, and while on the subject of manuals, back in the day the Borland documentation team did like to have a bit of fun in their work. The Delphi 1 manuals contained a couple of Easter Eggs.
For those Pascal programmers looking at building Android applications, be it with Delphi XE5 or with Oxygene for Java (I work with both!), here are a few Android-related resources that may come in useful:
Once upon a time there was colour and interest a-plenty in development tool splash screens. Well, this was certainly the case with Delphi and C++Builder anyway.
And then corporate America took over and things dulled down with an unmistakable business-like tone.
Take a look through the progression of splash screen I have here and see if nostalgia strikes.
1997: Delphi 3
1998: C++Builder 3
1998: Delphi 4
1999: C++Builder 4
1999: Delphi 5
2000: C++Builder 5
2000: JBuilder 4
2001: Delphi 6
2002: Delphi 7
2004: Delphi 2005
2005: Delphi 2006
2007: Delphi 2007
2007: C++Builder 2007
2008: Delphi 2009
2008: C++Builder 2009
2009: Delphi 2010
2010: Delphi XE
2011: Delphi/RAD Studio XE2
2012: Delphi/RAD Studio XE3
2013 – Delphi XE4
2013 – Delphi XE5
Good to see prompt Delphi support for iOS 7, as reported by Embo’s Sarina DuPont. It’s out and available for download from the registered users site a mere 1 day after iOS 7 was released.
Documentation for the new support is on the docwiki.
I can’t help noticing, though, that it appears to be an XE5-only update. This is not good news for those still beavering away with iOS code in XE4.
I’m sure I remember hearing talk of support for iOS 7 shortly after iOS 7’s release for XE4 iOS programmers.
Let’s hope there’s an XE4 update to follow real soon, otherwise this will throw another bone of contention into the mix, and the blogosphere will once again be alight…..
Blimey, that took me by surprise (again)! I figured it was coming fairly soon, but I didn’t realise quite that soon.
Anyway, Delphi XE5 is here (as is RAD Studio XE5 and siblings), as Tim Del Chiaro on his Delphi Insider blog.
The Trial Edition is up and available for download and those with Software Assurance should have access to the full version.
You can get a run down of what’s new in the XE5 doc wiki – specifically the What’s New page, but there’s also a general What’s New page. However the thrust of this release is all about adding Android to the portfolio of supported target platforms, with the suggestion that you can get applications compiling for both iOS and Android from a single source base.
But before getting bogged down in Android it’s worth mentioning these new features:
Ctrl+. or F6) is no longer a modal dialog but is now a search box TListView search filtering support Also there have been a bunch of iOS fixes along the way, as you’d expect.
The full Delphi range of platform targets now covers:
This is achieved with this half dozen compilers:
Because the Delphi compiler generates native machine instructions, its output is processor-specific. In other words it doesn’t target the Dalvik Virtual Machine, where regular Android applications reside, which are basically Java p-code applications that are executed by a variant of the Java VM. Instead it generates raw machine code, as all the current wave of Delphi compilers do (the long gone Delphi for .NET was the exception to this general rule). So because it’ a compiler compiling native machine instructions Delphi’s Android support has the following requirements:
These requirements appear here and there in the documentation, mostly concurring with itself: 1, 2, 3. [Update: the 3rd link is new and also lists various devices that FireMonkey apps have been tested on]
[Edit: It should be noted that the Android emulator is an *emulator* – it emulates ARM instructions when set up as an ARM emulated device. This is in contrast to the iOS simulator, which simulates an iOS device by running an Intel code version of the app, where the real iOS app again will be built with ARM instructions for the iOS device ARM chip. The implication of this is that the performance is atrocious and extremely disappointing for most. As Warren Postma details in XE5 Trial Download and Install Experience, you would really be advised to get a cheap Android tablet to test on, and use the emulator as a last resort.]
[Edit: I should add that if you are going to get a cheap Android device to test your apps then you should most definitely take steps to ensure it meets the minimum specifications required by a Delphi application – it must have an ARMv7 chip that supports NEON instructions and be running an appropriate OS version. Thanks for the reminder on that, Jolyon]
How do you find out if your device is supported? Well, the OS version you can find out in the Settings. The path and menu items may vary but goes roughly like this: Settings, About phone (or tablet), Software information, Android version.
To check the CPU details you’ll need to run one of the tools from the Android SDK against your connected device. Delphi installs the Android SDK and NDK if you don’t tell it you have it pre-installed. The Android SDK gets installed into a directory something like: C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk. In the platform-tools subdirectory from there is the Android Debug Bridge, adb.exe.
To run a command against your device it needs to be connected, typically by USB. This requires you to install an appropriate USB driver for your device as the ones located by Windows typically don’t do the job. Refer to the helpful The Delphi Geek blog post on the matter, XE5 and USB Drivers, for more information and links to drivers for the more common Android phone manufacturers.
When your phone is connected you’ll need to launch a command prompt and run an adb command. This may be easiest if you change directory to the platform-tools subdirectory (or Shift+right-click on the platform-tools folder in Windows Explorer and choose Open command window here). Firstly run the command:
adb devices
just to prove that your device can be seen by the Android tool chain. Assuming it can, run:
adb -d shell cat /proc/cpuinfo
This will show you CPU information something like this:
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 13.52
processor : 1
BogoMIPS : 13.52
processor : 2
BogoMIPS : 13.52
processor : 3
BogoMIPS : 13.52
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x1
CPU part : 0x06f
CPU revision : 0
Hardware : UNKNOWN
Revision : 0003
Serial : 0000000000000000
Check the Processor line to ensure you are running ARMv7. In the Features line check that neon is included in the CPU feature list
There have been various events worldwide over recent fays and more coming in the days ahead, spreading the word about the new Android support in Delphi XE5. Today I attended the London event, which was held in a theatre in the Natural History Museum.
Embarcadero’s JT was over to help with the launch, and also on stage were Jason Vokes and Steve Ball.
I was a long way back in the audience with the zoom on my telephone’s camera on maximum. But this was the theme for the day.
If you are keen to try out Delphi’s Android support, go right ahead and start downloading and installing. However I would urge you to read up on how Android development works whilst the download/install process takes place. There are many docwiki pages that help you get a handle on how it all fits together with the main entry point here: Android Mobile Application Development. A whole bunch of subtopics are listed here.
Recent posts about Delphi’s Android support, which pre-dated today’s launch, include the following:
In a previous blog post I discussed the Objective-C Bridge, available when building iOS apps. This is part of the RTL that allows Delphi code to interact with Objective-C API code. Objective-C code is compiled native code and Delphi code is compiled native code, so the bridge allows the two sets of code to get along. You can define Delphi versions of iOS classes (rather akin to how you can declare Delphi versions of Win32 API functions in classic Delphi), create instances of Objective-C classes, inherit from Objective-C classes and generally do what is necessary to access parts of the CocoaTouch API that are not consumed and surfaced by FireMonkey or parts of the API that do not have similar behaviour exposed by FireMonkey.
Oh, I should mention it’s not so much called FireMonkey now. It seems to be getting referred to more and more as the FM Application Platform. I suspect the latter sounds a little more “business”-y.
Anyway, the Android support offers a similar API bridge called the Java Bridge. Now the Android SDK classes are Java classes living in the world of the Dalvik VM. Delphi code is machine code running on the CPU. This is different to the iOS case. So the Java Bridge uses JNI to communicate across the native/managed boundary but basically offers broadly similar behaviour. You can declare Delphi versions of Android classes, create instances of them and communicate with them. So aspects of the Android API that do not get employed by regular Delphi apps can be accessed for the most part.
One shortcoming of the Java Bridge is that you cannot inherit from a Java class, which makes certain things rather tricky. However I’m going to write up my understanding of the Java Bridge and Objective-C Bridge in additional fuller articles with various examples over coming months, and try and offer ways around the Java Bridge shortcomings. Watch this space. Well, ok, you’d do better to read up on all the Android backgrounders in docwiki while downloading and installing XE5 :o)
Here are some more Embo pages for you to chew over and apply due consideration to:
Working on some Delphi projects with some clients over recent weeks has thrown up a number of tips that have been well-received so I thought I’d write them up for a more global audience.
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 MSJ article 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.
Update: Just 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.
The old TList class is still a useful beast, even if in many cases we should be using the newer generic TList<T>. 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, add a watch that casts the address shown in the inspector to a TObject and call its ClassName method – don’t forget to ensure the watch is set to allow side effects and function calls when adding it.
This tells you the type. Now you can bring up an inspector for the currently unhelpful point 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:
For bonus points you can identify the target type in the CPU window’s memory pane rather than the watch 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. In the case above the first pointer in the list had the value $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.
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!
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.
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.
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.
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.
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
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%
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.
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 Editor Options.
Yes, yes, there are reasons why it gets it wrong – it’s not using the exact same 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 QC and vote for it/them.
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.
Many of you will have already bumped into this information, but I’m posting it for the benefit of those who haven’t come across it.
In much the same way as how the static RAD Studio online documentation is complemented by updatable and updated web-based documentation at http://docwiki.embarcadero.com, the sample applications supplied with RAD Studio are also updated over time and available via an online Subversion repository hosted at SourceForge.
The RAD Studio Demo Code Web Site is at http://radstudiodemos.sourceforge.net and the SourceForge project page is http://sourceforge.net/projects/radstudiodemos. To pull down the demos you can use your favourite Subversion client and use the checkout functionality.
With regard to Subversion clients I like using TortoiseSVN from within Windows Explorer, although there is also a TortoiseSVN plug-in for the RAD Studio IDE. Of course if you use Delphi XE or later you can perhaps more sensibly just use the built-in RAD Studio IDE Subversion support.
Suitable Subversion repository URLs for the RAD Studio demo projects include:
From time to time you can again use your Subversion client to update the demos to take advantage of any changes made in the online repository. It’s good to be kept up to date!
Above I touched on the online up-to-date documentation. For completeness I should mention that the docwiki is available from Delphi’s Help menu (RAD Studio Docwiki) and I should also offer up this list of entry pages to the online help systems:
Finally, it’s always nice to get a refresher on what’s been added in recent product releases, so do stop by the What Was New In Past Releases page on the docwiki.
The typical current requirements of the customers I work with, so they tell me, are to stick with Windows + VCL thanks to the long-term projects they have ongoing. Because of this I’ve not really spent too much time getting to know FireMonkey in excruciating detail since it was introduced. However, given that the quintessence of the XE4 release has been iOS support and this typically† revolves around using FireMonkey, I figured maybe it was about time to roll the sleeves up and get stuck in.
This post is a summary run-though of the things I bumped into, how I got on, what I figured out, what problems I encountered and how I achieved a few things whilst checking out the latest platform-targeting in the Delphi product line.
Ah, it’s been released… The May 2013 release of Oxygene, released on 27th May 2013, brings us Oxygene 6.0, and Oxygene 6.0 brings us the official release of Oxygene for Cocoa.
The Oxygene language now gives ways of coding for all the currently interesting platforms using the three available editions of Oxygene:
Oxygene is hosted in Visual Studio 2012 (support for Visual Studio 2010 has now been phased out in Oxygene 6.0). If you don;t have a copy of Visual Studio 2012 the Oxygene installer can set up the Visual Studio 2012 shell first.
For existing users of Oxygene for .NET and/or Oxygene for Java there are some new features added to Oxygene 6.0, including a spate of new conditional defines to help distinguish which compiler built your code or which platform you are targeting:
| Oxygene 6.0 edition | Edition define | Platform define | GC/ARC define |
| .NET | ECHOES | DOTNET | GC |
| Java | COOPER | JAVA | GC |
| Cocoa | NOUGAT | COCOA | ARC |
However the main thrust of the release is Oxygene for Cocoa, which works in conjunction (if you want) with Apple’s UI designer to support visual UI design via nib (.xib) files or storyboard files. It also understands and fully supports multi-part method names so that it fits in directly with the Objective-C naming system and can represent and refer to any existing methods. It support the iOS Simulator, supports debugging there and on-device and offers all the options needed to sign and provision your apps. It supports ARC (automatic reference counting), understands bridging and uses an LLVM back-end to generate good ARM and 64-bit Intel code.
It ships with all the standard frameworks imported and has a tool that allows you to import any additional libraries you need to work with. Because Oxygene always uses the frameworks that natively exist on the target platforms, there is not an awful lot to learn specific to Oxygene when building Mac or iOS apps. Anything you learn on the Internet about how to build aspects of Mac/iOS apps applies directly – it’s just a case of expressing the various local API calls in the Oxygene syntax, which is a very familiar Object Pascal based syntax.
During pre-release development Oxygene for Cocoa was called Project “Nougat” and I worked with it a lot to keep tabs on how it progressed. I’ve built a whole bundle of test apps to keep on top of (mostly) iOS application development techniques by simply following various online Objective-C tutorials, and just entering the code in Pascal instead of in Objective-C.
I’m delighted Oxygene for Cocoa is now released as I’ve been productive with the tool for quite a long time now. I’ve wanted to make blog posts about how I do thing with it, but given it’s just a syntax shift there hasn’t really been much of a need for it. I guess maybe I’ll do one at some point to show the basics of building up an iOS app in the Visual Studio IDE and getting it launching in iOS Simulator, but after that it’s just writing code in the same way any other iOS developer does; just in Pascal.
On June 17th I’ll be demonstrating the product with a talk at a Developers Group meeting in Maidenhead, UK.
You can find more information about Oxygene for Cocoa at these links:
Buying Oxygene is reasonably pocket-friendly. If you’re new to it then $699 gets you all three versions. Otherwise there is a $499 renewal price for existing Oxygene for Java or Prism customers, a $599 cross-grade price for any users of Embarcadero Delphi or of older Embarcadero Prism versions (XE2 and below) and also a $99 academic price.
If you want to see how you get on with Oxygene 6.0 without committing you can always pull down a trial version first.
