Two FireMonkey nasties

As the title says, here’s two little FireMonkey nasties I’ve got round to QC’ing that may be of interest to someone starting to play around with the framework:

  1. TBitmap.LoadFromFile does not raise an exception when the file does not exist – instead, it just silently returns (see QC 102636).
  2. TFmxObject.Children (which is equivalent to TWinControl.Controls in the the VCL) always returns nil on an out-of-range index rather than raising an exception. Combined with the fact the ‘as’ operator accepts a nil source, this causes typos to generate nasty, generic access violations rather than exceptions that tell you what the error actually is (see QC 102747).
Advertisements

3 thoughts on “Two FireMonkey nasties

  1. Hi Chris,

    I have noticed you submitted a number of bugs for MacOS on Quality Central.

    I was wondering if you could help me in anyway in terms of getting started of converting other MacOs interfaces not available in XE2 and even its possible. I’m at a loss unforunately…

    http://stackoverflow.com/questions/9577901/how-to-convert-additional-objective-c-frameworks-not-included-in-delphi-xe2

    Any assistance would be greatly appreciated.

    Kind regards
    P

    • You are on the right lines:
      – The GUID is necessary under normal Delphi interface identity rules, but can be anything (the Objective-C classes don’t have GUIDs).
      – You don’t need to convert every single method due to the dynamic nature of Objective-C, however the method and parameter names for the ones you do translate must match *exactly*.
      – Names must match because Objective-C is case sensitive, and disambiguites overloaded methods by parameter name not parameter type.
      – Methods must all be declared cdecl.
      – Do not add the framework to the Delphi remote profile. However, declare and call an exported flat function from the framwork at startup (either through static or dynamic linking), otherwise its classes will not be registered with your application when you try to instantiate them. This is necessary even for basic Cocoa frameworks if something else (typically FMX) doesn’t do it for you (cf. https://delphihaven.wordpress.com/2012/01/09/writing-delphi-console-applications-that-call-a-cocoa-api/).

      I have a more elaborate explanation for a wider project that may come out later.

  2. Pingback: FMX anti-pattern: returning nil rather than raising an exception on an invalid state or arguments | Delphi Haven

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