Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: "Randy Magruder" <rmagruder@xxxxxxxxxxxx>
- Date: 6 Feb 2006 06:20:30 -0700
Open a VCL.NET Form. Drop a Windows Forms Control on it (without
having to go through the convoluted process of importing it - and
getting that "experimental" compiler message which really makes me
feel comfortable). CAN'T DO IT.
You're right. So the question is: Why would you WANT to? Windows
Forms controls perform much worse than VCL.NET controls, and there's
nothing out there that I've seen for WinForms that hasn't already been
done to death by 3rd party vendors for VCL? So why are you trying to
cram a square peg into a round hole. What benefit do you get from it?
Open a VCL.NET Form. Drop an ADO.NET datasource on to it. CAN'T DOIT.
Now *this* has a bit more legitimacy to it than your control issue
above. On the other hand, I would also ask you why you are trying to
do this in this way? What is it you're trying to accomplish? VCL.NET
has dbExpress and dbGo ported for .net if you want to go that route,
heck you could even use BDE.NET (not saying you would..just that it's
there). So if you're trying to write an app in VCL.NET, why do you
want a ADO.NET datasource? Of course, if you are that desparate to use
an ado.net datasource, you could always code in WinForms using
Delphi.NET, but that's not what we're really talking about, is it? I
thought we were talking about being able to port Delphi applications to
..net?
Anybody out there use TFrames? My app makes extensive use of TFrames
instead of MDI. Create a TFrame. Drop it on a Windows Form. CANT DO
IT. (I tried to import a Windows Forms Frame (called user control)
into my VCL form. Got loads of random "stack overflows".
They're two DIFFERENT Frameworks!
Hello, YES!!! DUH!!! I By Jove I think he's got it! They're DIFFERENT
frameworks. But they are both equally .NET. And VCL.NET outperforms
WinForms in most respects. On the other hand, if you port your VCL code
to VCL.NET assemblies, you can interop quite nicely with any WinForms
app you want. It sounds like you're REALLY in love with Windows Forms
( a mystery in and of itself, based upon my experiences building apps
with WinForms). If you're SOOOO in love with WinForms, why are you
still trying to write UI with VCL.NET? And if you love VCL, why
are you trying to slap ungainly and godawful WinForms controls on your
VCL.NET forms?
The problem here isn't that there is anything inherently wrong with
VCL.NET, or anything inhrently wrong with Delphi's support for
WinForms, as both exist and work quite nicely. No, the problem here is
that you think VCL.net should *be* some kind of Windows Forms mutation,
and all I can say to that is that I'm forever glad it's NOT. You
haven't yet made any kind of case for why you'd want to start slapping
WinForms components and controls on perfectly good working VCL/Win32
forms that you want to compile in .NET. You do know, of course, that
even if Borland had provided you with that capability, the moment you
started slapping ado.net and winforms controls on your vcl.net forms,
they would no longer compile as Win32 code, right? Or did you expect
Borland to pull that off too?
Man, oh man, I'm glad you're not in charge of OUR migration
strategy...because you seem like the kind of person who opened the
software, tried to drop a winforms control on a vcl form and threw a
temper tantrum when it didn't work. Rather than understand what the
correct migration path should be from Delphi VCL to .NET, you just
tried to do it the obviously WRONG way and got mad when the tool
wouldn't let you do it.
I should have stated in my blog that porting VCL to VCL.NET would be a
strategy for clear thinking pragmatic programmers, not people who are
creating red herring arguments to mask the REAL issue: they don't want
to include anything in their app that Microsoft doesn't give them in
the OS.
You need to work on your debating strategy some. If you're trying to
make a case for not using anything not made by Microsoft, stick with
it...run with it...embrace it. BE the Xenophobe you are. But if you
are going to try to hide behind very shallow "the tool won't do this"
arguments, you might want to think about HIDING your Xenophobic
comments, so that people won't discover your true agenda and realize
that there's really nothing TO your technical arguments. They are just
a thin facade to cover your real agenda.
Randy
.
"Randy Magruder" wrote:
So I can recompile VCL to VCL.NET. WHO CARES?
Anyone who does not have the luxury of time to re-write from scratch
hundreds of thousands of lines of WORKING code, introducing all NEW
bugs in the process. But aside from that, no one, of course!
LARRY:
I don't have that luxury either, but what's worse: that or getting
stuck with a proprietry framework that hardly any .NET programmers
know. I also don't have the luxury of teaching new programmers the
entire VCL framework whenever we hire someone!
"Randy Magruder" wrote:
to >> integrate Win Forms and ADO.NET with VCL.NET.How many of you out there are pissed off that there's no easy way
Define "integrate". I can't answer this one til I know what it is
you tried to that you felt was not 'easy'.
LARRY:
See my points under "Prove it" above. I have VCL TFrames and a main
form that shows whichever frame is currently requested. I tried to
create Windows Forms "Frames" and import them into my app. This gave
me stack overflows (and the lovely "experimental" warning message").
I also wanted to replace dbGo with ADO.NET components. This can't be
done without rewriting every single data module unless I create the
objects in code. I would also have to set up hundreds of "connectors"
in code. Borland should have provided translation tools from VCL to
Windows Forms or some kind of VCL compatible layer ON TOP of Windows
Forms.
"Randy Magruder" wrote:
(itI refuse to get stuck with proprietry middleware like BDP andVCL.NET.
Just what is it Microsoft makes that isn't proprietary?
The .NET framework and Win Forms is part of the Operating System
WILL be included in any future client os) exactly like MDAC, so I
don't have to worry about client deployments or massive exe files
with entire frameworks in them.
This argument is so incredibly lame I'm not sure it deserves any
kind of response. One might equally argue that you should make all
your UI components just use whatever comes out of the box in Visual
Studio. All your apps can look like plain vanilla, with no
enhanced UI look and feel, no advanced capabilities like you get
with components from DevEx or Infragistics, etc, all because you
don't want to use anything that doesn't come "out of the box". Any
truly useful software you create and may want to resell is
undoubtedly going to require that you redistribute something that
you did NOT get out of the box from Microsoft. But then I forgot,
you have the luxury of huge amounts of time, so when you need a
complex customizable grid, I'm sure you'll just write it from
scratch because you have all the development time and money in the
world. Again, unlike we mere mortals. If the above truly
reflects your opinion, I already don't want to see any applications
you write. I expect they will be pretty vanilla. Boy, third
parties just suck, don't they?
LARRY:
Firstly I've only worked on one system for the last 2 years. It's
fairly large but you're right about the third-party components. I
never touch them. That's because I have the luxury of not having to
make my app look like a video game. My clients are happy with vanilla
grids and edit boxes. They care more that the thing works, even if 50
people are hammering it at the same time. I also don't have to worry
about upgrading to new versions of Delphi, since everything required
uses the "Vanilla" VCL. I don't need to rely on someone else's code -
just the VCL. My point however was not that one shouldn't use 3rd
party components (even though I would recommend only doing this if
absolutely necessary - not because you want your app to look like a
video game). It was that I do not want to be responsible for
deploying middleware-after-middleware on client PCs. You could argue
this about the .NET framework, but I see this as an Operating System
component - i.e. NOT 3rd party. In the very near future, .NET will be
as common as MDAC.
"Randy Magruder" wrote:
Since Delphi supports writing WinForms code, I'm not sure where your
rant is coming from?
LARRY:
Try doing VCL and Win Forms in the same project.
"Randy Magruder" wrote:
I'd hire the guy who is more pragmatic and is neither afraid of
tackling apps in C# or building and extending existing applications
written in Delphi.
LARRY:
I'm glad YOU have the luxury of time to train all your new
programmers on Delphi/.NET because no new programmer learns Delphi
and most .NET programmers don't know Delphi.
"Randy Magruder" wrote:
because you've clearly
gone Xenophobic when it comes to anything not produced by Microsoft
and shipped in every copy of Windows. Who needs that? I'll take a
pragmatic programmer who uses the right tool for the right job any
day over a zealot.
LARRY:
For Win32, Delphi is the right tool. For .NET, Visual Studio 2005 is
the right tool, not VCL.NET or Borland's average attempt at .NET V1.1
WinForms. Try this (if you have SQL Server): Open a WinForms app in
Delphi. Drop a SQLCommand object on your form. Set up the connection,
set the command type to "Stored Proc" and write in the name of the
Stored Proc. Click on the Parameters collection. Where are the
parameters? You have to code them yourself! Nice support for Windows
Forms, Borland! What does Delphi offer the Windows Forms user over
Visual Studio? Nothing - so how could Delphi ever attract new users?
Win32 will very shortly be a legacy platform. Where do you want to
get stuck?
- Follow-Ups:
- References:
- My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Randy Magruder
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: John Kaster (Borland)
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Randy Magruder
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: John Kaster (Borland)
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Steve Zimmelman
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: John Kaster (Borland)
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Steve Zimmelman
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: John Kaster (Borland)
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Ingvar Nilsen
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: John Kaster (Borland)
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Ingvar Nilsen
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Randy Magruder
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Larry
- My rant about the "throw out delphi and re-write it in C#" crowd.
- Prev by Date: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Next by Date: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Previous by thread: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Next by thread: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Index(es):
Relevant Pages
|
