software development, windows

CodeGear abandons .NET Windows Forms?

10 Comments

Intriguing blog post here suggests that future versions of Delphi .NET will not support Windows Forms, the most widely used GUI library for .NET. Apparently the Delphi 2006 Windows Forms designer will not appear in Delphi “Highlander”. If you want to do GUI work in Delphi .NET, you will have to use VCL.NET, or else make do without a designer.

At first glance this looks like a mistake. The main problem is third party components. There are plenty around for Windows Forms, few for VCL.NET. OK, you can import a Windows Forms component and use it in VCL.NET, but it’s not ideal.

Then again, what is the future for Delphi .NET? Pretty uncertain, judging by what CEO Jim Douglas told me. If the speculation about Windows Forms in Delphi is correct, then anyone who invested in Delphi Windows Forms development has been left stranded. Might not the same happen to VCL.NET developers? And what are the implication for WPF, a much nicer GUI library than Windows Forms though immature and little-used at the moment? Developers hate this kind of uncertainty.

10 thoughts on “CodeGear abandons .NET Windows Forms?”

  1. anyone who invested in Delphi Windows Forms development has been left stranded

    Yes, all three of them… Anyhow, CodeGear’s priorities with respect to Delphi (as set out on the recent-ish roadmap) seem about right to me, given their resources. The shame is that the years between D7 and D2006 cannot be relived…

  2. Tim,

    I thought the same when I first heard this (as did most other Delphi users from reading the newsgroups) but upon further reading and listening, it became clear(er).

    It would appear that Microsoft are moving away from it too. They aren’t dropping it but they’re saying that it will no longer evolve. WPF is certainly being billed as the new WinForms (see here for example).

    I admit I think it’s a concern for those who have WinForm applications but once .NET 3.0/3.5 is out, then WPF will be pushed forward and WinForms will be, effectively legacy.

    For me I think they might have done well to just leave it alone for those who need to migrate (again) but we don’t appear to have had a definitive answer from CodeGear as to why they have taken such a controversial decision.

  3. Delphi developers care about the language and the framework, VCL. Continuing to support the VCL on native and managed code gives Delphi developers the unique/RAD advantage. Continuing our support of VCL on native code (win32), managed code (.Net) and (according to our roadmap) extending VCL to unicode and Win64 in the future gives Delphi developers an outstanding advantage over just using Windows API or the .NET FCL (which continues to change over time).

    Delphi developers know what they have with VCL and the thousands of VCL components that are available to be used on Windows and .NET.

  4. Yes, all three of them

    Agreed, but are there really many more developers using VCL.NET for GUI work? As I mentioned, the main issue is with 3rd party components.

    Tim

  5. Delphi developers care about the language and the framework, VCL

    Thanks for the comment, David. In the end though, Delphi developers just want to get their work done.

    Most people accept, I think, that Codegear has limited resources and needs to focus. Perhaps discarding winforms makes sense. That said, this hasn’t been communicated well. Rather than simply waiting for us to spot that it was missing from the roadmap, it would have been better to be upfront about the decision.

    Tim

  6. It would appear that Microsoft are moving away from it too.

    True, but even Microsoft recommends not to use WPF for line of business apps in .NET 2.0, which is what Highlander targets. Surely it would not have been that hard for Codegear to maintain its existing winform designer in Highlander? But the other issue is about confidence. Someone considering a Delphi .NET project may say, “look what happened to winform support” and have less confidence in the product.

    Tim

  7. > Tim: Someone considering a Delphi .NET project may say, “look what happened to winform support” and have less confidence in the product.

    We have been consistent with VCL support from the beginning. We are continuing to move VCL forward on native and managed code. VCL is the road to 64-bit and other places. Delphi+VCL is the power.

  8. > Tim said: That said, this hasn’t been communicated well. Rather than simply waiting for us to spot that it was missing from the roadmap, it would have been better to be upfront about the decision.

    We’ve been telling all developers that we are focused on Delphi and VCL. We held a series of 8 online chats with developers and put the replays up (including the Q&A sections) on our developer network site. I will see about putting up a “what’s not in the roadmap” section.

  9. > Tim says: Agreed, but are there really many more developers using VCL.NET for GUI work? As I mentioned, the main issue is with 3rd party components.

    There are loads of VCL components that work just fine for native and managed code. In many cases, you just recompile your components and applications.

Comments are closed.