Jay Taylor's Blog

Use Windows Live Writer to Post to Your WindowsClient.Net Blog

Did you know you can use Windows Live Writer to post to your WindowsClient.Net Blog?

You can!

Step 1. Download and install Windows Live Writer and follow these steps.

Step 2. Select Add A Weblog Account... from the Weblog menu in Windows Live Writer. (If this is your first time using Windows Live Writer, the application will auto-prompt you to add a new weblog).

Step 3. Choose Another weblog service and click Next >.

Step 4. Complete the Weblog Homepage and Login screen by typing http://blogs.windowsclient.net/[yourblog] into the Weblog Homepage URL field and entering your username and password in their respective fields. Click Next >.

Step 5. Windows Live Writer will not auto-detect the WindowsClient.net blog provider, but the next screen will give you the option to configure it manually.

Step 6. Select Community Server from the drop-down menu and enter this URL into the Remote Posting URL field: http://blogs.windowsclient.net/blogs/metablog.ashx

Click Next >.

Step 7. You can edit your Weblog Name and edit your settings on this screen, but that's optional. Click Finish.

Step 8. That's it! You're ready to edit your WindowsClient.net blog using Windows Live Writer.

Windows Presentation Foundation: Getting The Big Picture

Pete Faraday and Brad Becker posted an article to WindowsClient.net this week titled Deciding When to Adopt the Windows Presentation Foundation.

One of the reasons I love WindowsClient development is because I can go from an abstract idea to a concrete product fast.

This has a big downside, however, because the faster you go, the more mistakes you make, and one of the biggest mistakes is making a snap decision about a project's fundamentals that causes insurmountable problems down the road. For example, if you choose the wrong UI platform, can find yourself stuck at 90% done because your platform doesn't have base classes to deal with complex text or video or 3D. And when this forces you to backtrack, it can be painful and costly. The time, cost, and effort required to resolve the issue almost always exceeds the project's deadline and budget.

I remember a recent case when a client wanted to print a PDF receipt from an ASP.NET form submission.

I said, stupidly, "That's not a problem at all; we can do that easily."

Then I realized that all of the popular PDF controls cost about 20 times more than the client was willing to pay.

"Houston, we have a problem!"

Long story short: I found an free, but undocumented control that I was able to hack into submission, but it took me 5 times longer than I anticipated.

This isn't the best example, as the client introduced this post-analysis; but, if you're like me, you've experienced the pain of backtracking, re-coding, deleting hours of work, porting to a different platform, testing, and coding some more just to get back to that 80%.

The question I always ask myself is the same question you probably ask yourself, "Why didn't I check if my platform could do what I needed it to do BEFORE I started coding?"

Pete Faraday and Brad Becker's article, Deciding When to Adopt the Windows Presentation Foundation, helps you decide when to adopt WPF. The table three-quarters of the way down is especially helpful in deciding which UI platform to use, but it also changes the question:

"When is WPF, the richest UI platform Microsoft has ever released, not the right choice?"

The answer is in the article...