Re: Thinking Clearly
- From: Barry Kelly <barry.j.kelly@xxxxxxxxx>
- Date: Wed, 05 Jul 2006 18:02:03 +0100
lurkio <spam@xxxxxxxxx> wrote:
This refers to hosting the CLR runtime inside your unmanaged application
- HwndSource and HwndHost are both .NET WPF classes.
Yeah, I fully appreciated that point but I mentioned those APIs
because such features suggest that you can utilise them if you
want access to WPF as your GUI front-end without the need to
re-write your entire Win32 back-end for another platform - which,
as the Dr Dobbs article hints at, is why Microsoft might well
be using that approach themselves in places (i.e. Office).
Yes. It would also make sense given the amount of effort they've put
into C++/CLI, probably to enable this scenario - putting their
second-biggest (? I think) cash-cow on the new UI.
Of course, I could (and probably should) have mentioned the
possibilities of using WPF/e in conjunction with Win32/64 code
as that doesn't require the .NET run-time at all...
we on the same page? :)
"You can build some wonderful programs using Avalon, and there’s
no need to the throwaway you’re existing investment in Win32
technologies in order to leverage Avalon.[...]
It's a kind of "checkbox feature", a "yes-sir" feature for marketing.
The WPF engineer that I quoted above seemed /a shade/ more enthusiastic
than /that/ about it...though if indeed the marketeers were the driving
force behind this, do you have any speculation as to why they might be
so keen on these features ?
In so far as it's an "unmanaged" interop, I think so, yes. For example,
the story for hosting ActiveX controls is to import as a WinForms
control, and then host the WinForms control in HwndHost, and then put
your host in your XAML - it's like a Russian doll, and managed code is
all over it.
(They always do sound enthusiastic :)
The point is that either you're going to go to the hassle of hosting the
CLR (and thus handle the stitching together of your Win32/64 unmanaged
code with the managed UI yourself), or you're going to compile in
Delphi.NET and get most of it for "free".
Hmm, "free"...if you are prepared to wait until Delphi.NET actually supports
Technically, you don't need to wait for anything for "support", in the
sense of creating applications built in Delphi with a WPF UI. Good
tooling and design-time support is a different thing, though.
if by the time you decide to make the switch you are lucky enough that
there are available VCL.NET versions for all of your third-party VCL controls,
and if you are subsequently prepared to move to a framework stuck in a state
of perpetual feature lag behind the current version of the .NET...
Wise move on your part sticking the word "free" in quotes ;-)
I can't comment on how WPF could possibly integrate with the UI side of
VCL.NET. I can't really see it myself, knowing what I do of WPF - and
that's fairly little - presentations and a couple of hours of browsing.
It would have to be a whole new approach, and what would be the point?
One would have to see the deficiencies of WPF to design something really
better, I think. I really can't say anything meaningful - too little