Re: Captain Jake's Top Ten List of what I'd like to see in thenextversionofDelphi



Brian Moelk wrote:

Can you put a WinForms component on a VCL.NET form? Is that better
interop?

It would be nice if you could seamlessly do that. However, if you
really want to, you can create winForms in assemblies and call them
from a VCL.NET app. (or visa versa).

Apples to oranges. VCL and WinForms have similar philosophical
approaches; MFC and WinForms do not.

Perhaps my example is too extreme, but the point is, what is the
argument for switching to a managed environment from native code that
'works fine'?

I think this statement assumes that Borland's customers are idiots.
We all saw that you can recompile fishfact for .NET. But at the end
of the day, I think customers are wondering why fishfact on .NET made
any difference at all since fishfact works just fine on Win32.

Fishfact doesn't use any 3rd party components. If you're going to move
your Delphi apps to .net and expand in that direction, you don't want
to have to go back to using just what's in the box. And you certainly
don't want to have to shoulder the burden of porting 3rd party
components to .net yourself. That's what you'd want the vendor to do,
and release an update, as they would for ANY new version of Delphi.
Borland need to get those pieces in place to make VCL.NET a more viable
option. They didn't really do that. There were mixed messages about
the purpose and future of VCL in a .net environment, and I think that
created a lot of doubt as to why one would take the risk, especially
when it was obvious that many Delphi component vendors were NOT.

There is also little reason for 3rd party vendors to support VCL.NET
as well. If the solution to this problem is to sell .NET itself, then
Borland's in a tough position. They would have to sell .NET over VCL
Win32, but not oversell it for developers to adopt WinForms.

The problem, in my opinion, is that all too many people, particularly
development managers, have created a single inseparable trinity out of
WinForms + C# + .NET. Clearly C# isn't the only language for .net or
winforms, and WinForms isn't the only Windows library for .NET (since
VCL.NET exists). By allowing Microsoft to dictate the lay of the
battlefield, Borland has put Delphi at a disadvantage. Some serious
selling needs to happen to convince people (particularly managers who
don't know better) that .net is the underlying platform, that C# is
just one possible language and that WinForms is just one possible
framework, and that development organizations can and should feel free
to mix and match on .NET.

In other words, they must be able to easily articulate the advantages
of VCL.NET over WinForms in about 10 seconds flat. The only story
they have is code migration. Sorry, fishfact isn't enough and I
think the track record shows that it's not.

I agree that FishFact isn't enough. I disagree with you that the only
story is code migration. I'd also say that a flatter .net learning
curve and better UI performance are also elements. Also, code
migration doesn't have to be a one way street as it is with C# and
VB.NET. If your code still builds as win32, you can target those who
want to use .net and those who want to use win32.

Sorry Randy, I don't believe this is about Borland's failed evangelism
or marketing. It's about Borland's failed VCL.NET strategy itself.

You haven't substantiated this at ALL.

I disagree. I think it is an intrinsic problem with the framework.
It's the wrong strategy.

WHY?

This always strikes me as crazy argument. .NET and Win32 aren't
really multiple platforms that people really care about. They are
both pretty much "windows-only" platforms. Unless DevCo embraces
mono whole hog, that's my take on it.

Microsoft will drag us kicking and screaming into .net if they have to.
This argument will be one we laugh about in 3 years time.

Better, IMO, includes compatibility with WinForms components.

Why drag VCL.NET performance into the WinForms sewer?

As far as your 'wrapping MS technology' statement. No amount of
wrapping is going to make WinForms anything other than the piece o
junk I think it is.

And here's where marketing by zealotry begins... ;)

Look, I'm not against WinForms because of VCL. I'm against WinForms
because in the 3 years that I've been coding against it, I've grown to
loathe it on its own terms.

Randy


--

.



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: 64-bit Windows for AMD 64 is here...
    ... > All that was demonstrated is that VCL.net is less capable than VCL ... than the rather poor WinForms. ... old Win32 API structures in an OO coating. ... I mentioned that one of the strong points of Delphi is is compatibility ...
    (borland.public.delphi.non-technical)
  • Re: Pleased...
    ... WinForms as a UI...nearly as fast as native Win32 Delphi code. ... ..NET) applications that are not reliant on the VCL.NET. ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionof Delphi
    ... Better interop with ... Can you put a WinForms component on a VCL.NET form? ... Win32 or WinForms. ... the Delphi Win32 development on board the VCL.NET train, ...
    (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)