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

Randy Magruder wrote:
Garbage collection, no more refcounting for interfaces, with the nasty
self-referencing workarounds you have to do. Better interop with
things NOT written in Delphi (C# assemblies), and whatever is cutting
edge .net stuff that's coming out right out of the box.

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

I think I have a better chance of getting components I want if I use VCL
Win32 or WinForms.

One might also ask why .NET at all PERIOD. Those MFC apps performed
better than WinForms, so what's the advantage in moving to .NET AT ALL?

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

That's Borland's fault. They did not do what they needed to do to get
the Delphi Win32 development on board the VCL.NET train, and that shows
in the relatively low #s of ported apps and components.

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.

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.

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.

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.

DevCo has
catching up to do here to carry the Delphi Win32 successfully into
VCL.NET. They have work to do. It's not an intrinsic problem with the
framework.

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

Insert the necessary "In your opinion" here. It's both useful for
multi-platform and interop and the ability to continue to re-use legacy
code without re-writing it in a new environment.

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.

In terms of interop, .NET itself already has hooks for interop. Wrap
your Win32 code up in COM or a web service and you're well on your way
to interop. Code level compatibility is just not that significant.

I would hate to see DevCo take your advise and wave the white flag on
VCL.NET. It is a better solution than WinForms, and should be built
upon as the better alternative to rich client .NET development. What
failings it has up to this point are solveable, both technically and
from a marketing/devrel perspective.

It's failings might be "solveable" but at what cost? And more
importantly what strategic advantage?

Having ECO use it as well will
help (and its inability to be a VCL.NET solution has been a problem
both for ECO and for VCL.NET).

It's not only a problem, it's just crazy.

Yeah so why drag it down by making it a SlowForms only technology? It
should absolutely be part and parcel of the VCL.NET strategy moving
forward. DevCo's slogan could and should be: "Making .net Development
Better"

Better, IMO, includes compatibility with WinForms components.

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... ;)

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

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)
  • D2006 Smooth InterOperator, was Re: John Kaster in Milwaukee
    ... Run .Net code from Win32 applications without COM ... Delphi for .NET can be used to create unmanaged exports for poorer kids like ... one wonder why they are not just using COM interop instead then. ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... MFC and WinForms do not. ... We all saw that you can recompile fishfact for .NET. ... as they would for ANY new version of Delphi. ... Win32, but not oversell it for developers to adopt WinForms. ...
    (borland.public.delphi.non-technical)