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.
14 comments:
I agree, I'm not quite sure what's going on here. I can't understand why CG think dropping design support for WinForms can possibly work? Surely if they're going to allow .NET development as part of the design tools, they have to support the standard as well as their own VCL.NET forms?
I've not made any move towards .NET yet but was hoping to stick with Delphi, but this has made me think twice. Did Nick explain in that thread why they've made this decision?
Don't forget Chrome - object pascal in visual studio.
CodeGear has lost any meanful leadership years ago. If RemObjects ever branches out into win32 code, CodeGear might as well close their doors.
It would be way better if VCL.NET could handle WinForms components. Maybe CodeGear can be convinced of implementing this...
Hi Roland, I read your posts on "non technical" newsgroups about the decision of dropping WinForms support in the future releases of Delphi.
I developed a WinForms application in the past, too.
However, I started thinking about what could have driven that decision.
As Nick said many times, WinForms technology is becoming more and more dependent on the IDE, so this seems to make keeping in sync with Microsoft technology harder and more difficult.
I think VCL.NET is a great opportunity (for those who are interested in targeting the .NET Framework platform, of course).
I found myself coding an internal company library with dual code, for Win32 & .NET, without much effort, having great results and satisfaction!
You said that there are no third party components for VCL.NET, but most of the VCL components outside in the world can become VCL.NET components with some changes or - a lot of times - just recompiling them!
I hope CodeGear leave the "WinForms Component Import" utility, to let Delphi developers wrap WinForms controls and use them in VCL.NET application, fulfilling all the possibile situations.
I think that dropping WinForms can be a good move if CodeGear shifts all the resources busy with Microsoft technology to extend capabilities and source-compatibility of VCL.NET, also leveraging the fact that VCL Win32 will become Unicode based very soon.
I know that migrating a WinForms application or maintaining it with a previous version of Delphi (and of the .NET Framework, appareantly 1.1) is not the best solution, but I try to think about the possibilities on the VCL.NET side, which I prefer over WinForms (too immature, too many bugs, few out-of-the-box components, no purely graphic controls, no DataModules, no cross-module references, no ActionList...and I hate the designer!). :-)
Regards!
Marco from Italy
> How can a roadmap talk about design enhancements, but in fact drop it?
I'm also not sure what's going on, CodeGear is not clear here. .NET 3.x without design tools support: I can't imagine how. Maybe... are CG Delphi team planning your new _own_ compatible WinForms designer (...!!) ?
Hi Marco,
The reason that I choose to build some applications in Delphi .NET winforms were customer driven. My customer had specifications about the, to use components, which were not available in VCL.NET. I tried to wrap them in VCL.NET with no success. Having a large Win32 Delphi core classes it seemed to be the most logical choice to use Delphi .NET, I also 'cross compile' those classes between Win32 and .NET.
Greetings,
Roland
Btw in about three weeks I will be in Italy too. :)
I've been around since Turbo Pascal 1.0 for CP/M. OK, There are my qualifications. Here is my concern here:
I like the VCL, and as a developer I don't care much about Winforms. HOWEVER... The people we work for care a lot about it. I can just herar it now, "What? Delphi doesn't even support Winforms? And you want us to buy it?"
There's the problem. It's one of market viability. Studebaker built great cars, and threw beautiful superchargers into them. Great stuff. You can now see them in the Studebaker Museum in South Bend, Indiana. But you will NOT see them in a new car dealership.
Am I making my point??
We have been "busting our b##s" to convert from VB6 to Delphi. We started with Delphi 2006 and we now have D2007. One of the huge positives about Delphi was the ability to do native Win32 and .NET. The reason we want to do .NET is the huge number of first quality 3rd party tools. The fact that WinForms is going to be dropped and hence the elimination of this large number of 3rd party tools is a complete show stopper for us. We have essentially wasted 12 months of intense effort. Do I think CodeGear is making a mistake? Oh Yes! to be sure, but with this decision then we won't be programming Delphi.
I am so angry about this.
Dr. Fritz Klein
UNC Medical School
Medical Education IT
Well as your post said, use the best tool for the job. If you're doing WinForms, of course the best tool to be using would be Visual Studio, no doubt about it. Why are you wasting time doing WinForms development in Delphi?
I sincerely hope CodeGear concentrates on the VCL and VCL.NET, and stop trying to compete with Microosft.
--Anonymous
I think he ment the best tool for the job. Not the best tool.
There will be a VCL RAD designer for Win32 and .NET in Highlander. This gives Delphi developers the unique advantage for their development. You can still use code to create WinForms applications just as you can use code to build Windows API applications with Delphi.
The VCL is the power of Delphi.
David, that's very good but you will need to either strengthen your strategic relaionships with the component vendors or do some nifty work to allow us to wrap .NET components without issue and with full Designer support. I have been talking with both Infragistics and DevEXpress (both of whom I have used in the past) and both who are dismayed that Codegear is continuing to arrogantly disregard the sue of these excellent 3dr party components. It's a recipe for disaster and will result in many migrating over to Visual Studio
What is about Mono. If you use VCL.NET you can't run the application on Mono. VCL.NET uses Win32 API- Calls. If B... ups CodeGear removes this unmanaged code VCL.NET it's an option. But it's not in sight.
Removing the winforms- designer is the biggest mistake CodeGear has made. There is no reason to use RAD Studio. Coding everything manual? I think VS with Chrome is a better choice.
Hi,
I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading.
Nice blog. I will keep visiting this blog very often.
-
Delphi development
Post a Comment