XAML is really just an XML-based object persistence format. It's not directly tied to the display technology that it's mostly used for, which is "WPF" or "Windows Presentation Foundation". It's really WPF that should be compared to Windows Forms -- you can use WPF without writing a single line of XAML (or having the designer write it on your behalf).
If you're used to using the Win32 API or a thin wrapper over it like MFC, then Windows Forms is a lot closer to what you know already. That's because Windows Forms itself is a (somewhat thicker) wrapper over the same Win32 API. By contrast, WPF is a UI framework that's been redesigned from the ground up. Individual elements on a WPF window aren't represented by an window handle; there's only one HWND at the top which effectively provides a blank canvas for WPF to draw on. There are probably hundreds of thousands of applications built on USER32.DLL and/or Windows Forms. The odds that Microsoft abandons all of these applications are pretty low -- it is the applications, after all, that make the platform what it is. And although WPF is in many respects a much better-to-develop-for architecture than Windows Forms, it also isn't perhaps quite as mature -- and there are a few things that are still more easily done using Windows Forms than WPF, particularly in a line-of-business-style application. With respect to IronPython, we don't have much to say about the platform as a whole. You can execute just about any .NET code from within IronPython -- whether that's Windows Forms, WPF, WCF, WF, Managed DirectX or the CLR-based technologies that are just being invented now. So as long as Windows Forms exists, you'll be able to use it from IronPython. If your specific concern is related solely to Harry's comment about the Visual Studio integration work being more difficult for the Windows Forms designer than for the WPF designer, then I think you've read a little too much into what he said. Our intent is to support the Windows Forms designer. It may be that -- due to its quirks -- we're not able to do so in the early previews of the work, but I don't think that any of us would consider the integration done if it was WPF-only. Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Disclaimer: I am a Microsoft employee, but I have absolutely no inside knowledge on any of the topics I've written on here other than those related directly to IronPython. On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe <[EMAIL PROTECTED]> wrote: > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar > to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. > WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > > Max Yaffe > Gamry Instruments, Inc. > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com