HomeBlogLearnProductsEventsServicesAbout UsFAQ
Mike Yeager's Blog

Thursday, May 31, 2007
Surface, SilverLight, Xiine, Orcas, PopFly

There's a lot of new stuff out there and it's pretty fun to take in all in. Some of it's awesome (Surface and Xiine), some of it's crap (Silverlight), some of it's just an incremental improvement (Orcas & PopFly). Anyway, here are my opinions based on my interactions with these technologies. Remember, you get what you pay for...

If you haven't seen Microsoft's new UI paradigm, check out Surface. I saw some of this in a Bill Gate's keynote a few months ago and wondered when it would find it's way out of the R&D labs. It's hardware and software and for certain types of things, it's incredible (though I wouldn't want to write a book with it). I want one! I wasn't all that excited when tablet PCs came out. This is a whole new ballgame!

Xiine is a sweet digital media reader that manages subscriptions, downloads the content and lets you view it and interact with it any time or place you want. It's kind of like iTunes for magazines, books, tutorials, etc... I recently upgraded my video driver to take advantage of WPF and the graphics in this thing are cool. So far, I'm finding that it comes in really handy when I travel because I've always got new reading material in my laptop. I can even cut and paste code snippets right out of my CoDe magazine subscription.

OK, I was a little harsh on SilverLight - it is a good concept. I think of it as Microsoft taking Flash to the next level. In its initial release however, it relies on the developer knowing javascript and the foundation seems ... shall we say... a bit shaky. Playing with it was one of the most painful experiences I've had with new technologies in a while. In its latest iteration, it allows us to use C# or VB and get away from the quirks and drawbacks of scripting. That does make it a lot more interesting! Still, all of the Silverlight stuff you do will be hosted on existing web site technology, so it's really just giving us more exciting things we can do with a web page - soon.

Orcas, the next version of Visual Studio includes a lot of cool new stuff, but some of the wind is out of the sails because we found out about a lot of the new stuff a long time ago with the release of the 3.0 framework and all the WFs (WPF, WCF, WF). Though we'll finally be getting the developer tools to create things that use these technologies easily, the technologies are old news by now. The new things in Orcas are really all about the compiler features. Linq is the one thing that I've played with in early releases that I'm REALLY excited about. It hasn't been out in the general public nearly to the extent of the other features, nor have the new type inference features that make Linq really exciting. I'm really looking forward to Orcas - but it's yesterday's news.

WCF was a bit of a hassle to get installed, but it seems to work quite well. Even though there is some new terminology to learn, the concepts are pretty straightforward. After that first hello world app, you've got the hang of it. There are a ton of options and issues, but compared to remoting and the W* implementations, shis is way more powerful and easier to work with.

I've worked in some capacilty with WPF and XAML for some time now and am pretty familiar with it. It is da bomb for UI work. The designers are getting to the point where you can use them. Orcas will support it. Nuff said.

I've seen Workflow Foundation (WF), but haven't tried it out myself because I haven't had a use for it lately. It seems a bit esoteric and I may hold off for a while until the tools get better. It's just one of those things where the tools don't give you much visibility into what's going on yet. I'm going to wait on this one.

This morning, I signed up for the Alpha of PopFly, a SilverLight based social web site. It's kind of a YouTube site that give you tools to create your web site right inside your browser. You can also create "Mashups" where you smash together services available on the web and create some new useful or interesting combination. I saw one this morning where they smashed a list of upcoming music events together with Live Earth to give you a map of the country showing all of the events and giving you event information. Pretty cool. There are hundreds (and soon millions, I'm sure) of combinations. Finally, there is the community where you can share you stuff and see what others have shared. So far, I like it because it brings that ability to use some of the information floating around on the web in an intelligent way, so the content can be of higher quality and be more useful.

It's been a lot of fun. I've gotten to test drive some really cool stuff and I like where it's going in general. Some of the trials I've had have just been getting past the marketing babble and finding out what these things really are and how I might use them. That's always been a challenge with M$. Let me know what you've seen recently that's cool...


Posted @ 10:35 AM by Yeager, Mike E. (myeager@eps-software.com) - Comments (24)

Monday, May 21, 2007
Static Analysis and Team System

If you've programmed in .Net, you've at least heard of FxCop, Microsoft's free static analysis tool. It's a VERY cool tool that looks at the IL in your .EXEs and .DLLs and does an automated code review for you. Microsoft even provides a whole set of default rules to look for everything from naming conventions to pointing variables that are declared and never used. How can you beat that for free?

I'll never forget the first time I ran FxCop against a very small project that I had just finished. I thought that I was a pretty good .Net programmer at that point. How bad could it be, right? 287 violations. I don't think I had 287 lines of code in the whole project! Ouch. It took days to get over the bruises on my ego, but with the Help of Claudio Lassala, a C# MVP here at EPS I went over each violation, figured out what each one meant and how to correct it. In many cases, just figuring out what the violations meant was hard enough! Come on, who instinctively knows how to reduce your code's "cyclomatic complexity"? In FxCop, there is usually a link you can click right in the violation itself to get a full explanation of what it is and how to correct it. Naturally, most of it sounded pretty far out there to me and not really applicable to my app, but Claudio was insestent that the code would be of much better quality if I fixed EVERY SINGLE violation. That first time, it took me a couple of days to get them all cleaned up, but in the end I DID have better quality code and after using it on every project I got used to coding to a higher standard so that now, it doesn't feel like any additional effort. Instead of typing:

public string HelloWorld(string Recipient)


        return "Hello " + WhichPlanet;


I instinctively type:


/// Returns a string saying "Hello" to someone.

/// </summary>

/// <param name="recipientOfHello">The recipient of hello.</param>

/// <returns>string</returns>

public string HelloWorld(string recipientOfHello)


        // Example of resource in english: "Hello {0}";
string.Format(System.Globalization.CultureInfo.InvariantCulture, Properties.Resources.HelloWorldText, recipientOfHello);


I've gotten better performance, it's clearer to the majority of other .Net programmers, I've added intellisense for programmers who will use my code down the road, I can post versions in other languages easily, etc, etc, etc. Once I added tools like CodeRush to my dev environment, I was able to automate most of the typing and since then, I've never looked back.

It was just about the time I was feeling pretty good about myself again that Claudio introduced me to some additional static analysis rules that he had created for our internal use at EPS. FxCop allows you to create your own rules and add them to the default rules. Only 46 violations this time <s>. At least now I KNOW thta my code meets all of our coding standards when I check it in. I LIKE FxCop. It's helped me clean up my code considerably and found things that I would probably never have discovered on my own. Things were pretty good...

Then along came Team System. I think Team System is AWESOME, that every programmer should use it whether they work in a large team or not and that Microsoft should lower the barriers they've created with the ridiculous pricing and licensing scheme they've created for it. (Most people start to sense that there's something wrong when you have to produce white papers to explain a licensing model). For a V1.0 product, they've done a great job and by the time V2 comes along I think it will be hard to live without. The worst piece of the puzzle so far seems to be in the area of static analysis. They've baked in the heart of FxCop - in fact the FxCop name still appears in various places, but I get the feeling that they only had a weekend to do it and never got to finish...

Many of the nice things about FxCop didn't make it into the new integration. The links to explanations of violations for example aren't in the TS version. Speed is another issue. It got so bad that we had to step back and come up with a whole new process so that we could avoid running static analysis during most of our builds. The engine also seems somewhat ... ah ... "quirky", occasionally locking up Visual Studio and requiring a re-start. The list goes on, but since static analysis is SO valuable to us, we developed some work-arounds I wanted to share:

1) In FxCop, you could add acronyms such as “EPS” to a custom dictionary for each project so that you didn’t get naming errors when doing static analysis. In Team System, you can still do that, but the settings are global – for every project. Modify (or create) your CustomDictionary.xml file for Visual Studio. The default path is C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\

<?xml version="1.0" encoding="utf-8" ?>

2) Use "Configuration Manager" to create a build configuration to run static analysis. Everyone knows that every VS project has a "Debug" and "Release" configuration. The Configuration Manager tool, lets you add other configurations. One thing you can do with configurations is target the build to a specific processor type (which is handy for those of you with 64 bit machines), but the real value of build configurations is that you can change all of those project properties which, for Team System includes things like whether or not to run static analysis. Because we use a lot of test driven processes, we build often, so our default "debug" configuration is set up to be as fast as possible - no static analysis, no xml comments, etc. We then create a new build configuration for each project in the solution, copying the "debug" settings and then we modify them to produce a very thorough build. We can even set up a policy in Team System to require that we build with this configuration before allowing code to be checked in. Most of the day we code, build and test with the fast "debug" configuration. Then, when we're getting ready to check code in, we switch to the new configuration and build everything. We clean up the static analysis violations, ensure that our tests pass and THEN check in our code.

Catch you later!

Posted @ 10:41 AM by Yeager, Mike E. (myeager@eps-software.com) - Comments (32)

Friday, May 04, 2007
The Visual Inheritance Question

I've probably converted a couple thousand forms from Visual FoxPro to .Net. In fairness, I was the primary developer on a tool that did the conversions for me. There are some notable differences in the two environments that I wanted to highlight. I'm just finishing up on a couple of deadlines that have kept me away from my blog, but I want to write this stuff down while it's still fresh.

When I lived mainly in the FoxPro world we made the most of visual inheritance. We subclassed the base form, button, textbox, checkbox ... everything. That way, when we wanted to change the look and feel or behavior of these controls or add some functionality, we could do it in one place and the changes got inherited in every place we used them. Then we created some composite controls. Created a subclass of the main for "edit" forms, for "search" forms, for report forms. We dropped on "OK" and "Cancel" buttons, a control to do resizing, changed the background color, etc. Next, we added another whole layer of subclassing everything so that changes could easily be made to one project and not another. By the time we created a form that we’d actually use in an app, it was probably about 4 layers deep in visual inheritance. Now, when we needed a new edit form, we simply subclassed the one that had almost everything on it, filled in the blanks, moved things around, adjusted the colors, the size, the title bar, fonts, behavior, etc for the specific needs of this one form and we were done. Visual subclassing was very, very powerful in VFP.

.Net doesn't like visual subclassing nearly so much. Create a subclass a form based on another form and you find out pretty quickly that things are quite different than in the VFP scenario I just described. Probably the first thing you'll want to do is resize the form and change the caption on the title bar... but for some reason -- you can't! What good is subclassing one form from another if you can't even change the text on the title bar! Turns out, .Net has a really good reason for this behavior (called "encapsulation"), but it sure does throw a wrench in the works if you want to do visual inheritance. The well-known work-around is to go into your base form and change the modifier from the default private to public. This works great for the designer which will now let you resize the subclassed form. The best practice however is to not do that. Instead, you should create an interface for the properties and methods on your base class that you want subclasses to have access to and create public methods (and/or properties) on your base class that implement the interface. Perhaps you'll create an interface including SetFormTitle() and SetFormSize() methods. Now sub-classes can call these methods to adjust these settings. This leaves a lot of people (including me) scratching their heads. Forget using the form designer - it won't work with your interface. At this point, you're limited to modifying the base class in a subclass by writing code. Does that sound right?

Of course, VFP could work this way too. If you've ever created a "control" class, dropped a few textboxes or buttons on it and used it on a form, you've seen this in action. Unlike using a "container" class, once you drop your new control onto a form, you can't right-click, select "edit" and drill into the textboxes and buttons. Most of the VFP developers I know did this about once, learned their lesson and never did it again. Why limit yourself?

Now, what was that "encapsulation" thing again? One of those key pieces of object-oriented programming. It means that objects should only interact with one-another through well-defined interfaces and that one object shouldn't know the internals of the other. To put it another way, you should be able to see the other object, but not see inside the other object. That concept sounded sooooo awesome the first time I learned about it. Practically the death-knell for spaghetti code! As long as my objects stayed backward compatible with earlier interfaces, I could add functionality, completely change the internals of my object and not worry about breaking any code that used it. As long as I maintained my SetFormTitle() and SetFormSize() calls with the same parameters and return types, I was not going to break any code that used my object.

So if I was to drop my container onto a form and drill into those text boxes in the designer. Maybe just to stretch one of those text boxes to make it just a little bit longer? Do I now know too much? Do I now know about the internals of my object? Haven't I just busted the rules? .Net emphatically says, "Yes". What CAN we do to make everyone happy?

You CAN subclass the .Net base classes in code. (Something along the lines of public class MyButton : System.Windows.Forms.Button in C#) You can then compile this class and use it in your applications. You can even get it into the toolbox, and with a little extra work, set a meaningful icon for it (it won't show up looking like a button in the toolbox by default) and make it behave just a little more like a button. With some more work, you can get it to show up looking like a button at design time. Now, whether you just include the source code for MyButton in your project or compile it into a dll and set a reference in your project, you can start using MyButtons, but unless you are a control designer, I think this is a little too much effort. Besides, this is “inheritance”, not “visual inheritance”. This is an exercise in creating written code.

Is there actually a difference between an object meant to implement logic and one meant to be visual? I think so. And I think we should draw a line between them and allow for more visual inheritance. I would however like to see a big difference from the way FoxPro implemented it. I’d rather not make it so easy to let controls see UP the containership chain. In other words, the textbox shouldn’t have easy access to the form it’s on, and especially not to the other textboxes and buttons. I’ve seen code like that and it truly IS ugly. If controls need to work with each other, that should be done in one place, through the containing object which does have knowledge of its own internals. I think seeing DOWN the chain should be a lot less restrictive. Yes, I think you should be able to change the size of a subclass of a form. This would allow for a much better story in the designers so that we could visually change that title bar and stretch that textbox and create a much more productive environment.

Are there ramifications? Yes. Let’s say in VFP you had a project with 200 forms derived from a base class form with a label on it and one day you decide you don’t need the label anymore. You open the base class and delete the label, save your change and rebuild your app. Presto, the label is gone. Even if you changed the position and text of that label on every one of your 200 forms, you won’t see an error. VFP is happy to ignore all of those property settings in your forms for the label that no longer exists. .Net will scream at you however and I think that’s OK. You’ll get a couple hundred compile time errors and will have to double click on each one and remove the offending settings from each form. I’m OK with that. It will produce tighter, higher quality code.

This is NOT an issue with the CLR. These restrictions come from 2 sources. 1) all visual classes contained in other classes are marked private by default. 2) the designers don’t support “drilling in”. You can change the default modifier of contained controls from private to public. You can change properties of contained controls in code and even on the property sheet after you do this. The designers however will not let you make any of those changes visually and will very likely throw away whatever changes you made on the property sheet when it re-writes the code in the generated .designer file. Your changes will have to be made by hand in user code.

Would changing the way this works break the rule of encapsulation? I’m not so sure. Visual controls have a well-defined interface and exposing a well-defined interface (the top, left, height, text, backcolor or other members) in a subclass of a visual container isn’t as terribly horrible as exposing the internal workings of something that does logic. There is already a line in the sand between visual and non-visual objects. I think the self-imposed limitations are a question of philosophical purity vs. productivity. I understand the potential for misuse, but I fall on the side of productivity on this one.


Posted @ 10:02 AM by Yeager, Mike E. (myeager@eps-software.com) - Comments (39)

Blog List
VFPConversion Blog
Markus Egger's Blog
Ken Levy's Blog
Claudio Lassala's Blog
Blog Archive
March, 2008 (1)
February, 2008 (1)
October, 2007 (1)
September, 2007 (2)
July, 2007 (1)
May, 2007 (3)
March, 2007 (3)
January, 2007 (2)
December, 2006 (1)
October, 2006 (2)
September, 2006 (2)
August, 2006 (6)
July, 2006 (3)
June, 2006 (2)
May, 2006 (4)