CCR Exif v0.9.5b

Thanks goes to commentator Andreas, who found a nasty regression in 0.9.5 of CCR Exif when compiling in D2009.  Basically, TExifSection.SetStringValue was missing a cast, slicing the new string value into two. The perils of not being able to test against the D2009 compiler, eh? Beyond that, I’ve also fixed a few (non-breaking) issues in D2009 concerning how ASCII tags are now exposed as normal strings, so if you’ve downloaded my code and are using D2009, please download it again from the same location.  Note that I haven’t integrated this fix yet — I just wanted to remove the regression first.

[Update a day later: urgh, another one, this time an empty ‘type’ block causing a compile-time error in D2009 — fixed and uploaded once again. Current revision is thus 0.9.5b, though as said, there is nothing different for non-D2009 users between the various 0.9.5 versions.]

Advertisements

2 thoughts on “CCR Exif v0.9.5b

  1. Your code is running fine in D2009. Thank you. Even date/time written in Exif-format yyyy:mm:dd is now displaying correctly in Exporer properties (dd.mm.yyy in my case). So there is no need for further conversions.

    There is a small glitch left concerning D2009. I’ve to comment out type declaration here in ccr.exif.pas to get it compiled:

    { Backfill standard types for older Delphi compilers }

    //type
    {$IF not Declared(TBytes)}
    TBytes = array of Byte; //added in D2007
    {$IFEND}
    {$IF not Declared(RawByteString)}
    RawByteString = AnsiString; //added in D2009
    {$IFEND}
    {$IF not Declared(UnicodeString)}
    UnicodeString = type WideString; //added in D2009
    {$IFEND}

    HTH.

    • Thanks for confirming. Re the other issue (grr, another regression) — the error, I assume, is from the compiler not allowing an empty ‘type’ block (nothing new in D2009, so I should have noticed it). For a D2007-compatible fix, just move the definitions to below the next ‘type’ statement and delete the first. That way, something will definitely be defined within the block (namely, EInvalidJPEGHeader and so on) even if TBytes etc. are $IF’ed away. Revised version should be up now — hopefully there won’t need to be a v0.9.5c…

      [If anyone’s wondering — I updated the original post after writing this comment.]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s