Cross platform FMX/XE3 demos for CCR Exif

I’ve just added a set of FMX demos in the SVN trunk for my image metadata reading/writing library, CCR Exif. These are ports of the existing VCL demos (minus the resaving tester). In alphabetical order, they number the following:

  • ExifList displays the Exif tags from an image, Exif being the metadata format most cameras use.
  • ExifTimeShifter shifts the Exif date/times for one or more images by a specified number of minutes.
  • IPTCEditor edits the IPTC data held in an image. IPTC is the metadata format Photoshop used back in the 1990s, and makes for a slightly lower-tech alternative to Exif.
  • JpegDump displays information from a JPEG file’s header, providing a lower-level view of its metadata tags than the other demos.
  • Screenshooter takes a screenshot, applies a few tags, and saves to a new JPEG file.
  • XMPBrowser displays XMP metadata in a tree view, XMP being a newer, XML-based metadata format.

While the FMX demos (which require XE3 by the way) mostly hew to the line set by their VCL forebears, I began with a blank slate in each case. This I did because I wanted certain UI details to follow the target platform (i.e., Windows or OS X), and in so doing, see what FMX did to help, or at least, see how far it wouldn’t get in the way.

Screenshooter and ExifTimeShift

The simplest demo to port was Screenshooter, since the FMX version has almost exactly the same UI for both platforms. The only difference is the fact the Mac version has the regular Mac menu bar; however, the menu items on it are just the standard ones that FMX in XE3 set up for you automatically:

Similar between platforms too is ExifTimeShift:

In this case there are some subtle differences though:

  • I hide a few toolbar buttons on OS X because toolbars on a Mac just tend to have less items than their Windows equivalents.
  • The Preferences/Options dialog is non-modal on OS X, with no explicit OK/Cancel buttons and changes applied immediately. (I leave aside whether this makes for a better UI – in fact, I think I prefer the Windows model myself – but that is the contemporary Apple style.)
  • On both platforms, double clicking a listed file displays the image. On Windows the image window gets its own taskbar button; on OS X it is full screen-enabled – you can see this in the screenshot with the double arrow icon on the title bar – and listed under the application’s Window menu. While I had to implement these things manually, it wasn’t hard, though I’d admit the Windows part requires more work (the FMX developers are unfortunately obsessed with a Win 3.x/VCL-style ‘main form’ concept that isn’t technically native even on Windows).
  • The file date/time preference is saved to the Registry on Windows and the application’s preferences file on OS X. Since I didn’t want to introduce dependencies, the latter is done by direct API calls, though in practice I would use my own Mac Preferences API wrapper I blogged about previously.

ExifList, IPTCEditor and XMPBrowser

The main platform difference between the remaining demos is much more ‘in your face’: whereas on Windows the applications are SDI, on OS X they follow the basics of the Mac document model. As such, if you run ExifList, IPTCEdit or XMPBrowser on OS X without passing the application a file first, it opens with no window showing. This follows what Preview does:

Further, whereas the same instance of the Mac version can have multiple images open, each with their own window (and enumerable using the system-standard Cmd+` shortcut), you need to open the Windows version several times to have it load several images at the same time:


Each demo is essentially single source, and structured around my preferred VCL UI model. In this, the document form’s OnClick code is all centralised into action lists located on a data module separate from the form itself, with any necessary communication between the actions and the form being performed via interface types. A unit shared between all the demos (CCR.FMX.Demos.pas) then contains all the platform-specific UI-related code, and manages the differences between the different document models (no form is auto-created in the traditional Delphi fashion, and the document form class itself is looked up using RTTI). Alas, but that unit also implements certain crucial bug fixes for FMX itself, though at least the new IFMXxxxService system (see my previous-but-one post) made that bareable. I’ll probably blog about it in more detail later.

11 thoughts on “Cross platform FMX/XE3 demos for CCR Exif

  1. I realise this is n00b beyond belief, but I have read the guides I could find on adding components, and now need help. There are guides but they are from D7 and such old beasts. So, I had to improvise a bit:

    I fire up XE3, select “Install components”, Select ccr.exif from where I depacked it and select to a new package. I give the name ExifPackage as package name.

    I get that the CCR.exif uses TYPES and wants to add the FMX framework, and this is ok. I get the error message that jpeg.dcu is not found.

    Here I don’t know what to do and don’t know how to proceed. Would welcome ALL and ANY help with installing components.

    My ambition is to write a program that “syncs” exif date/time between camera contributions. I guess we have all seen it sometimes – you get pictures from different people, and you’d like to show them in a sequence as per the photo time. People have cameras with the time setting set differently. Some using DST and some not, whereas some are just wrong. I normally use ACDSee to rename based on exif metadata, but that turns random due to the exif time errors.

    Each contributor has their picture containing a time delta per picture which is correct, but the absolute time might be totally wrong, and my ambition is to give them all an aboslut which is correct.

    • Hello

      You don’t need a package – while certain classes descend from TComponent, they aren’t things you need to install in the IDE – once you have the code downloaded, you should be able to open up the demos and compile straight away. If you want the library itself generally available, you need to (a) open up the demos and do a Project|Build All (b) add the DCU folder to your library path via Tools|Options, Environment Options -> Delphi Options -> Library. There are two complications however:

      1. While it was never a VCL-based library, my code does use standard graphics classes to make things a bit more usable. Unfortunately the VCL and FMX graphics classes are different though, and it is impossible for code to discover whether it is being compiled in a VCL or FMX context without a custom conditional define. If you want DCUs for the VCL, then a conditional define named ‘VCL’ must exist, and for FMX, one called ‘FMX’. In practice, this means you just need to open up and compile the applicable GUI demos project group (‘FMX Demos.groupproj’ or ‘VCL Demos (XE+).groupproj’) to get the code compiled with the right dependencies.

      2. XE3 (and XE and XE2) have a more complicated build configuration compared to the old days, partly given the support for multiple platforms and partly by surfacing the idea of distinct ‘debug’ and ‘release’ builds (before you had to configure such a division without the IDE’s help). In practice this means you may want to compile my code multiple times using different build configurations. This will generate multiple sub-directories under the top level DCU folder.

      If you need more help, let me know and I’ll blog about it in more detail.

  2. So I open the “VCL Demos (XE+).groupproj” file, build it and then just add the path to the dcu:s in my project? Gotcha – worked. THANKS!!!

    In case I want to permanently add it to the IDE and be able to add it to any project by having it added in the tool palette. Is that a big mess to achieve?

    I would warmly suggest you strive to describe in the documentation/PDF file how to add it, as you might have n00bs that get scared off by needing to ask. Not pushy ones such as myself 😉

    • “In case I want to permanently add it to the IDE and be able to add it to any project by having it added in the tool palette.”

      The ‘by having’ doesn’t actually follow, and never has – installing into the IDE is one thing, adding the DCU folder to the library path another. Mind you, every so often I forget myself, but from the opposite direction – I install a BPL, have the custom components work fine at design time, then wonder for a few minutes why the ?!#& thing doesn’t compile!

      “I would warmly suggest you strive to describe in the documentation/PDF file how to add it”

      When I have the time… Unfortunately, this is one thing that has definitely got worse since I first released the code, but it can’t really be helped so long as I want to support both the VCL and FMX.

  3. Thanks for the CCR Exif, it works great.
    What about support for XE4 and XE5, where I get some warnings:

    [dcc32 Warnung] CCR.Exif.BaseUtils.pas(1324): W1000 Symbol ‘StrPLCopy’ ist veraltet: ‘Moved to the AnsiStrings unit’
    dcc32 Warnung] CCR.Exif.TiffUtils.pas(1607): W1000 Symbol ‘Seek’ ist veraltet
    dcc32 Hinweis] CCR.Exif.XMPUtils.pas(376): H2443 Inline-Funktion ‘TTimeZone.GetUtcOffset’ wurde nicht expandiert, weil Unit ‘System.TimeSpan’ in der USES-Liste nicht angegeben ist
    [dcc32 Warnung] CCR.Exif.XMPUtils.pas(1799): W1000 Symbol ‘StrLComp’ ist veraltet: ‘Moved to the AnsiStrings unit’
    [dcc32 Warnung] CCR.Exif.pas(6168): W1000 Symbol ‘StrLComp’ ist veraltet: ‘Moved to the AnsiStrings unit’

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s