Re: My rant about the "throw out delphi and re-write it in C#" crowd.



The fact is this: our strategy is to migrate our current app to .NET
and Windows Forms. We do not want to write new code in VCL.NET.

Okay, if the idea is to move to windows forms and that's a strategic
move for you, go right ahead. I'm not sure how that's an indictment of
vcl.net other than you've made a decision to go another way.

Nonetheless, those that observed that you missed the point of my 'rant'
were correct. You DID miss it. Your GOAL is C#. My rant was
addressing people who assume that legacy apps MUST be rewritten to move
to .NET. That is simply not true.

We want to write new code in Windows Forms and C# because that is
where we will be able to get programming resources easily

Probably true -- sounds like the same rationale behind using Visual
Basic 6 (poor souls).

and we will
be able to share code/forms/objects with other Visual Studio
developers in our company.

Define "share". It's important to know how fully you think you have to
'share' to be productive. A VCL.NET app is a full .net app, and if you
make .net assemblies that have vcl.net forms in them, those using
Visual Studio can still load and use those assemblies with no problems.
Obviously they won't be able to change them and recompile them in
Visual Studio, but interop is there as they are both fully managed and
interoperable .net binaries.

Our choice for the future is C# and Windows Forms. Whether that's
using BDS or Visual Studio will depend on which one does it better.

If you have to maintain any existing Delphi code, or you need to make
Delphi code interop with C#/.NET written by others, then BDS is a
better choice. If you have the luxury of a clean break, then do
whatever suits ya (but you won't have ECO <G>).

had a dream that I could mix and match, but obviously this isn't the
case. >

You *can* mix and match, just not within a single form. You just
wanted a level of mix 'n match that was fundamentally at odds with the
fact that the the FORMS part of the framework is at odds.

agree, Win Forms is definitely not better than VCL in it's current
incarnation, but if you consider how much it's improved in V2 and how
little VCL has changed, I'm confident that it is a safe bet and it
will probably surpass VCL in Win Forms V3, especially with guys like
Anders behind it and the Framework.

Anders is not 'behind' WinForms per se. He's Chief Architect of the C#
language and, in his own words, there is only a 'dotted line'
relationship between him and the .NET CLR. He's never alluded to any
direct influence over WinForms itself that I've seen. It's funny how
things come full circle. WinForms started by slapping huge areas of
designer code [that they don't want you to touch] directly into the
form code of a single file. Now they wanted to get that out into a
separate file, so now they are using partial classes to do that. And
in the next couple of years, we get XAML, which bears an amazing
resemblance to an XML-equivalent of a VCL DFM. Funny how it comes
full circle, isn't it? Anyway, I haven't seen any real improvements in
WinForms in v2 of .net. Asp.net, that's another story, but I can count
on one hand the # of talks I've seen or papers I've read by Microsoft
people about improvements to WinForms in V2. It's pretty stagnant as
they wait for the XAML/WPF stuff to show up in Vista. The next time we
get anything really new will be with that, on the WinForms side.

As far as VCL goes, what's MISSING that needs to be added? If you look
at VCL as a Form Designer system, it's been evolved some (adding the
guidelines, and some new components). If you look at it as a class
library, not much has been added, but with VCL.NET you can freely use
anything you want in the Microsoft FCL. I have lines of code that mix
the two of them very liberally with no ill effects, especially when one
does something the other doesn't do well.

So our goal is WinForms. If I can't mix and match, I'll have to
convert. I guess my use of Frames complicates things, but that's how
it is for me.

Well, you know better than me what you want to do with your business.
But I honestly have found WinForms to be very unsatisfying in many
ways. My preference would be VCL.NET for technical reasons, and I
concede there is political pressure to go the way of Redmond. But then
what else is new?

In terms of testing Delphi 2006, I did enough to realize that it was
not a trivial matter to mix frameworks (even though I thought this
would be easy because they're on the same "framework"). The last
thing I'm willing to sacrifice is a major drop in productivity and
stability doing translations backwards and forwards.

Well, I have to say that it honestly sounds like you're needlessly
going to re-write when you could go for a more evolutionary port and
mix in C# at will. But hey, if you have the development resources and
schedule that let you start all over again, go right ahead. It's not
the pragmatic choice for people with limited resources, but when you
have the luxury of time, you can undertake many tasks that others
cannot.


BTW Has anyone noticed a speed difference between dbGo for .NET and
dbGo for Win32. It seems a lot slower in .NET???

I would expect it to be slower because it has to go through the
P/Invoke Interop layer. It's the worst of all options, but it's good
if your legacy code uses ADO and you don't want to change that code. I
would rather use dbExpress if I had any kind of choice. I'm trying to
make most of my VCL code use ClientDataSets so I can hot-swap data
access technologies when I need to.

Don't hate me too much!

I don't hate you at all. But it's tough to debate someone on technical
merit when they drag so many non-technical preferences into the
discussion, and you gave all appearances of being more interested in
deciding FIRST go with Winforms and Microsoft, and DONT ship anything
that MS doesn't ...and then concluding from that you and BDS have to
part ways. That's fine if that's how you're making your decision, but
it isn't truly a technical reason - it's more of an allegiance issue.

I just expected more. I feel like a VB 6 user trying to get to
VB.NET. This is not what I was promised.

What promise was broken? Can you reference a promise made by Borland
about BDS that they broke?

Randy
.



Relevant Pages

  • Re: Discussion: "Why Visual Studion 2005 is better then BDS 2006?"
    ... In terms of Windows class libraries, I'd say VCL is better than ... anything I've seen in Visual Studio land. ... Not restricted to .NET 1.1 as BDS is now. ...
    (borland.public.delphi.non-technical)
  • Re: Is there any hope for Microsoft ?
    ... in BDS 2007). ... Assuming that WPF doesn't suffer the same fate as WinForms and get ... I'd be surprised, but I was surprised with the WinForms thing, too. ... I'm not sure how VCL vs WPF will shake out. ...
    (borland.public.delphi.non-technical)
  • Re: My rant about the "throw out delphi and re-write it in C#" crowd.
    ... nothing out there that I've seen for WinForms that hasn't already been ... done to death by 3rd party vendors for VCL? ... thought we were talking about being able to port Delphi applications to ... Drop it on a Windows Form. ...
    (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: 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)