Archive for July, 2011

The Need for a Smarter SyncEdit

Sunday, July 24th, 2011

When Mike Rozlog was visiting Calgary Alberta during the Rad Studio XE Tour one of the many features he demonstrated was SyncEdit. While SyncEdit is pretty cool from a visual standpoint, I don’t get why Mike was saying it’s such a great feature. First of all you have to select the scope in which to apply SyncEdit. It doesn’t even default to the entire unit, or the method in which the cursor is positioned. Then you have to locate the identifier(s) you wish to change and type in the new names. This isn’t really so different than using Ctrl+R to do a search and replace.  In fact, in most cases Ctrl+R is faster even if it doesn’t have the cool visual feedback.

Now if SyncEdit could be automatically invoked the moment you started modifying a method prototype in either the implementation or interface section that would be cool. It would be even better if the IDE could use that technology to create the prototype in the interface section when you added methods in the implementation section.

BTW, Mike, if you’re reading this, I’m still waiting for the answers to the questions I posed during that meeting, and later followed up with in an email. I know you’re busy, but the Tour was in Calgary on Sept. 9, 2010.

XE Parser causing long delays & Hangs

Sunday, July 24th, 2011

It appears my review of XE should have waited until I’ve had more experience with the IDE.

I just filed a QC issue (96552) because I am having a great deal of problems with XE becoming unresponsive.  It appears that when XE parses code in order to inject event handlers or provide code completion, it takes a long time to “think”, and sometimes if just gives up and decides to chew up all your CPU.  The solution to this specific issue seems to be making sure the unit being edited is present in your project as opposed to simply referenced by one of the units in your project.

I am running a stock version of XE with Update 1 now because I uninstalled IDEFixPack and GExperts thinking they might be contributing to the problem (and who can live without the code navigation capabilities of GExperts?).

If you’ve experienced similar issues I would encourage you to vote for QC 96552 and submit your own reports so EMB will give this issue some attention.  Code parsing in the editor has been a problem since D7 days and it scales poorly, so on bigger projects it apparently renders the IDE almost useless.  I have had to wait 5 seconds for the IDE to catch up on the code I’ve typed in because it was busy parsing (I presume), and I’m not a fast  typist.

Delphi XE - The Good, The Bad and the Ugly

Wednesday, July 20th, 2011

As a long time Delphi 7 user, I finally upgraded to XE.  It always takes a period of continuous use in the real world to get a feel for the environment, so I thought I would publish my experiences as a new user of XE, and my impressions for those contemplating an upgrade to this edition.  Most of my experience with a Galileo based IDE has been with Delphi 2007, so many of my comparisons will be between D7, D2007 and DXE.

The Good

XE is much faster than  any Galileo IDE I have previously used.  It’s form designer rivals D7’s in terms of performance, negating one of the reasons I refused to use Delphi 2007.  It’s compiler also seems to be much faster than D7’s and the code it generates also appears to be significantly faster.

I also love the debugger visualizers for TDateTime values.  Having to constantly create an expression using DateTimeToStr() to have a human readable value was a pain!

Of course, XE also comes with CodeSight Express, FinalBuilder, and BeyondCompare.  It has many incremental enhancements and some new features as well.  For the most part, I think EMB added the additional third party tools to make the upgrade more compelling because the IDE and compiler enhancements were not compelling enough on their own.  Most developers I think are waiting for the next version which to supposed to include X platform and Win64 support.

The Bad

The IDE does not appear to be as stable as Delphi 7.  In my first couple of days using the IDE I experienced multiple AVs in the RTL and VCL, and Eurekalog did not have an option to send an automated bug report, so I had to use the windows QC client and create one manually.  I wonder if EMB actually gets many of these issues reported as a result.

The code parser still blocks a developer from typing code while it parses the changes in the IDE.  IMHO this is an unacceptable limitation for an IDE.  A tool should increase a developer’s productivity, not stifle it by forcing them to wait until the editor is once again available, to accept further input.

Error Insight produces a lot of false positives so I have found it best to simply ignore it.

The F1 help still does not locate identifier help like D7 does.  For instance, pressing F1 with the cursor on IncMinutes doesn’t find DateUtils.

Unfortunately, DXE still suffers from the same problems I found in D2007.  It’s frustrating that functionality I found in CodeRush for Delphi beginning with Delphi 3 back in 1997 has still not found it’s way into the stock IDE.  For anything close, you have to use Castalia, GExperts, or CnPack (or some combination of them).

The Ugly

For some reason, when you launch Rad Studio XE it can take around 5 seconds on my machine before the splash screen appears.  I have found myself on occasion launching a second instance as a result of the delay between invocation and user feedback.  This is admittedly a minor irritation, but as a developer who invests a great deal of time ensuring his applications provide a high degree of responsiveness and user feedback, I think it shows a lack of polish.

I also like CompBar far better than the new palette.

Overall

Overall I would have to say that while DXE is not a leap forward, it is the best galileo based IDE to date, and certainly worth looking at even if you’re using a pre-galileo IDE and are happy with it.  While not a killer IDE, DXE is an improved platform that will form the basis for a lot of potentially exciting changes for Delphi.

Migrating to Unicode

Wednesday, July 20th, 2011

I recently started migrating my current client’s project to Unicode in a proof of concept application whose purpose was to decide on whether or not to upgrade to the latest version of RAD Studio.

The project is just under a quarter million lines of code to give you some perspective on it’s size, and it’s one of the most complex systems I have ever worked on.  It uses hcOPF extensively, incorporates tons of business logic, and it monitors and controls external serial devices.

Anticipated Challenges

I anticipated that the Serial port library used would be one of the most challenging items to port.  It only supports up to Delphi 2005, and doesn’t appear to have been updated since October 2003.  That said, the library was in use in the previous version of the product and proved itself to be reliable, so I chose to adopt it for the new release and had the same results even under Windows 7.

Other third party components used are the JEDI JCL/JVCL, hcOPF, DevExpress, TMS and PngComponents.  I didn’t anticipate any issues with the JEDI, DevExpress, or TMS components since they have been supporting Delphi releases almost as soon as they become available and have a good reputation in the community.  I knew that when EMB acquired the PNG components library they made some changes, in addition to trying to remove the old project’s code off of the Internet.  It took me some time to find the PNGComponents for Delphi 7 when I developed the app, and I must say it implements great designers, and is a pleasure to use.

Approach

Since this is a pilot project, using the current source, I wanted to make minimal changes to Unicode enable the application, in order to reduce the testing burden and likelihood of breaking proven code.  I also wanted to keep the source compatible with Delphi 7-2007 in case we chose not to upgrade, without having to discard all the work done for Unicode support in case we decided to upgrade at a later date.

I started by creating the D15 projects for all the components used and getting them installed into the IDE.  This proved to be my first road block as documented.  It took a blog post, a couple calls to tech support and one to sales before I managed to get a timed key to enable Delphi XE’s command line compiler and all of the features of the product.  My advice to anyone attempting to perform an upgrade is to contact EMB to get a timed key to begin with.  I would also advise to download the Delphi XE ISO from here.  When I attempted to upgrade my installation using the timed key, it kept complaining about not being able to resume a broken download, and it didn’t matter what option I chose, it would just repeatedly show the same dialog which doesn’t even tell you what download is broken.  After uninstalling Delphi XE I got the same error attempting to re-install the product.  Only when I installed from the ISO was I able to get the product running again.

Then I read Cary Jensen’s migration paper, and that from Nick Hodges.  I enabled all the Unicode compiler warnings as Marco Cantu recommended and paying special attention to <W1058 Implicit string cast with potential data loss from ’string’ to ‘AnsiString’> errors I proceed to go through the code and decide what needed to remain an AnsiString and what changes were needed to minimize any implicit conversions.

The Reality

The new PNG support in Delphi does not contain the TPNGImageList and TPNGCollection components.  I had used both in my application.  I attempted to compile the D7 version, and quickly abandoned that when I encountered several ‘cannot assign to left side’ errors.   Prior to discovering that  Uwe Raabe had submitted an update to the components to CodeCentral, I changed my application under D7 to load items from Resources. In some cases though, I was using components that required Imagelists so finding Uwe’s port saved a some effort in converting them for use under Delphi XE, and kept my source code compatible with D7.  Thanks Uwe!

To me this exemplifies one of the primary difficulties in upgrading projects to a new version of Delphi.  One that Embarcadero, likes it’s predecessors, doesn’t seem to understand, because if they did, why would they have removed the PNGComponents open source project?  Surely developers don’t upgrade their version of Delphi simply for new image support!  It would also be foolish to think you can stop the sharing of what was once open source on the Internet, or that attempting to do so wouldn’t give you a bad rep with prospective customers.  The reality is that there are Delphi developers out there who use old versions because they don’t like .NET, think the old IDEs are leaner and do everything they need, or are locked into their current IDE because of the sheer size of their code base and thus the magnitude of their porting effort, or because they don’t have source for their components.  By making the migration more difficult, these customers are going to be left behind no matter how many BOGO offers are made.

Anyway, I digress.  I made liberal use of CharInSet(), converted my serial component to use AnsiString/AnsiChar and made numerous other little changes and was amazed that it all ran just fine.  Porting this particular project to Unicode was much easier than I anticipated.  While the product still has to under go complete testing by the QA people, I am happy to report that the unicode migration project took less than the week I estimated, and none of the potential problems I was concerned with have materialized.  For those of you that haven’t taken the leap, I would encourage you to do so.