Re: Thinking Clearly
- From: lurkio <spam@xxxxxxxxx>
- Date: Wed, 05 Jul 2006 16:33:04 +0100
Barry Kelly wrote:
This is an email I got after a posting in the Microsoft winfx.avalon
newsgroup (milcore.dll appears to be the unmanaged core of the WPF
Subject: Re: Will MIL ever be documented?
From: "Pablo Fernicola" <pablofe@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 29 Jun 2006 22:55:30 -0700
We do expose unmanaged access to the imaging functionality in the MIL,
but have not plans in place for exposing the rest. MS applications
don't have access to it either.
I quote from the following
interview with a couple of Redmond's .NET cognoscenti about
WPF interoperability :
Specifically, the following quotes :
"SS: If the Office team wanted to enhance Excel, which is
mainly a C++/Win32 app, with WPF, what would that take?
"MH: Yes, you can do that. <edit> If developers have pure
C++, unmanaged applications, and they want to leverage
WPF, they have an interoperability model as well. It's
using a base technology in WPF, which consists of two
classes known as HWndSource, and HWndHost. These are the
things that we build on top of for Windows Forms interop.
Those allow us to build the hosting controls we need for
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).
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...
I saw a good quote that sums things up on this was on Nick
Kramer's WPF blog :
"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. As we’ve seen, we
can put hwnds inside Avalon programs, and we can put Avalon
code inside of hwnds, and even mixtures of those two, to create
incredibly powerful programs that leverage your existing code.
HwndSource, HwndHost, and IKeyboardInputSink make all of this
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 ?
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
WPF, 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 ;-)
- Re: Thinking Clearly
- From: Barry Kelly
- Re: Thinking Clearly
- Prev by Date: Re: Thinking Clearly
- Next by Date: Re: Compare D7 to BDS2006
- Previous by thread: Re: Thinking Clearly
- Next by thread: Re: Thinking Clearly