Idle Musings of a Delphi Junkie

I'd love to have ECO support VCL.NET, and was ruminating over this fact yesterday, when a thought dawned on me. The only thing that really makes ECO a WinForms technology is its support for .NET WinForms binding via the Reference/Expression/CurrencyManagerHandle components, and the EcoAutoForm stuff. The other underlying services and frameworks are not really dependant on WinForms at all.

For the life of me, I can't see why it wouldn't be feasible to use VCL.NET as your presentation framework, and still have full access to the EcoSpace IPersistenceService, IUndoService, IDirtyListService, IOCLService etc. The only thing you'd lose is the ability to have your domain objects bound to your GUI, which isn't really a big deal to me as I was in the habit of manually populating from my BO classes with my last few projects anyway. Hang on...

type, type, compile, mumble, type, compile..


OK, now I've quickly thrown together a prototype to test my theory. It uses the assembly containing the model that my currently under construction WinForms and ASP.NET ECO apps use, and simply shows all instances of the Course class from the model in a TListView. It does, however use a PersistenceMapperClient to talk to my ECO server application, and this all worked out of the box (as expected). If anyone is interested (or actually reads this blog for that matter), feel free to contact me and I can send you a copy. Alternatively, it was posted to the borland.public.attachements newsgroup, but be warned that posts there have a limited shelf life.


Its only a proof of concept thing, but seems to strengthen my belief that there is no reason why ECO and VCL.NET are mutually exclusive. It only has the code for the VCL.NET app, and includes the binaries for the assembly containing my model, and for the ECO server (connection hardcoded to tcp://localhost:8000/PocketCaddyServer). The ECO Server has a PersistenceMapperBDP which is talking to an InterBase database with the hardcoded path of POCKETCADDY.GDB (also included in the zip), but I see no reason why PersistenceMapperXML couldn't be used in the VCL.NET client for testing. I only chose to use my ECO server to further re-inforce the whole proof of concept deal.


And since coding this app, I've had confirmation from the ECO architects that there is nothing wrong with this plan at all, and the only thing you lose is support for databinding to your GUI. So if that isn't really an issue, there is no real reason to not use VCL.NET for ECO apps today.

Well, I managed to come through my 24 Hours of Delphi interview largely unscathed. As it turns out, the majority of the discussion centered around the forthcoming Delphi for .NET Compact Preview compiler. It seems there is quite a bit of interest in the community for this one. I was fortunate to get a sneak peek at this, when John Kaster from Borland Developer Relations asked me to write a CF Preview Quick Start article.

I mentioned in the chat that I'd been working on a PocketPC application called PocketCaddy. I've now uploaded this to CodeCentral. This is very much an evolving product, and I'm currently working on a PC based data entry ECO WinForms app, and ECO web service to expose this data to the PocketPC device. So as they say, stay tuned...

I've been slated to take part in Borlands 24 Hours of Delphi marathon tonight. I must say the enormity of this didn't really sink in until I noticed my name in an official Borland press release.

After all, I'm just a mere Delphi Junkie who spends a little a few hours a fair chunk of his life on the Borland newsgroups. It is indeed a great honor to be considered interview worthy, especially considering the lofty company I'll be keeping in this event.