Re: Does VCL have a future?

From: Dave Jewell (Dave.Jewell_at_btclick.com)
Date: 02/16/04


Date: Mon, 16 Feb 2004 20:04:06 -0000


"Craig Stuntz [TeamB]" <cstuntz@nospam.please [a.k.a. vertexsoftware.com]>
wrote in message news:403119d9$1@newsgroups.borland.com...

> To be pedantic: XAML is a means of describing an Avalon UI, and Avalon
> is one way --

Agreed.

> a way which appears to be superior to the other options
> in nearly every aspect -- of writing a Longhorn app.

As Microsoft themselves point out, Avalon is tied to Longhorn.
Consequently, if you're targeting Avalon (which is implicit in the use of
XAML) then you're cutting Windows XP, W2000, etc, out of the equation. This
might not be a "superior" option for some, but -- yes -- I see your note to
this effect at the end of your post.

> I'm not sure that's a safe assumption. Avalon uses its own rendering
> system (not GDI+, as with WinForms) and has a separate class structure.
> I don't know how much, if anything, they will have in common under the
> hood, but to the application developer they are totally different.

Yes, I am making some assumptions here. It would be easier if I had some
code to play around with, but I have not been thus favoured by Microsoft, so
far. <g> I think my key point was that the additional Avalon controls are
implemented in some managed code assemblies and that therefore (here's the
assumption) it ought to be possible to "get at" them in other ways. Whether
or not this is true (and how easy it is) remains to be seen.

> I don't agree with your interpretation of this statement, at least as
> I read what you wrote and MS wrote. I think MS is saying that Avalon
> is one option for writing Windows UIs. Maybe that's what you meant,
> but it looked to me like you were saying that Avalon uses the same
> controls as other frameworks, and I don't think that's what MS is
> saying here. Apologies in advance if I misunderstood you.

I just meant that Microsoft are adding the Avalon controls to the .NET
assemblies. It does seem to be possible to have a level of interoperability
between Avalon controls and the "classic" (so soon? <g>) WinForms controls.
This is borne out by the web link which Xavier gives elsewhere in this
thread. For example:

<MS quote>

There are three possible approaches when using the "Avalon" UI classes and
controls in a Windows Forms application:
  a.. Continue to use Windows Forms, adding "Avalon" controls or "Avalon"
windows to the Windows Forms application.
  b.. Create an "Avalon" application and reuse the existing Windows Forms
controls in the application.
  c.. Replace the Windows Forms UI of your application with a new
implementation built using "Avalon."
To support the first two cases, there is an "Avalon" control that can host
Windows Forms controls and a Windows Forms control that can host "Avalon"
controls. These hosting controls allow a developer to interchangeably mix
Windows Forms and "Avalon" controls, either on a Windows Forms form or in an
"Avalon" window.

</MS quote>

> At any rate, I think it is an important point that WinForms, Avalon,
> VCL for .NET, and the like are all options for developing UIs on .NET.

Agreed. This subthread was spawned around the issue of whether Winforms is
being phased out in Longhorn. Quoting again from Xavier's link, Microsoft
say this:

<MS quote>

First, it is important to note that the Windows Forms classes will continue
to be a central part of the Windows client as the platform moves first to
"Longhorn" and then beyond it. These classes will ship natively in
"Longhorn." Developers will be able to run existing Windows Forms client
applications on "Longhorn" and on the versions of the operating system that
follow it. Similarly, developers will also be able to use controls and forms
from both Windows Forms and the "Longhorn" UI classes ("Avalon").
Effectively, these two sets of classes will live side-by-side, and
developers will be able to use either of them.

</MS quote>

So I don't see any evidence of Winforms being dropped in the forseeable
future. I think Microsoft are smart enough to know that if they killed
Winforms when it's so young, people would be *very* wary of investing in
Avalon or indeed any of the new Longhorn technologies.

> They aren't part of the ECMA standard, and they all have their plusses
> and minuses. There may be more options in the future. To me it looks
> like Avalon will eventually be the best choice, but for the time being
> Avalon is hampered by the relatively significant downside that it isn't
> available to most of your potential customers.

Agreed.

Dave



Relevant Pages

  • Re: .NET
    ... I looked up Avalon and just found a .NET ... What will replace Windows Forms ... WinForms, and Win32 for that matter, should still work, but XAML will ... As Craig says though, Longhorn is not due for a couple more years yet, ...
    (borland.public.delphi.non-technical)
  • Re: Does VCL have a future?
    ... "Windows Forms/"Avalon" Integration ... Create an "Avalon" application and reuse the existing Windows Forms ... controls in the application. ... To support the first two cases, there is an "Avalon" control that can host ...
    (borland.public.delphi.non-technical)
  • Re: Unmanaged Visual C++ 2005 questions
    ... > The parts of Avalon that Longhorn relies on are not managed, ... since it's built starting with Windows 2003. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: The alternative Delphi roadmap to success
    ... The native windows API is an incredible boat of redundant and awkward functions and SWF sits right on top of it. ... Avalon is completely free from anything that could be even remotely related to Windows. ... Mono could pick up what MS found to be the bet approach. ...
    (borland.public.delphi.non-technical)
  • Re: Future of C++ and .NET/WinFX
    ... > What I would like to happen is for the GDI+ library ... No WinFX will be .NET (.NET becomes WinFX including Avalon). ... versions of Windows, new versions of .NET will keep coming out. ...
    (microsoft.public.dotnet.languages.vc)