[DUG] Auckland Event Details

Tue May 6 08:00:59 NZST 2014

Hi David,

You can separate business logic from gui logic. It is called multi-tier. I
put all business logic into a separate dll. This way it is very clean.

Just my 2 cents.

In xamarin C# solution, I use MvvmCross. It is very maintainable. I write
business logic in Microsoft portable library and gui into separate projects
for android, ios, windows 8 phone, windows 8.1 store. One code to rule them
all. :-)

Regards
Leigh

On 5 May 2014 17:53, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

> Hi Jolyon,
>
>
>
> If our current application suite was written in Elements instead of Delphi
> then you are quite correct, I wouldn’t see them any differently. I suspect
> (without knowing many details about it) that I would be quite happy with
> Elements – I might not be madly impressed at being forced to develop
> different GUIs for each platform but it looks like there are probably other
> benefits which would counter my annoyance at that.
>
>
>
> The whole point is that our current application suite is NOT written in
> Elements. It is written in Delphi with a big VCL front end. The same
> presumably goes for the majority of Embarcadero’s customer base. The
> decision Embarcadero made on HOW to embrace cross platform needs to be
> evaluated in that context.
>
>
>
> You seem keen to keep evaluating Embarcadero’s decisions in the context of
> purely what is the best resulting development environment. That is a very
> interesting conversation to have (and I genuinely have been finding it
> interesting reading your posts on Elements) but in a vacuum like that it is
> only partially relevant to the actual real world decision Embarcadero
> faced. IMO.
>
>
>
> Regards,
>
> David.
>
>
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Monday, 5 May 2014 5:42 p.m.
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> @David:
>
> Then I'm not sure how you see the elements approach as significantly
> different, other than in the degree of effort required to create the
> portable object library.
>
> Platform dependence arises in Elements in only two ways:
>
>
>
> 1) You write code that is dependent upon some platform specific language
> feature or framework
>
> 2) You compile the code
>
> Other than that, your code is portable to any platform supported by the
> compiler(s).
>
>
> By it's nature, any GUI code is platform specific, so all the GUI work is
> caught by #1
>
> But the upside of that is that your GUI code is platform specific, not
> lowest common denominator (and you are encouraged - dare I say forced - to
> develop your applications the way we always should - with the GUI at arms
> length from the functional code).
>
> FireMonkey scores big Brownie points because it allows you to keep all
> your business code locked up in the GUI where many people habitually find
> themselves plumping it thanks to the RAD philosophy of the past (which the
> VCL facilitates and never really grew out of).  Such implementations will
> be attracted by the ability to simply "migrate to FireMonkey"and not have
> to think about how to develop properly for the new platforms.
>
>
>
> But back to Elements.... I think the fact that the technology is so
> successful at embracing the different platforms causes some people to think
> that Elements code is only ever Java code, or Cocoa code or .NET code, and
> ne'er the
> twain shall meet.
>
> This isn't so.
>
> When you write portable code, then it is mapped to platform specifics only
> at compile time.
>
> Both of these declarations are legal Oxygene code:
>
>   customers: array[0..10] of Customer;
>   customers: ^NSArray;
>
>
>
> The first is platform agnostic and as long as you work with that array
> also using portable code, then that code will compile for Cocoa, Java or
> .NET equally well.  The second is obviously tied - declaratively - to Cocoa.
>
> I think perhaps some blogging on more examples in this area is called for.
>  :)
>
>
>
> On 5 May 2014 17:18, David Brennan <dugdavid at dbsolutions.co.nz> wrote:
>
> Hi Jolyon,
>
>
>
> What I said was: “Any solution needs to provide either a near perfect one
> way migration path *or* long-term single sourcing between VCL apps and
> the new platforms.”
>
>
>
> Embarcadero’s current approach is the latter route. I can use exactly the
> same source code between VCL and Firemonkey apps. The GUI layer certainly
> needs to be different but I regard this as an unfortunate inevitability
> whichever route Embarcadero went (as I said in my original reply, the only
> alternative would be to update VCL to seamlessly cross compile onto other
> platforms which everyone seems to have agreed was just too hard).
>
>
>
> You are correct that I haven’t tried to migrate any of our current
> applications to Firemonkey and I have spent a relatively small amount of
> time developing test apps in it. However large parts of our code, including
> the most important and complex parts, can be compiled without VCL forms and
> are used without the GUI in several different DLL styles (eg ISAPI, COM
> DLLs, etc). There would of course still be plenty of work to be done in
> incorporating this code into a Firemonkey app (new GUI, GUI links to our
> business objects, mobile compatible data layer) but our core logic should
> in theory be fine. The only hiccup I can see is the new object reference
> counting used on the mobile platforms which may require some tweaking of
> how we handle lifetimes of some objects to make sure they get freed
> properly when desired.
>
>
>
> Even if some effort is required the key point is that after we have
> performed this effort our core logic can be compiled to all platforms
> (including Windows). That is my main goal out of any cross platform
> solution and anything which does not deliver this automatically fails.
>
>
>
> I do agree that lack of support for Windows Apps may become a concern.
> Last I heard Microsoft were deliberately locking out native solutions which
> don’t use their exception handler. However this is only a real problem for
> us if Windows RT takes off and currently it seems to be doing the opposite.
>
>
>
> Regards,
>
> David.
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Monday, 5 May 2014 4:27 p.m.
>
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> @David:  What you say they shouldn't do (treat Delphi+VCL as legacy) is
> exactly what they *are* doing, they just haven't come out and said as
> much.
>
> Consider that their Windows 8 support consists of little more than GUI
> styling.  FireMonkey does not work very well (in terms of making sense) in
> this space and you might argue that this is OK because Windows won't be as
> relevant in the *mobile* space (many would disagree) where FireMonkey is
> more firmly planted.  But for the VCL to be struggling to remain current on
> the desktop, should be a source of concern.
>
> The best you can do with either approach is create something that looks
> the part but which doesn't stack up once you peel back the GUI paint job.
>
>
>
> So, that being the case, if FireMonkey is the "future"of Delphi on future
> relevant platforms, where does that leave the VCL and longer term support
> for the Windows desktop ?  Which, growth of other platforms
> notwithstanding, will remain very relevant for a long time to come.
>
>
> From what you say I get the impression that you haven't yet actually tried
> to migrate any code to the FireMonkey world.
>
>
> Unless your legacy code was implemented in a fortuitously forward-thinking
> manner, I suspect that a great deal of what you think might/should be
> portable in your VCL code in particular may well turn out to depend on
> things that aren't available to you in FireMonkey, or certainly not in a
> way that you will be able to seamlessly and effortlessly migrate to.
>
>
>
>
>
>
> @Xander:
>
> Cost is one reason to discount Xamarin.  Elements cost me US$699 - that's
> both Oxygene (ObjectPascal) and Hydrogene (C#) for .NET, Java and Cocoa.
>
> Why would I need both languages ?
>
> Well, I intend to learn C#, but I have shorter term project goals where
> being able to leverage my productivity in ObjectPascal will be useful.
>  With Elements I can mix and match as I develop my C# skills.  Because
> there are no framework/runtime "walled gardens" in the way, work done in
> one is directly usable in/with the other and - indeed - in the platform
> native development environments to boot.
>
>
>
> i.e. if it is easier to create a "Cocoa encapsulation"of some C API using
> C# than to do so in ObjectPascal, then I can do so, but then I can use the
> classes thus created directly on the ObjectPascal side, if I prefer to use
> that for (e.g.) some GUI app that consumes that API.
>
> And I can publish my encapsulation and Objective-C developers can use it
> in their Xcode solutions.
>
>
>
> The same applies in the Java space.  Also, in that case, I prefer Visual
> Studio to Eclipse or any of the other Java development environments (plus
> Java is even worse than C# as a squirrely brackets language).
>
>
>
>
>
> Which is another point worth mentioning.... RemObjects implementation of
> ObjectPascal and - to a lesser extent - C# improve significantly on Java,
> C# and Objective-C in key areas, without losing compatibility at the
> code-gen level.
>
>
>
>
> @Leigh - why not use Java ?
>
> I think my answers above should explain why I prefer not to use Java.  :)
>
>
>
> For context:
>
> I currently do most iOS / OS X development in Xcode and Objective-C.
>
>
> I use Oxygene for Java (Android) being careful where possible to create
> relevant code in my Android projects in a portable, platform independent
> form with a view to re-using it in future Xcode/Oxygene/Hydrogene projects.
>
>
>
> I anticipate using Hydrogene and/or Oxygene for .NET
>
>
>
> On 5 May 2014 15:50, David Brennan <dugdavid at dbsolutions.co.nz> wrote:
>
> Thanks for the reply.
>
>
>
> The single source requirement was based on my own requirements but I
> strongly suspect I’m not alone in this. We have a million odd lines of code
> and having to maintain two versions of that code to support iOS/Android
> would automatically rule any solution out for us.
>
>
>
> Maintaining two versions of the GUI is also annoying but marginally more
> palatable because a decent case can be made that the GUI requirements
> between the different formats are sufficiently different to mandate making
> new form designs anyway. Even so, I would still strongly prefer that being
> my choice rather than foisted on me, and I would also prefer to be able to
> use our current components on the new GUI (in our case primarily DevExpress
> VCL). However I accept that it was close to impossible to port VCL to the
> mobile platforms so a new GUI layer was inevitable.
>
>
>
> Looking at overall approaches (and ignoring you specific recommendation
> with Prism) I believe there are two aspects to what you are saying
> Embarcadero should have done:
>
>
>
> 1.       Their GUI layer should be platform specific. Thus one would need
> to develop a new version of a form for each target platform. I can see the
> arguments both ways on this and suspect it comes down to how much effort a
> developer wants to spend on each platform. For the foreseeable future any
> iOS/Android apps we release are unlikely to be our core business so from my
> point of view I prefer being able to develop a single tablet size version
> of each form, add a few platform specific runtime customisations to the
> layout and release to all platforms. But I recognise others may prefer the
> other route.
>
>
>
> 2.       Their language should cross compile into the most common
> environment of each platform. That means Java for Android, Cocoa for
> OSX/iOS, .NET/Win32/Win64 for Windows. That is a pretty impressive trick
> and I am indeed impressed that RemObjects have managed to pull it off. The
> question is whether Embarcadero could have achieved something similar while
> maintaining single source backward compatibility for their existing
> customer base. We would still need to be able to compile our current
> applications for Windows with minimal changes. This means VCL still needs
> to compile too, as do applications which directly access Windows APIs etc
> (although obviously it would be acceptable to need to replace both VCL and
> Windows API calls before single sourcing to another platform). I think it
> might have been possible but Embarcadero decided to go the native
> instructions way instead.
>
>
>
> Back to your specific suggestion, you say that Embarcadero should have
> made Delphi + VCL a legacy solution and made Prism the new solution. In
> order for this to work IMO either Embarcadero would need to provide a
> robust tool to convert VCL projects to Prism projects OR you would need to
> be able to single source code between Delphi and Prism. Otherwise the
> migration hurdle is just too large – a development house would need to move
> ALL their code and rebuild ALL their GUI in Prism at once to make the
> switch, small steps over time would be impossible. Embarcadero would also
> have come under a lot of pressure to enhance Prism so you could compile
> directly to Win32/Win64, otherwise a portion of their customer base who
> demand to the metal code in Windows would not make the switch.
>
>
>
> This is all in my opinion, but it is in my opinion as the owner of a
> Delphi software development house. Hence I think my situation is relevant.
> You blithely say ‘simple’ leave Delphi + VCL as their Win32 solution with
> Prism/Elements as the new platform. But I don’t think it is ‘simple’, as I
> explained in the previous paragraph. Any solution needs to provide either a
> near perfect one way migration path or long-term single sourcing between
> VCL apps and the new the platforms.
>
>
>
> In that context I can see why Embarcadero have gone the way they have and
> it seems reasonable to me. My only beef with it is whether the
> implementation they chose (Firemonkey) was the right one – I think they
> needed to be much more ambitious with their initial design of Firemonkey,
> do everything properly to make it a really top class component suite, and
> then spend three years carefully developing it before releasing it. Instead
> they purchased it then rushed it out the door, and have been spending a lot
> of time since then trying to fix design flaws, something which is much
> harder to do once it is already in use and backward compatibility is an
> issue.
>
>
>
> Regards,
>
> David.
>
>
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
>
>
> *Sent:* Monday, 5 May 2014 2:41 p.m.
>
> *To:* russell at belding.co.nz; NZ Borland Developers Group - Delphi List
>
>
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> @David:
>
> Your prescription that the approach must support single source is
> arbitrary.  Heck, not even Embarcadero achieved this goal completely
> satisfactorily, so by that criteria FireMonkey itself is a failure.
>
>
>
> RemObjects approach is the more robust one.
>
> Rather than trying to pretend that platform differences can be abstracted
> away or reduced to lowest common denominator (as if the various user
> communities of the various platforms were not themselves making their
> choices precisely because of those differences, in many cases), those
> differences should be embraced and the developers empowered to take full
> advantage of them in order to provide the best solutions possible for
> *each* platform, not limited to providing a solution that can be deployed
> on *all* platforms.
>
> What should Embarcadero have done ?
>
> Simple.  Instead of tossing Prism into the long grass, they should have
> brought Elements into the fold.  Kept Delphi + VCL as their Win32 solution
> with Elements as their .NET and mobile platforms offering.
>
> But, frankly, as an Elements user who has previously experienced
> Borland/Inprise/Codegear/Embarcadero's product management, development,
> marketing and pricing at first hand, I am actually *very* relieved that
> they didn't (and suspect that RemObjects themselves might have resisted any
> attempt to do so).  ;)
>
> The very fact that an outfit such as RemObjects have both the technical
> nouse and capacity to deliver something like Elements whilst Embarcadero,
> with far more resources at their disposal, are left buying up other
> people's technologies and trying to create a marketing message around them
> whilst rushing out poor quality releases (XE6 Hotfix 1 was out before the
> ink had dried on the XE6 release EULA!) to keep the money mill churning,
> should tell you everything you need to know about Delphi's future.
>
> If RemObjects can do it, and if Embarcadero are everything that their
> supporters crack them up to be, then Embarcadero should have been able to
> deliver their own "Elements", especially given that they would have been
> able to focus exclusively on a Pascal solution, if they so chose, without
> the added distraction of a C# front end.
>
>
>
>
>
> @Leigh....
>
>
>
> Yes, Oxygene/Hydrogene (hereafter: Elements) when targetting Java,
> produces Java byte code.  Just like the vast majority of Android code out
> there (with the exception of games - the one type of app that the
> NativeActivity support in Android was only ever intended for).  Oh, and the
> FireMonkey apps.
>
> One thing this means is that unlike FireMonkey, your target platform is
> not confined only to Android and the Java environment provided there.  For
> example, if you really wanted to, you could use Elements to create an
> Eclipse plug-in.
>
> Elements can produce Java code, hence Elements supports all Java based
> platforms using all of the capabilities that those Java platforms supports
> because - to all intents and purposes - when compiling for Java, Elements
> *is* Java.  Just with a different language front-end.
>
>
>
> As such, yes, it runs at Java speed, just like all the other Java code on
> those Java based devices, Android or otherwise.  But it does so without
> having to drag in a bloated runtime and a custom UI rendering engine (and
> that's incorporated into EVERY FireMonkey app, btw).  Your apps take full
> advantage of the device capabilities.
>
> That includes, for example, ART, which is the Android technology that
> allows Java based Android apps to be installed as pre-compiled, native code
> binaries.  Just like FireMonkey apps, but without the embedded bloatware,
> and with the ability to run on any Android device (that support ART, or
> indeed of course all the ones that don''t).
>
>
> But equally, when compiling for Cocoa, Elements is an LLVM compiler.  All
> of the same advantages apply - you have complete, platform native access to
> the platform with all of the benefits that accrue.  Whether that is Cocoa
> (OS X) or CocoaTouch (iOS).
>
> Similarly, Elements for .NET... any .NET based platform is available to
> you, be that Windows.NET, Windows RT or Windows Phone.
>
>
> How is the .NET support in FireMonkey these days, by the way ?   ;)
>
>
>
> On 5 May 2014 12:59, russell <russell at belding.co.nz> wrote:
>
> Always interesting to read strong opinions … even when presented as facts
> and focusing on a few topics.
>
> The analysis looks plausible. I cannot assess it well as I write for a
> niche community  and RAD Studio serves me fairly well.
>
>
>
> Russell
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Monday, 5 May 2014 11:13 a.m.
>
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> What makes less sense is the way that they added support for those
> platforms.  You are right to highlight the manner in which they have
> managed to tick boxes.  Unfortunately it is *purely* an exercise in
> ticking boxes.  Far less useful as a solid basis for continuing to be able
> to *keep* those boxes ticked.
>
> Delphi was always a niche product.  Despite the marketing, their
> cross-platform solution is *not* Delphi for "iOS/OS X/Android" (and it
> painfully clearly is not Delphi for .NET, let alone WinRT or WinPhone).  It
> is "Delphi for FireMonkey", with the ability to deploy to any platform that
> FireMonkey manages to cajole a semblance of support for within the
> constraints of what the approach allows.
>
>
>
> i.e. you cannot build true Android solutions using FireMonkey because the
> way that FireMonkey works rules out certain capabilities of that platform.
>  Similarly your FireMonkey Android apps will not benefit from ART.  Sure,
> your FireMonkey app is "native code", but is also bogged down by the
> non-platform native frameworks required to make even "Hello World"possible,
> so whilst true platform native apps gain all the benefits that that
> platform delivers, FireMonkey remains stuck in it's own world.
>
>
>
> i.e. FireMonkey created a niche within a niche.
>
>
>
>
>
> Having attracted the interest of Delphi developers to the platforms that
> FireMonkey ticks the boxes for, many of those developers will quickly
> realise the limits and look instead at the alternatives, at which point
> they realise just how far behind Delphi has fallen over the years while
> Embarcadero wasted their time on the Smoking Chimp.
>
> As for the renewed interest in developing the VCL, this can be seen as a
> return to core value, or it could be seen as a belated recognition that
> FireMonkey is not in fact the secure future for Delphi/Embarcadero that it
> was supposed to be, and worst of all, without any viable strategy for
> supporting the platform on which that core value rests - i.e. the latest
> and future versions of Windows - even that core value is now at risk.
>
>
>
>
> For myself, I now use a combination of RemObjects Elements and Xcode for
> most of my work.  Delphi is now very much a legacy platform.
>
>
>
> On 5 May 2014 10:46, David Brennan <dugdavid at dbsolutions.co.nz> wrote:
>
> It was a good seminar IMO. I understand why Embarcadero have decided to
> spend so much time adding support for OS-X, iOS and Android, at some point
> we may even take advantage of it. More importantly though I’m glad they
> seem to have realised that now they have ticked those boxes they need to
> return to address quality across the product.
>
>
>
> I just hope that XE7 will continue that trend so that the Delphi IDE and
> executables continue to improve in speed and robustness. I’m also hoping
> that XE7 will see a big push to make Code Insight bulletproof (or as bullet
> proof as such a thing can be, given that if you screw your syntax up
> completely midway through a big change it is always going to struggle, but
> it would be nice if it returned to fully operational once you tidy things
> up a bit!).
>
>
>
> Cheers,
>
> David.
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jeremy Coulter
> *Sent:* Monday, 5 May 2014 10:10 a.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> Yeah let us know hen its done. We didnt attend the presentation for
> various reasons, although it would have be good, so am looking forward to
> hearing what Marco had to say.
>
>
>
> Jeremy
>
>
>
> On Mon, May 5, 2014 at 9:51 AM, Alister Christie <
> alister at salespartner.co.nz> wrote:
>
> I managed to spend a number of hours with Marco after the presentation,
> and have about an hour and a quarter recorded, which I will make available
> after Marco has reviewed it.  It was great talking with him, it seems that
> Embarcadero made a good choice appointing him Product Manager for Rad
> Studio.
>
>
>
> Alister
>
>
> Alister Christie
>
> Computers for People
>
> Ph: 04 471 1849 Fax: 04 471 1266
>
> http://www.salespartner.co.nz
>
> Follow us on Twitter http://twitter.com/salespartner
>
> PO Box 13085
>
> Johnsonville
>
> Wellington
>
>
>
> On Wed, Apr 30, 2014 at 8:43 AM, Gary Benner <gary at benner.co.nz> wrote:
>
> HI All,
>
> Sorry this is a little late but just got back from a trip overseas.
>
> To endorse Alister's comment, great opportunity to meet Marco.
>
> cheers
>
> Gary
>
>
>
>
> Please see below details for the RAD XE6 Launch. Please will you forward
> this email invitation to members of the NZDUD to register/attend the event.
>
>
>
> Date and Venue:
>
> Friday, 02 May: Auckland
>
> Venue: Rydges Auckland - 59 Federal Street Cnr Kingston Street, Auckland
> 1010, New Zealand
>
> Time: 8.30am Registrations, 9:00am – 12:00pm
>
> http://forms.embarcadero.com/AP14Q2NZDeveloperDirectLIVE
>
>
>
> The event will be hosted by Damien Bootsma with special guest-speaker,
> Marco Cantu, RAD Studio Product Manager, global luminary & author of over a
> dozen books on Delphi. This event is not to be missed, so register NOW, as
> spaces are limited!
>
> Be amongst the first to see live previews of RAD Studio XE6 and all of the
> great new technology, with the latest enhancements to the VCL and more.
> Here's a glimpse of what is in store:
>
> Empowering your VCL codebase and developer productivity
>
>
>
> • Give Your VCL apps a new look-and-feel with improved VCL Styling
> • Introducing Win 7/8 taskbar buttons
>
> Database, integration and scalable services with RAD Studio XE6
>
>
>
> • Core Database Features Improvements
> • New FireDAC Database Explorer and more
> • Working with JSON and XML
> • Building scalable and secure DataSnap services
>
> Embrace and Extend Your Mobile and VCL applications
>
>
>
> • App Tethering
> • Not reinventing the wheel with new BAAS Client components
>
> "Turning on" to mobile and The FM Application Platform
>
>
>
> • Introducing Android support in C++Builder XE6
> • App Monetization with Advertising and In-App Purchases
>
> Evolution within a revolution: Summary and Q&A
>
> If you are an application developer, technologist or development team
> leader and interested in modernising your VCL apps & extending your
> applications to mobile devices for your customers, then this event is for
> you!
>
>
>
> Kind regards,
>
>
>
> Mike
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20140506/31700922/attachment-0001.html 