Some IDE enhancements to consider...

The Tool Palette has this great option of filtering its content. Give it the focus (or click the filter button) and start typing. For example you will find all the type of buttons when you type 'butt'.


This is just great!

Today I had to search a unit for specific functions, and you can search the code structure with the structure pane which is a list of all the components and methods of a unit in alphabetic order.


Would it not be nice to have a filtering option on the stucture panel too? Just type 'Formc' and you have your FormCreate event.

Taking this idea a step further, also the Object Inspector and Project Mangager could benefit from such an option.

I am not sure if anybody already came up with this, but if it is in Quality Central I sure would like to vote for it. (Did not find it yet)

The day after...more options?

Ok, CodeGear drops Winforms. It is now clear that I belong to an exclusive group of Delphi .NET Winforms developers out there. That sounds cool, but they now have a little problem, driving their applications into the future. I am not happy about this affaire, but live goes on. Time to sort out my options.

What was I thinking, doing Winforms development in Delphi .NET?
As I told you before I use(d) Delphi .NET Winforms for only few applications belonging to the same project.
This project is a VCL Win32 project, built up in a couple of modules (read seperate applications) which I started two years ago. Why VCL Win32? Simple Delphi is VCL
The last two modules needed Gauges and Charts. At first I builded this in VCL Win32 with TMS Software's Instrumentation workshop, however my client came up with the Dundas Gauges and Charts. And he was right, these are a class on their own.
Of course this were .NET components, which I could not use in Delphi Win32. So a decision had to be made. Basically there were two options Delphi for .NET Winforms, or VS C#. (I tried to wrap them into VCL.NET, but that did not work)
Although the controls were built for VS.NET (and supported), I choose for Delphi .NET for the simple fact that I could reuse my coreclasses by sharing them between my Win32 and .NET projects.

Bringing my Delphi for .NET Winforms apps into the future
No panic, however at some point in time I probably have to upgrade my applications to 'something else' (Or I will have to install BDS2006, and .NET 1.1 framework, for the rest of my life ;-))

At this point I think that my only option is to bring the projects over into VS C#.

More options?

CodeGear to drop winforms designer in Highlander

Early june the roadmap for Delphi and C++ Builder was published. At first sight I found it a good roadmap.
It became even better with the updated one, where the nice codename Commodore for a 64 bit Delphi was introduced.
I first became a bit worried by a blogpost of Devexpress CTO Julian Bucknall who somehow managed to read between the lines. What he read was that C# Builder and Winforms support was dropped (Kaput as he says). His exact words:

There's no mention of the WinForms designer. Indeed, as I understand it, it's kaput. You should be using the forms designer that targets VCL.NET.

Huh? Let's take a further look at the roadmap, it says:

"Highlander" is a planned release that is both a major upgrade to Delphi .NET and a roll up of Delphi 2007 for Win32 and C++Builder 2007 into the complete 2007 RAD Studio. Highlander is planned to enhance Delphi's .NET support up to .Net v2.0 including both framework, design, and language enhancements.

Delphi developers will be able to develop rich, full-featured websites using RAD techniques and ASP.NET 2.0. VCL developers will be able to easily migrate code to managed code using VCL.NET. Delphi developers will also be able to use model-driven development to drastically improve their productivity.

Specific areas of focus under consideration for Highlander are: ... etc

OK search the roadmap for Winforms and, yes, it is not mentioned. But highlights in the above quote: major upgrade to Delphi .NET, enhance Delphi's .NET support up to .Net v2.0 including both framework, design, and language enhancements

Oh well Julian must be wrong, it will all have to do with C# Builder. Dropping C# Builder, hmmm I can imagine such a decision. Because C# Builder is in fact the Microsoft C# compiler and C# syntax = C# syntax.

Well he was not wrong, in fact he had it right. After reading this non.tech thread it was all clear to me, someone asks:

Will there continue to be a Winforms designer for Delphi for .Net? Because,
that's what our ECO applications are using and we are using DevExpress .Net Winforms components. Especially, after reading Julian's blog entry of
yesterday.

and Nick Hodges from CodeGear replies:

> Will there continue to be a Winforms designer for Delphi for .Net?
No -- we aren't going to be supporting Winforms going forward.

Shock, WTF, no more winforms support???
How can a roadmap talk about design enhancements, but in fact drop it?

Delphi .NET, the history
Before I continue it is good to take a brief look at the history of Delphi in the .NET world.
Delphi entered the .NET world, announced as a first class .NET citizen read about it here. First class with everything on it. It was a evolution, instead of the revolution, so Delphi developers could embrace .NET the easy way. Well it turned out that Borland/CodeGear had to play catch up with Microsoft. .NET 2.0 support is still not here.
I remember once at a Delphi launch, here in the Netherlands, that someone asked when will Delphi support .NET 2.0? The anwser: Within a few months after its release. OK we know that a few month became a few month more, but what the hack we can wait, we want to do Delphi, also in .NET!

Finally its there, but it is crippled without the winforms designer support.

What does this mean for Delphi.NET Winform developers?
This one is not hard to answer. Delphi .NET and C# programmers will have no form designer if they move forward to .NET 2.0 and beyond. Be assured you can manually code your design (Yeah, yeah I am looking forward to that...) and compile your code. So basically they are forced to move to either VCL.NET or VS. The first option, VCL.NET, is, imo, not a real option because the lack of thirdparty components. So the only valid option looks to be, to move on to VS. This will drive those developers away from Delphi, is that the goal? I doubt that.

What does this all mean for Delphi as a product?
Well I can only write down my own opinion here, but I think it is a bad mistake. Whether we like it or not .NET will become more and more the synoniem for Windows Development. Win32 will be supported for a long, long time but from a business point of view as well from a personal point of view (jobs) you can't deny .NET when you development has a focus on Windows. You just can't.

What for appeal has a .NET IDE with only ASP.NET support?
Personally I think it is more logic to have an IDE that support both.

Is VCL.NET a true alternative for Winforms?
I don't think so. I don't know if it is used often, but it seriously lacks thirdparty support.

I think that Delphi will continue to be strong on native Win32/64, but its .NET participation will decline.

What does this mean for me?
I always tried to pick the right tools for the right job. At this moment I do projects in Delphi 2007 Win32(60%), Delphi .NET(10%) and Visual Studio 2005 C# ASP.NET(30%).
In the long term I will probably move my Delphi .NET applications to VS C#. Fortunately they are not that big, but it will cost me some time. I think it is a pitty, because VS2005 has also it's quirks. Even now I find that Delphi .NET (the IDE) has some advantages compared to VS. (Still can't get used to the endless list of tabs in VS)
Delphi will stay to be my number one tool in the Win32/64 native development world, but on .NET it will be another story.

The roadmap
Nevertheless the roadmap has some great things for the near future (Unicode, Win64). However I find it a bad sign that the roadmap is not clear on the Winforms departure, which has great impact on the developers using it.
It seems that messages from CodeGear now, and Borland in the past, are still driving confusion, and that will affect its customers, and eventually CodeGear self.

Trouble installing update #1, frozen Collecting Information page?

Installing Delphi update #1 on my desktop machine was smooth and rather fast ( less than a hour). On my laptop however it was a different story. :-(
The installation was "frozen" on the Collection Information page. Something that took only 5 seconds or so on my desktop PC.
After waiting for 3 hours I killed the process and downloaded the 700 Mb installation from CodeGear here.
Again all "hanged" on the Collecting information page. Having not that much patient anymore I killed the setup process within a hour.

Fortunately Robert M. Lincoln had just posted a thread in the non-tech that he had the same problem and solved it by disabling all the startup apps using the MSConfig.

(3) This time, I ran MSCONFIG, and disabled allstartup programs (using "Selective Startup", uncheck"Load startup items", leave checked "Load SystemServices", "Use original boot configuration" is checkedand greyed out). After rebooting, I ran as in (2) aboveusing the DVD from the ISO file.This time, success!

Installation was just as fast as on my desktop PC! :-)
Now wondering what app blocked the installation?

Delphi / C++ Builder roadmap

The Delphi and C++Builder roadmap is available on the Developer Network.

Basically it drills down to this:

Second half 2007: Delphi "Highlander"
Containing support for .NET 2.0 en .NET 3.0 compatibility. All personalities will be in the Rad Studio 2007.

First half 2008: Delphi "Tiburón"
This version is about Unicode and Generics

Somewhere in 2009: Delphi "Tiburón +"
Native 64 bit support (VCL for Win64)
Support for multi-core/multi-threaded development

The direction of this roadmap seems to be OK. But that all depends strongly on what technologies you use. Overall I think it is a good roadmap.

All the details in the roadmap.

Delphi 2007 update #1 is available

Delphi 2007 Update #1 is available for registered Delphi 2007 users. It will come through the automatic update function, or in the traditional way as a download here.

As you can see the update will uninstall you current Delphi 2007 installation, and then reinstall the one with the update. First question that raises is:

Now I will have to reinstall all components again?

The answer is No, you don't have to reinstall all components, as stated by Nick Hodges in this non-tech newsgroup thread. His exact words: "Nope -- all your settings will be retained. " .

Another tip, have your serialnumber available, because it is required for the install. (In case you are at home and the serials are in your office ;-) )
Updated: Argg I did not read the Installation notes properly, as Dave Keighan says in the comments it is not necessary to have your serials. (Only for new installation I guess) I could install update 1 immediately after all. ;0

More info in the Installation Notes for Delphi® 2007 for Win32® Update 1 document.

Delphi 2007 update #1, coming soon

Chris Pattinson posted the QC list for the Delphi 2007 Update #1.
More then 300! fixes is this update.

Read the complete list at this CDN article.

The update should come automatically for registered users through the new installer function, "Check for updates"