WPF

SoCal .NET User Group Presentation

Bill Sheldon — Mon, 16 Apr 2007 14:16:00 GMT

One of the items I learned when I was requested to speak to the LA C# User Group, was that they were essentially affiliated with the SoCal .NET User Group (http://www.socaldotnet.org/). Apparently the same speaker coordinator works both groups and they meet one after the other. Thus I was also requested to speak to the Orange Country group on the following night April 4th. Since some people attend both meetings I agreed to adjust my topic slightly.

In this cas I adjust my presentation to focus on WPF and Interop. The focus of course being the ability to take applications built with Windows Forms 2.0 and have the user interface work with new components being built with WPF. The presentation again introduces .NET 3.0 and WPF but doesn't include much of the XAML focus from the previous night's presentation. It instead spends more time looking at Crossbow.

Crossbow is the code name which Microsoft used when it was building the Interop libraries to allow the new WPF windows graphical libraries to work alongside the existing Windows.Forms libraries. The key message was: if you are using the Interop controls, the WindowsFormHost and ElementHost controls should ALWAYS be used to host User Controls. Yes they CAN host individual controls such as a TextBox or DataGridView, but if you need to Interop you have business logic in place and you should always encapsulate the controls in a User Control prior to having those controls placed in one of the Interop controls.

In addition I spoke about how this Interop direction is really a lesson learned from the initial Visual Basic 6.0 to Visual Basic .NET migration based path which Microsoft provided. Microsoft learned that trying to take an entire real world application and migrate it's entire code base to a new implementation language was a cost prohibitive scenario. It tended to be difficult for engineers to imagine and they constantly wanted to start with the backend components which made it that much more complex.

Instead with WPF Microsoft has pursued an Interop strategy. There won't be any tools to migrate your Windows Forms based application to a WPF UI. After all many components such as the DataGridView control just don't have a single equivalent under WPF. The key being that when you went to move the implementation from Windows Forms to WPF you'll want to change the implementation completely.

As I also note, not only did Microsoft learn this lesson when planning WPF, the Visual Basic Team has been leading the way. They have released a set of tools which will allow you to create new .NET Forms and have these forms compile into classic VB6.0 applications. In this way you can begin to extend your existing VB 6.0 applications with new .NET based capabilities without needing to spend 6+ months migrating your code base. The new VB Interop tools although not the focus of this presentation are every bit as exciting as the WPF Interop tools. You can get the latest version of the VB Power Tools from MSDN or from the Visual Basic Team blog at: http://blogs.msdn.com/vbteam/archive/2006/11/02/interop-roadmap-usercontrols-mdi-and-data.aspx

Here is a copy of my slides from the SoCal .NET User Group Presentation:

WindowsInterop.zip (992.07 KB)

LA C# User Group Presentation

Bill Sheldon — Mon, 16 Apr 2007 13:47:00 GMT

I know most speakers like to announce where they'll be speaking in advance (helps drive attendance...) but a couple weeks ago I was contacted by the speaker coordinator for this group and asked if I could speak in a couple days. In talking with them they said they hadn't really gotten much info yet on WPF and XAML so I agreed to do a brief presentation on these topics to this group.

So on April 3rd, I gave the LA C# User Group (http://www.lacsharp.org/) a presentation discussing XAML and WPF. The focus of the presentation was that you shouldn't think of XAML as being an adjunct or WPF. The two technologies are separate and have different goals. WPF is a set of class libraries which are part of the larger .NET 3.0 Framework. XAML is a declarative language which can be used to create .NET applications. The point being that XAML is a full fledged .NET application language like C#... (VB of course is still easier to read...)

Attached to this post is a copy of the slides that I presented to this user group meeting.

WPFIntro.zip (1.09 MB)

The C-ME application and some cool links...

Bill Sheldon — Wed, 21 Feb 2007 10:10:00 GMT

Tim Sneath recently added a post regarding the InterKnowlogy WPF application C-ME. This application was originally developed for The Scripps Research Instititute and provides a Collaborative Modeling Environment. What we mean by that this that you can model an image and as Tim's blog states, this might be a molecular structure or an engineering structure. Of course model viewers exist everywhere and while it's a great graphical tool the goal of C-ME was to allow you to place annotations (from Notes and Word Documents through HTML links) directly into the context of the 3-D image. Thus if you want to comment on some aspect of the image your comment stays in context. This means instead of trying to describe the element associated with your comment you can literally attach the comment in 3-D space and the next person to review it can literally see what the comment is related to within the image.

Tim Sneath has more information, some comments from other people involved in the project, and links to exclusive downloads related to the application at his blog:

http://blogs.msdn.com/tims/archive/2007/02/14/great-wpf-applications-9-scripps-institute-cancer-research.aspx

Working with Javascript sucks - What's the Alternative?

Bill Sheldon — Sat, 09 Dec 2006 13:14:00 GMT

It's funny get into a technical discussion with anyone who does alot of web development. Opinions are rife and vary across the board. You can create conflict on any number of topics. "Hey I like smart client/windows desktop applications better then web applications" or "I like C# over VB for my projects", whatever. The fact is the type of people that spend time sitting in front of computer screen constantly making minor adjustments in a source file and reviewing the results to see if the results are exactly as desired tends to have more then a few strong opinions.

Now let me add a disclaimer here: this post is only refering to web development - not server scripting.

In most cases just like the any other opinion, everyone has their own, and the live and let live approach is the most productive. Yet I've tested the above statment - Working with Javascript sucks - out on dozens if not hundreds of developers and I've never gotten anyone with a truly different opinion. Sure now and then someone will say it's not that bad - but consistently even those who proceed to tout its benefits on the client are still at some level of the opinion that it sucks as a developer tool for web development.

Which brings us to the question of: What's the alternative? For a while we could simply refer to Javascript as a way to make screens a bit more interactive and for clueless developers to place data validation code so hackers could completely bypass it. The useless nature of Javascript for browser based data validation could be a complete discussion. Of course the discussions been done repeatedly yet even newly developed systems that shoot themselves in the foot are being released - proving there will be a subset of developers who will never understand. The point being that the only real value of Javascript was as a language to make a browser react, and even then doing more then shuffling data around was difficult at best.

Then along came Ajax. With the introduction of Ajax (I last wrote of Ajax a little over a year ago: http://blogs.interknowlogy.com/billsheldon/archive/2005/09/09/415.aspx) it has become apparent that Javascript isn't going away anytime soon (like so many technologies which have outlived their true value: http://en.wikipedia.org/wiki/COBOL). The fact is that Ajax took what people had been hand coding in Javascript for page interactivity and packaged it. Of course toolsets like the Microsoft ASP.NET for AJAX suite have been slow in truly making it to market, but the market has continued to grow in spite of this. The only disadvantage of course is that while this will provide you with a set of specialized controls from the ASP.NET standard.

Of course the challenge right now is that to leverage AJAX you still need some, you guessed it, basic Javascript that you have to customize. After all AJAX has Javascript right there in the acronym. Meanwhile the underlying issues with Javascript and the fact that it has a lousy development environment remain. Thus when you talk to people working with Microsoft's ASP.NET AJAX, it's all about the Javascript (http://blogs.interknowlogy.com/joelrumerman/archive/2006/09/22/5126.aspx for a good example...)

But again - Is there an alternative?

Well little by little two alternatives are emerging. One is still based on Javascript but in this case you never touch the Javascript. That is where thrid party vendors have wrappered the complex Javascript for you. Telerik provides such a soluction at: http://www.telerik.com/products/ajax/r.a.d.ajax.aspx. (The Telerik suite with it's support for everything from native ASP.NET to Dot Net Nuke and Sharepoint is rather impressive.) It may not be as efficient in what it sends to the server in a given round trip as say custom coded controls which are handling the AJAX communications, but then again its way easier to implement and get the same behavior. In a cost - benefit analysis you'll probably find this solution wins out the majority of the time, and since it's based on AJAX you can even have developers like those here at InterKnowlogy customize those pages where you need a custom solution. More important just like the Microsoft ASP.NET AJAX solution it approaches the market with compatibility across multiple vendor's products as a focus. This solution favors compatibility over what we'll call capability - and that is a very marketable feature.

The other alternative is, as with most technology, coming from an alternative direction. It's called WPF.

Nothing against the Ajax/Telerik solution, but for those of you not paying attention even as Microsoft provides basic support for the AJAX model that they invented so long ago they have also seen a better way. The Windows Presentation Foundation (WPF) is an XML based user interface definition. Now as we all know XML already runs in browsers so we have the basics of what you might think of as a next generation HTML. Go a step beyond the current namespaces we use for custom controls in ASP.NET. Go beyond well formatted HTML. Take the next step and say - what if the declaration of a Textbox was just that... a declaration that both the Smart Client Application and the browser understood. Now go a step further - suppose the browser wasn't just a rendering engine but instead allowed for a recogniztion of the fact that a change in that drop down was actually designed to trigger an Ajax style update from the client. One that didn't require a full round trip of the entire user interface (postback) to the client nor any Javascript - not even generated script. Admitedly it wouldn't be compatible with all of the existing browsers on the market right away - but that's only one form of compatibility and in this case perhaps not the driving one...

WPF addresses a different type of compatibility. Compatibility between desktop based and browser based applications. The ability to design a user interface which works well and looks the same in both environments without needing to completly re-implement the interface. For an "enterprise" or "corporate" developer this is actually a more important type of compatibility. Within an organization it's possible to dictate that everyone must use version 8 of browser X or to produce a smart client application... these developers are constantly being challenged to choose between smart client and browser alternatives (even if they do both it's still extra work like double data entry).

It's this arena of compatibility which WPF targets in the short term. Of course as more and more companies move to WPF for it's reuse across desktop and web more and more corporate users will demand third party browsers support the WPF model. These browsers will respond because they want people to be able to use their product in their work environment. Over time what will start as a tool which is focused as much on Smart Client applications has the potential to again revolutionize the market. Note I'm not saying that AJAX wont' survive for decades to come or that it isn't viable - I'm just noting a future alternative, one which I think web developers will be a little late in coming to the party... by the way note all the AJAX and WPF presentations on the blogs.interknowlogy site...

Leveraging Glass in your WPF App

Bill Sheldon — Wed, 19 Apr 2006 16:50:00 GMT

Tim Sneath added a cool post showing you how to add the Glass UI that is part of Arrow to you winform based application. Very cool effect for those looking to do a slick WPF application (not that IK is doing any of those :-) oh yeah - TSRI... here's the link:

http://blogs.msdn.com/tims/archive/2006/04/18/578637.aspx