Global command binding: the less attractive options

While I find the technique outlined in the previous post to be the preferable way to create globally available commands that can be used throughout a program’s user interface, as I mentioned I did try a number of different approaches to solve the same problem. Fact is, I think none of them are completely terrible. […]

Continue Reading...

Category: WPF

Command binding in WPF: global commands

The design of the WPF API encourages one to keep one’s code decoupled. That is, the goal is for each piece of code to do one thing,  do that one thing well, and to not carry dependencies on other pieces of code (particularly with respect to avoiding a provider being dependent on, or even aware […]

Continue Reading...

Category: WPF

How many XAML-based APIs do we really need?

I admit, this is really just a rant. Readers may want just to move on; this post isn’t going to solve any problems. Heck, it isn’t even based on full knowledge of the historical context. But I’ll share what I know, and explain my suppositions. I just have to get this off my chest: Microsoft […]

Continue Reading...

Category: op-ed

I’m back!

And, I hope, in a good way. 🙂 For a variety of reasons, I got a decent start on this blog years ago, but then got distracted by other things and was forced to set it aside. Well, I’m finding a need and opportunity to return: better time management (only slightly…I’m still not very good […]

Continue Reading...

Category: metablog

MSDN’s canonical technique for using Control.Invoke is lame

While I’m on the subject of using the Control.Invoke method, I’d like to mention a pet peeve of mine. That is, the technique that everywhere on MSDN is proposed for dealing with using that method. In particular, according to Microsoft, the preferred technique is to write one method that does two completely different things, depending on […]

Continue Reading...

Category: code, concurrency, Forms

Form-closing race condition (part 2)

In my previous post, I mentioned that it turns out that there is a way for a form to be closed without the …Closing/…Closed methods/events being called. Any code (including the synchronized flag technique I described earlier) that relies on this notification will fail under that scenario. So, what to do? Well, as I mentioned […]

Continue Reading...

Category: code, concurrency, Forms

Form-closing race condition (part 1)

Okay, I know last post I said next I would be writing about more network stuff. But I’ve been away from the blog, and in returning to it I had to revisit an issue that came up when I was doing the GUI stuff. The issue is a race condition between a thread that may […]

Continue Reading...

Category: code, concurrency, Forms

Basic network programming in .NET (part 3)

For this post, I’ll be showing network code that is about as simple as it can get. Frankly, when it comes to the i/o itself, it’s my opinion that the code never gets all that complicated. The complexities tend to be with respect to managing all the other stuff that’s hooked to the i/o code. […]

Continue Reading...

Category: basic, code, networking

DemoDotNetNetworking.cs

using System; using System.Collections.Generic; using System.Text; using System.Threading; using System.Net; using System.Net.Sockets; namespace ConsoleDemo { class Program { static string[] _krgstrTestData = { “a test line”, “another test line”, “a very long line of text that will be sent to the server, which will then echo it so that the client can receive it again”, […]

Continue Reading...

Category: basic, code, networking

Basic network programming in .NET (part 2)

Since you’re reading this, I’ll assume the previous post didn’t scare you off. [:)]  I know even that abridged version of details may seem daunting but really, with some practice writing network code, it’s all stuff that will come naturally. With that in mind, let’s get to know what the basic structure of a network […]

Continue Reading...

Category: basic, code, networking