Re: How can you drop Winforms support?

On Mon, 25 Jun 2007 14:28:43 -0400, Brian Moelk <bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Randy Magruder wrote:
There has to be economic justification for third party vendors to
support VCL.NET.

Yes, and there need to be clouds before there will be rain. Anything
NEW to add, Brian??? :P

ISTM, you had overlooked that "small" factor in your previous post, so I
felt obliged to bring it to the fore of the discussion.

You can if you like, but it's such a basic common-sense assumption that it seems like a waste of time to raise it continuously, or do you know anyone here who thinks that 3rd party components should be produced out of the goodness of the vendors' hearts?

Again, I was mentioning this because you had used them as a specific
example (and first at that) to demonstrate that VCL.NET has good third
party support.

It *is* a supported product right now, and it's up to DevEx's usual standards. There's no reason not to use it if you have a project that can benefit from it.

As usual, you're missing the real question.

Hardly. "Significantly better" includes the underlying framework that
it's based upon. Do you really think I don't realize that .NET might
offer something different/better than Win32? I might be your nemesis,
but I'm only your nemesis because I'm not an idiot.

We're resorting to name calling? Gee, I expected better from you...

The real question is if VCL.NET can actually *leverage* it better and if
CodeGear is going to be willing to break compatibility for forward progress.

Define "leverage" as used in the above sentence.

Sure, but you're neglecting the fact that interop solutions exist today.

In my opinion, Interop sucks. But that's just me I suppose.

It's far easier to use Interop to sprinkle those good .NET bits into an
existing VCL Win32 application than it is to port the whole application
to .NET.

The only reason it is hard to port the whole thing to .net is the components. Unless you are writing really low level pointer-based code or going crazy calling Win32 stuff, your typical business application's biggest problems are going to be with 3rd party components, and NOT with your application level logic. So if the components exist for both sides of the fence, it removes the single biggest obstacle to 'porting'.

This benefits the end user how? Better performance? As you well know,
performance is more about how one writes their code.

I'm throwing it out there as a hypothetical. Pick any particular 'reason' you want why someone would want a .net application. Heck it could be political in nature ("we must have a .net product right now, it's a feature checkmark", saith the trendy Dev Manager). I don't care WHAT the reason is. I'm just saying pick any reason that you might want to use the underlying

The one thing you didn't mention is unicode support, which I believe you
get with .NET, not sure if you'd get it with VCL.NET.

I'll leave that up to roadmappers.

So I decide to port my VCL app to VCL.NET so I get that.
This has nothing to do with FCL/WinForms/ASP.NET. It's all about the
bytecodes. Being able to use that shiny VCL Office 2007 Ribbon Bar from
TMS in .net without modifications offers me the advantage of being able
to move my app lock, stock and barrel onto the .net framework while
still having the GUI that I didn't WANT to have to change.

Which the Delphi *market* has clearly *rejected*.

This is far too simplistic of a comment. You think the market rejected the idea 'in theory' or 'in practice'? There's a big difference. Something that sounds like a great idea, when poorly executed, will get rejected. Delphi.NET has, up to this point, had a LOT of things going against it, totally aside from whether it is a good idea:

1. The product was and is stuck in .net 1.1.
2. Microsoft hype-wave towards WinForms as *the* way apps are supposed to be developed
3. The product was not in great shape (Delphi 8)
4. The support for WinForms in Delphi (may have actually HURT things by re-inforcing the idea that WinForms, not VCL, was the future-- even for Delphi programmers, who might then just say -- well why not then just switch to VS.NET ?!)
5. The chicken 'n egg loop of 3rd party components. Borland should have had 3rd party vendors on board and releasing VCL.NET versions of their stuff from day 1 to give Delphi coders an incentive to move development to Delphi.NET. They didn't, there were no components, which meant no developers, which meant no components, and so on.

These and undoubtedly a few more all contributed to make Delphi.NET a ho-hum proposition at best. Something that was (and is) a great idea IN THEORY got torpedoed IN PRACTICE by poor execution and an unclear strategy. If we could turn back time and do the Delphi.NET launch again, it would have been:

1. VCL.NET only
2. Unicode support
3. Up to date with whatever version of .NET was out there
4. 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.
5. New classes that would match functionality people like in FCL (container classes, XML classes, etc).

Had they done all these things and EXECUTED them well, I think Delphi VCL.NET would have been a NATURAL option for Delphi developers, not the problem it has been. You believe at this point it's too late for VCL.NET. I couldn't disagree with you more strongly. I suppose you can resort to calling me names again if you like....but I think I made my point very clear here. WinForms and to some degree C# were diversions from what should have been a well executed Delphi-centric, VCL-on-any-platform strategy. CodeGear now realizes this, and also we realize that WinForms wasn't the holy grail it was hyped as being, and those two combined perhaps make for a climate more hospitable and resistant to the Microsoft hypewave than in the past, when MS was basically saying that all its OWN products were going to be .net based (right down to the operating system!). Microsoft couldn't have scripted a better headfake than they did in getting the rest of the development community to get off balance.

I'm saying that it hasn't been *enough* of an advantage for VCL.NET to
be a highly desired item.

I would say the same argument could then be made against WinForms/WPF.

The "right" question is: Why use VCL.NET when we have the VCL? It's
not just me that is asking this question, it's the whole Delphi community.

I think there is still some vestigal fear about the security in continuing with native development. On a technical level, Delphi native might win many arguments. At a broader, less technical level, it might not. We have gone from Microsoft promising .net for all to Microsoft moving ahead with more native code support (such as the Steve T's arguing it out in blogs). But do we really KNOW for sure that all the framework goodies Microsoft will add will be readily accessible to native code? No, I don't think we do. Microsoft can, at any time, make life miserable for native coders wanting to do this or that Vista thing or this or that WPF thing, or whatever. That puts native code developers in a somewhat precarious position. I honestly just have my doubts about whether we'll even be able to get access to some of the higher level framework technologies Microsoft is putting out. What about Silverlight ? What's its place out there for native coders? Microsoft continues to roll out their dev technologies as ..net, .net, .net. And even if they do surface native API's, will it be done in a timely fashion? There may yet be a need for developers to move something into the .NET space to take advantage of these things, and I honestly don't think many besides you are fond of interop solutions. If I may be so bold, it's easier to develop and debug one body of compiled code than be hopping across interop boundaries all the time, and that's assuming no performance issues.

What's wrong with thinking about interop? To me this is the most
logical and natural extension. It's exactly like using COM or dipping
into the Win32 API that Delphi developers have always done.

Please don't use COM as an argument for Interop. You start losing me right there. I'm not a big COM fan anymore.

IMO, a full port is insanity. It's uncertain that the ported
application will function *exactly* like the former which means
retesting *and* it doesn't offer as easy of a migration *back* to native
if it turns out that .NET isn't necessary or is rejected by one's customers.

I am a fairly big fan of a single source base if it is possible to obtain that. It should be able to be recompiled for .net or Win32 with little to no hassle. There may be testing issues that expose some things, but again, a properly written multi-platform framework is going to have those minimized to the point of no real impact.

Well, it's not like Kylix because Windows .NET and Windows Win32 is
still Windows. Linux is a different market entirely and is more
suitable for server applications than desktop ones.

Obviously. Don't get sidetracked onto which platforms I picked. Point is, the platform can be a separate decision than the UI, and one doesn't constrain the other. That's all I'm saying....and I think you actually KNOW that.

I can use interop techniques and leverage .NET if I choose to with
Delphi Win32 and VCL Win32.

Well, you know my position on the pain that is Interop.

That's hilarious, you use VCL.NET so that you can be "pretty confident"
that your application will look as good as your VCL application? Why
take the risk at all?

Well, if your attention span exceeds the last paragraph, because I was ASSUMING there was some underlying reason for changing platforms from Win32 to .NET. ASSUMING this is true, then the UI component issue ceases to be a deal breaker. You act as if the above paragraph was spoken in a vacuum.

Someone has to make VCL.NET *more* compelling which means breaking
backward compatibility with the VCL for *forward* progress. Otherwise,
there's no point at all in VCL.NET, might as well keep going with VCL.
Economic incentive.

One might pose many of the same criteria you posed upon VCL.NET upon WinForms and finding THAT technology falling flat on its face. What, honestly, is more spectacular about WinForms than VCL? So I can buy a WinForms DevEx quantumGrid and ribbon bar instead of a VCL DevEx quantumgrid and ribbon bar and use generally the same exact rad approach to writing my app? If you can't make a case that WinForms is superior to VCL development and worth jumping over to, then of course you're going to have the same problem with VCL.NET. Yet lots of people jumped to WInForms...call it Shemitz's "learn once, write anywhere" if you like...or just Microsoft's managing to scare the world into thinking they better move to MS .net or fall behind, but based upon being a superior development solution? I haven't seen that for WinForms.

I'm not going to sit here and tell you that VCL.NET is where it needs to be. It's not....absolutely not. But as long as there is a significant # of Delphi Win32 developers world wide who may at some point need to move to .NET, then there is a good reason to get rid of the distinction between VCL and VCL.NET and just call it VCL (for as many platforms as you like).

Any problems with VCL.NET were with execution of the plan, not the plan itself (and providing WinForms support for the last several years has NOT helped clarify the message!).,

Randy


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
.

Relevant Pages

  • 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: How can you drop Winforms support?
    ... I'm not certain you've provided any reason for those third party vendors ... that VCL simply cannot. ... The product was not in great shape (Delphi 8) ... meant no developers, which meant no components, and so on. ...
    (borland.public.delphi.non-technical)
  • 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: 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)
  • 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)