[DUG] Delphi Update

[jason at software-solutions.co.nz]

From my early playing with FireMonkey I could not use Messages at all, at least this is what I found when trying to port an app written in Delphi+VGScene (where Firemonkey originated from).

I have threads working with a REST Service for data sync and without messages basically have to rethink the lot, not to mention, Firemonkey basically broke the entire app anyway.

And lets not mention that the editors in FM are dreadful, I have several user that hate the editors (Tcombobox, Tmemo, TEdit)  and have done a lot of tweaking to get the VGScene editors working correctly, but these changes will not work at all with FM. Oh well, looks like onto c# and maybe Silverlight (or HTML 5) for the nice visuals I have managed with VGScene, and a complete rewrite for iOS/OSX.

It looked good in the early days, I’ve spent over 12 months intensive development on my latest project, and looks like I’ll be re-doing it again next year.. at least I’ll have a version 1 that will allow me to model the next build on and gain some knowledge with.

Jason


From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Tuesday, 15 November 2011 11:31 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Delphi Update

@David

I don't have specific technical issues with FireMonkey as such, just a general feeling that it's too niche in an already niche area.

When I am developing code for OS X I am going to run into problems that I need to solve and areas of the Cocoa framework that I need to learn about.  The bast majority of samples and other sources of assistance out there will be assuming "native" Cocoa development, and access to native facilities in the framework.  There will be precious few such sources of assistance that can be directly applied to FireMonkey code that aren't written specifically with FireMonkey in mind.

Things like "Synchronise" in multi-threaded code for example.

FireMonkey incorporates the same complicated and potentially fragile Synchronise mechanism that the VCL is hobbled by, but both Windows and OS X have native mechanisms for ensuring that code is performed on the main application thread.  FireMonkey doesn't use either of those mechanisms on Windows or OS X.

On Windows, I have my own "native" Synchronise implementation (create a form in the main thread and send it messages to be processed simply as part of the message queue - much simpler, more lightweight and more reliable than the VCL "Synchronise"mechanism).

On OS X the equivalent would be even more simple:  just invoke "performSelectorOnMainThread", but as far as I have been able to tell, there is quite simply no way to get at or utilise this mechanism from Delphi.


To an extent this is a separate question from whether or not a generic, non-platform specific GUI layer was the preferable/more correct choice rather than creating a visual controls framework specific for each platform, but equally a non-platform bound approach intrinsically favours that generic solution since platform binding in the GUI Controls typically necessitates a much closer affinity to the underlying platform.  In the case of the likes of OS X that means the Cocoa runtime.

Compare and contrast the two approaches to OS X support undertaken in FPC

First, a runtime "bridge" between the FPC runtime and the underlying platform runtime:

http://wiki.freepascal.org/PasCocoa#The_information_on_this_page_is_legacy_and_only_available_for_historical_purposes._Please_see_FPC_PasCocoa_for_current_information.

This first approach will be very familiar to anyone who has done any OS X coding in Delphi, with or without FireMonkey.

Now look at what replaced that approach:

http://wiki.freepascal.org/FPC_PasCocoa

i.e. Language extensions that bring the platform runtime and concepts right into the language, in exactly the same way that the "message" and "automated" keywords do/did so successfully on Windows (and in fact, in FPC they managed to re-purpose that "message" keyword itself!).


Android ... ?

From the little that I have experimented with Android so far, I simply cannot see how they can extend the FireMonkey and platform bridge approach to Android at all successfully, never mind emitting the write code from the compiler back end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20111114/b3b2fd85/attachment.html