Delphi and the Compact Framework, Real Soon Now?

David I posts about a preview they are showing at the SDC sessions. From the blog post it appears that we may very well see a preview compiler targeting the .NET Compact Framework prior to the next major release of Delphi.

While details are sketchy it is extremely positive to hear about the compiler showing up prior to the next major release. Hopefully we can do our bit and flush out any major platform issues as part of a preview so the next major release can have something robust and workable.

Some background materials:
My point of view
Danny's preview of Delphi on CF
Allen's follow up on VCL/WinForms positioning


Kudos to the Delphi team for pushing it out the door :).

This is probably a good time for you to pick up Software Assurance if you haven't already. After you figure out what it is it doesn't make sense to not have it if you are using any Borland Tools.

Delphi.NET and the Compact Framework

Danny has provided an update on Delphi support of the Compact Framework. It all sounds very promising but...

For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.

Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.

What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.

Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.

So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.

Byte Alignment Bites

We are so spoiled when developing for the Windows platform. It is polite enough to allow us to access mis-aligned data (data which is not aligned on machine word boundaries). I have been tinkering around with some ActiveSync code on a Compaq Aero and just finished getting a fresh reminder that non-aligned data can and does result in worse than sub-optimal performance.

In particular, the data exchange occurs within the GetPacket and SetPacket methods of the IReplObjHandler interface. This interface is implemented on both the desktop and the device. I have written the desktop bits in Delphi and the device bits are in Embedded Visual C++ 3.0. Normal thought processes suggest minizing the volume of data passing over the link (especially when it is serial 19200-56000). So, as is typical,I immediately packed the structures for all text content. Basically it is just a fixed header with a variable portion followed by one or more variable length property entities. This format permits me to send just about anything and is relatively robust except for the overhead associated with the property names travelling in each packet exchange. But that is getting a bit off topic (as I am permitted to at this time of night).

All was fine with marshalling the data on the desktop (where you can debug, have a good tool, etc.) but the ActiveSync connection would literally drop and there was nothing logged as to the failure other than a NAK (obscure at best). With some heavy injection of file based debug statements in the code in question I found that the system simply stopped when trying to access the second property header. For whatever reason as soon as I saw what was happening it just sort of turned on a light bulb for me (gotta love that on those rare instances). So, now the marshalling code does four byte alignment on strings that it passes along. It was quite easy since the data lengths were already being used so I was pretty lucky in terms of length of time to finding the bug and fixing it. Now I can get on with the rest of the tinkering.

So, the lesson, remember that all platforms are not created equal and you still need to know something about what is underneath. Happy coding.

Some more links for ActiveSync

Well, I am back at poking about some Windows ActiveSync code again. The hunt for real-life-problem-solutions relating to ActiveSync are pretty hard to come by for some reason so anyone looking atdoing it really is starting from scratch (or nearly anyway). I have located another set of pages outlining in a very understandableformat,some insights on handing the ObjectNotify device function. Here is the relevant page and a link to the site map which has some more worthwhile information.

Here is another link but it is a bit more thin.

Windows CE ActiveSync

Well, over the past couple of weeks I have been tinkering on and off with the Windows CE devices again. Of particular interest has been integration into the ActiveSync process. The only sample application that is provided by MS is called StockPor and while it does the job and works it only offers a single viewpoint and is so much like any other initial example. It lacks the growth pains that someone else has worked through to get things working.

To tackle this problem I have been using eVC 3 for the client library (the sync library that sits on the device), eVB 3 for the handheld applet (doesn't get much easier to use since you have ADO support), and Delphi for the server sync library (after having converted the CESync.h and requiredheaders)and MS SQL server for the server store (not using active sync built in functions though). It has been progressing fairly well and I have framed in all the layers but have stumbled on a few points of the API that simply are not clear.

So, as time permits, I have been actively searching for other ActiveSync source code examples to find some lessons learned and alternate views of the function implementations. I have found a site with three separate ActiveSync enabled tools but they are not compiled for the device I am using and the source code is not available. Anyone interested in these ActiveSync Tools can pick them up here. The search continues...

Annoying eVC device download problems

I have been playing around with some handheld development again (did some a few years ago). I am really just exploring ActiveSync and what the state of the tools are presently. So I have been picking as eVC/eVB 3, eVC4, and the Compact Framework. As before, some of it was easy while other bits of it can be extremely frustrating. Getting eVC3 to consistently download the binaries happens to be one of the most annoying gotchas :(.

After trying a few dozen different things from various topics in the groups one solution has come up consistently as solving the problem of eVC failing to start/connect to the device during the build. All you need to do is start up a copy of the Remote Zoomin tool and it will prime the connection, cancel it after it starts downloading the bitmap if you wish but it is best to leave it running. From the point on (until you undock) you can build to your hearts content.

It is a shame about the undocking bits since what I am playing with relate to ActiveSync and having to redo those steps can be bothersome at times but at least it works.

<tapping_foot>When will Delphi for CF be ready...</tapping_foot>