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

Randy Magruder 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).

Ugly.

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'?

For the Delphi developer, there is less of an argument. Especially if
you're doing VCL Win32.

I would argue the strength and breadth of the .NET framework itself, or
the practical realities of employment and web hosting.

Merely arguing stuff like "garbage collection" as a productivity
increase is meaningless. Delphi developers will have a learning curve
going to .NET and they already feel quite comfortable with taking their
trash out themselves.

Also, there is no end-user benefit driving .NET adoption either. On the
contrary, if you're doing client GUI's the installation of the framework
itself could be viewed as a detriment.

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.

Certainly, and this is a problem.

That's what you'd want the vendor to do,
and release an update, as they would for ANY new version of Delphi.

But those vendors aren't doing so. Why? Cause the market for VCL.NET
is vastly smaller than the Winforms component market.

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.

It has nothing to do with Borland and their ability to communicate!
Again, this isn't an evangelism or marketing failure.

IMO, this is purely an economic decision that these component vendors
made. Supporting VCL.NET will give them very little new revenue,
whereas supporting Winforms will give them potential for a lot of revenue.

How many VCL Win32 customers have been asking their vendors to support
VCL.NET? I would venture to say virtually none. Why? Because for most
Delphi developers, moving their existing Win32 application to .NET
doesn't make sense.

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.

This is their perception, but in some ways it is based on some
reasonable facets of reality: 1) .NET 2.0 support and 2) CF support.

Besides, it's much easier for people to compare .NET to Java. It was
bound to happen in management's perception even if the reality is different.

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.

As if Borland *allows* MS to do anything. That's laughable.

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.

Borland can't even sell its *Delphi* developers. They can't sell me and
they can't sell a lot of Delphi developers that I know that are using or
moving to .NET.

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.

Flattening the learning curve is a *migration* issue. Besides
flattening the learning curve in this fashion also raises the
incompatibility between Delphi for .NET programmers and the rest of the
"vanilla" .NET programmers out there.

IMO, sometimes it's actually better to learn something new and struggle
with the learning curve. The investment in traversing that learning
curve yields better cohesiveness in more .NET shops and across them.

Better UI performance, ok, but like I said, many customers don't care.
We as developers are very sensitive to things like that, but end-users
in my experience aren't and seem to be content with WinForms apps.

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 think I have considering that I haven't heard any arguments why Delphi
developers should use Delphi for .NET and VCL.NET as they adopt .NET
development.

I can also just point at the scoreboard. I think the usage patterns of
BDS speak for themselves, Delphi developers aren't idiots. If there was
a compelling reason to use Delphi for .NET and VCL.NET for .NET
development, they'd be doing it. But most are using Delphi for Win32
work. Most of those that I know that are doing .NET development, are
using C# and VS.NET.

Saying that it's marketing or evangelism is the classic Borland scape
goat. It's bogus.

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

WHY?

Because there's nothing compelling in Delphi for .NET and VCL.NET. The
only sales pitch is migration: migration of code and skills. But it
falls flat on its face because Delphi Win32 works just fine, and without
broad 3rd party vendor support it's not even a feasible migration story.

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.

I think MS would be crazy to drop Win32 support in their OS' for the
foreseeable future.

I agree that they want everyone on .NET, but my point is that end-users
only care if it will run on their machines. If their machines run
Windows, they don't give a rats ass if the underlying technology is .NET
or Win32.

Better, IMO, includes compatibility with WinForms components.

Why drag VCL.NET performance into the WinForms sewer?

3rd party component choice.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: How can you drop Winforms support?
    ... Being able to use that shiny VCL Office 2007 Ribbon Bar from ... The support for WinForms in Delphi ... Get 3rd paty developers on board with a partner VCL.NET program with the idea of a coordinated release of the VCL.NET IDE and VCL.NET 3rd party ports to get an initial influx of the biggest 3rd party names. ...
    (borland.public.delphi.non-technical)
  • Re: Thinking Clearly
    ... And I concede that not having .NET 2.0 support ... to most .NET developers. ... Delphi I can choose WinForms *or* VCL.NET. ...
    (borland.public.delphi.non-technical)
  • Re: Stop the negativism!
    ... of Delphi added features that wrapped the latest out of MS. ... But this strategy (and it upgrade income stream it generated) became more ... these coming platform evolutions when many developers ... The bottom line is that the core technology that Delphi rides on (the win32 ...
    (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: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... is vastly smaller than the Winforms component market. ... VCL.NET developers = less market for VCL.NET components. ... Borland has put Delphi at a disadvantage. ... code directly to the Win32 API. ...
    (borland.public.delphi.non-technical)