Re: DevExpress and VCL.NET

From: a (blwatters_at_shaw.ca)
Date: 01/31/05 

Date: Sun, 30 Jan 2005 18:51:14 -0800

Johnnie,

> Am I the only developer that feels that DevExpress, the PREMIER component
> vendor for Delphi has wasted their time and money supporting VCL.NET? I
> mean, they have superb .NET products; why does Quantum Grid 5 and other
> libraries have to support VCL.NET? Even the latest Delphi incarnations can
> use their EXISTING products.

Well what is the alternative?

Do they waste their time writing for WinForms 1.x? Considering that
Microsoft
is currently in the process of rewriting them, this would be silly. I don't
know
of a single developer willing to write a major app in WinForms right now
because everyone knows that MS is rewriting them in order to get around
some of the fundimental problems with it. Even when MS releases this, we'll
have to wait for Delphi 2006 (at the earliest), *hope* that it works well
enough to use, wait for everyone to come out with enough WinForms 2.x
components to actually be useful, and then rewrite our apps for the new
windowing and event model.

At best, DevEx could do what most developers are doing and wait until
2006 or 2007 before it knows whether this would fly.

OR....

They could write for the VCL.NET now. This means they:
a) don't have to completely rewrite their components because they were
written for the VCL model to start with.
b) don't have to wait for MS to get it's act together.
c) can provide tools now rather than in two or three years.

Most people using DevEx are folks using it in Delphi 7 and needing an
upgrade path to .NET. If DevEx included only some WinForms
controls, all their clients would have to completely rewrite their
applications. I assume they have done the numbers and it is a good
business decision.

Relevant Pages

  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... MFC and WinForms do not. ... For the Delphi developer, there is less of an argument. ... How many VCL Win32 customers have been asking their vendors to support ... Delphi developers, moving their existing Win32 application to .NET ...
    (borland.public.delphi.non-technical)
  • Re: The New Roadmap
    ... WinForms is not my first choice for .Net UI apps. ... for the VCL since Delphi 1. ... VCL in both places where it makes sense. ... Why would you ever *need* to write a .NET GUI app? ...
    (borland.public.delphi.non-technical)
  • Re: VCL.NET revisited...
    ... That's probably because I *am* an existing Delphi developer (among ... WinForms but I'm hard put to blame all the sluggish response of .NET ... Adding Avalon support isn't what I had in mind for new WinForms ... The .Net framework, yes, but not WinForms. ...
    (borland.public.delphi.non-technical)
  • Re: Best Blog Entry in Years
    ... the customers tell me they want to run in a safe environment as .NET code. ... Mixed mode compiler does not help here - and I do not want to rewrite all ... There is no different paradigm between native code and .NET code ... Strikes me as counter intuitive - if you have a large code base in Delphi ...
    (borland.public.delphi.non-technical)
  • Re: Delphi 8 info
    ... > can't put VCL.NET components on a Winforms form and vice versa. ... not floating like in Delphi. ... Deployment of the .NET runtime is a short-term issue. ... VCL.NET runtime classes into a monolithic exe or can link against the ...
    (borland.public.delphi.non-technical)