Run time is design time for AGT [15]

by Administrator 30. October 2008 19:40

The AGT (Argentum Tela) series of articles is an effort to do two things.  Usually an idea is presented only in its finished form.  The first goal is to do some Reality Blogging, to show an idea evolve over time without pulling any punches.  The second goal, and the example vehicle for the evolution aspect, is an extensible Design Surface for Silverlight similar to what we have in Visual Studio 2008.   This type of application has all sorts of interesting uses.  My example is a Home Theater layout tool.  Read the entire saga:

Choosing an Approach to Editing Properties

One of the last top level pieces to begin fleshing out is Property Editing.  I don’t want to see “Red Couch” in the toolbox anymore: I want to see “Couch” and to change its color at runtime by editing his properties.  Having had a lot of experience writing things like this so as to fit neatly within the framework Microsoft gives us, I felt very familiar with the benefits and drawbacks of these approaches.  I had to ask myself some questions:

1.       Is the PropertyGrid really the best way to go about changing attributes of objects on a design surface?

2.       Is a Visual Studio style grid the best route?  Maybe a smaller gird that appears right next to a Component (ala Visio) is better?  Maybe there should be more interaction with the Component itself?

3.       How important is it to support the editing of a Property for many Components at once?

4.       How important is Undo?  Redo?

5.       What is the best contract between IDesignableControl and “the design time environment” for determining which properties are editable and how they should be edited?

When writing custom controls for the Visual Studio designer, it always bothered me that the Contract between my Controls and the Designer Time Environment was simply some attributes on public properties.  Now that I’m in a position to change it for my own world, I’m having trouble thinking of something better.  My ideas on what is the most “correct” in terms of Object- and Component- oriented semantics is not the only thing at play here.  As a component creator, what do I want my software development experience to like?  Is placing eight attributes on a property the easiest and most sensible way?  If I diverge from what’s present in the Visual Studio design time environment, how much extra work am I creating?

What design-time support is present in Silverlight anyway?

Designer Support native to Silverlight

What namespaces, classes, interfaces, and attributes we are accustomed to from “full framework” design time support have made it into Silverlight?


This namespace only contains things related to a Silverlight plug-in control on ASPX pages.  There’s nothing useful for us here.


Many of the familiar friends are here:

·         CategoryAttribute – Place this on a property indicating what category the property belongs to in a categorized PropertyGrid.

·         DefaultValueAttribute – specify the default value for a property

·         DescriptionAttribute- a Description for a property or event

·         DesignerProperties class.  This one is interesting.  At the time I started this article, RTW was not quite out and the documentation on MSDN didn’t really say anything about what this actually did.  The description now says “The DesignerProperties class provides attached properties that can be used to query the state of a control when it is running in a designer. Designer tools will set values for properties on objects that are running in the designer.” Ultimately, though, this is an attached property for “IsInDesignMode”, which I don’t know if I’ll need or not.

·         EditorBrowsableAttribute – In what situations should this property be shown by designers or intellisense

·         TypeConverter – TypeConverter is missing some things from the full framework. The MSDN documentation still says it supports “standard values” but those methods (to return a standard values collection) are missing in Silverlight.

·         TypeConverterAttribute –present and accounted for!

Missing in action:

·         System.ComponentModel.TypeDescriptor – In the full framework, TypeDescriptor is extremely important to the design-time environment.  TypeDescriptor is used to augment Reflection to specify what attributes a Component has. 

o   TypeDescriptor tells us what kind of Editor is used to modify an instance of a Component

o   TypeDescriptor tells us what kind of Designer a particular component uses

o   TypeDescriptor is used to create design-time instances of a type

·         TypeDescriptor is extensible via IExtenderProvider, ITypeDescriptorFilterService, ICustomTypeDescriptor, all missing.

·         System.ComponentModel.Editor

·         System.Drawing.UITypeEditor

In some cases I’ve already made design decisions that negate the need for some of these missing things.  Other’s I’ll have to introduce or replace.

Design Goals

Property editing is complex.  Now that I see the lay of the land, I can state some design goals and some approaches to achieving them.

1.       The items on the design surface (IDesignableControl) need to be able to be inspected for a list of Properties that are displayable and editable.  It should be painless for Control authors to do this.

2.       When a property is found to be displayable, we must be able to determine what type of visual Control should be used to display the property value.

3.       When a property is found to be editable, we must be able to determine:

a.       The type of the property

b.      The category of the property

c.       What type of visual Control should be used to edit the property value

4.       We should be able to display all of this in a PropertyGrid-esque fashion.

In order to reach these goals, I decide on the following:

1.       I’m going to try replacing the attribute based Component-Designer contract mechanism with new and modified interfaces.

2.       I’m going to make the Component inspection mechanism pluggable, in case someone really wants to fall back on Reflection.

3.       I’m going to come up with some better named interfaces and types to use to modify property values.

4.       I’m going to build some helpers/extension methods to make this painless for IDesignableControl authors.

5.       I’m going to build a PropertyGrid from scratch.

Working on these ideas, I have come up with this:

Since no code was written as part of this article, the most updated code is still AGT[14].

In the next article we’ll look into implementing this approach.


Failures.Add( AutoGenGoogleAds )

by Administrator 29. October 2008 20:43

I love the auto generated Google ads:


I didn't know the 13th Amendment had been repealed?


The War on Excellence

by Administrator 29. October 2008 15:20

I really will get back to technical blogging tomorrow, but politics are consuming too many mental cycles right now.

As I said here, one monumental failure of the current political "share the wealth" thinking is that they simply seek to avoid reality.  We cannot pretend that there are no consequences to taxing wealth.

From this article on Corey the well driller, it would seem that the current political Left feels that people who "fall through the cracks" because they didn't have health care are of utmost national concern.  People like Corey who finally turn a profit after 30 years of struggle and "fall through the other cracks" are not their concern.  After all there are precious few people in America like Corey the well driller and while we as a nation need them, politicians don't need their votes.

As I have said often enough in the past, our notion of the "wealthy" that we "need to tax more" is astoundingly unhinged from reality to begin with.  In addition to my previous thoughts on how horribly dishonest it is to say that Obama's plan will only tax those making more than $250,000 per year, there are some other concerning aspects of this mentality.

First, the plan is a broad stroke.  Even if one bought into the horribly flawed idea that we should tax these "wealthy" people we have used a poor metric with which to delineate them.  In, say, Missouri, $250,000 is a fortune because the cost structure there is cheap compared to other areas of the country.  In Wisconsin, $250,000 doesn't go quite as far but is still a very nice income.  In Manhattan where the cost of living is something like 400% higher than in Milwaukee, a salary of $250,000 may very well include plain old "working middle class professionals". 

The goals and methods of the would-be wealth re-distributors can be even more suspect (if such is possible) using another mathematical method of evaluation.  Let us suppose that the range of income in the United States is from $Zero to $5billion per year.  We have defined the "wealthy", the point at which we should take an extra pound of flesh from people, as $250,000/year.  $250,000 is .005% of $5billion.  If I'm making $250,000 per year and in the same tax bracket, in the same "Abused, eat the rich, they've got plenty" demographic as people making 20,000 times what I make what does that tell me about the nation?  If I'm middle management at an insurance company do I feel that those economic powerhouses are my Peers?  I'm in the same class as Warren Buffet and Bill Gates?  Really?

We have not only demonized Wealth in this nation, we have hijacked the term to mean "anyone making more than I expect I ever will".  Many employees no doubt consider their direct supervisors a member of this privileged upper crust, people who at best make perhaps 30% to 50% more than they do and are already being punished for it via higher marginal tax rates and loss of various categories of deductions. 

This populist class warfare goes hand-in-hand with another phenomenon unfolding over the past decades in America.  When Americans observe a candidate who is well educated, articulate, intelligent, and cultured, we call them an Elitist.  We say that it's bad to be an Elitist.  We say that the other candidate who has few or none of these desirable qualities is "more like me", "down to earth", "someone I could have a beer with", and we want them to call the shots instead of the Elitist.

We exalt the common and seek to elevate the mediocre to the level of the Good.  We have declared, as a nation, that those who Do have fewer rights than those who Can't or Won't.   We seek to punish our betters precisely because of their qualities that we ourselves have identified as Good and Admirable.

America is currently engaged, on all possible fronts, in a War on Excellence.


Blueprint for change?

by Administrator 28. October 2008 16:39

I read Obama's "Blueprint for change" plan from his website, all 64 pages of it.  I am not reading McCain's plan because at this point I highly doubt he'll be elected.  Regular readers know that I don't have a horse in this race, being neither a McCain nor Obama supporter.

My first observation about Obama's plan is that he seems to have everyone covered here, at least everyone who matters to someone who's most likely about to ride a populist vote into office.  Every special interest group has a message for them.  He has something to say to women, minorities, the poor, immigrants, the Green movement, the Labor Unions, people without Health Insurance,  people who can't survive on social security, veterans, people who can't pay their mortgages, the "middle class", people who want to go to college but can't, single parents, and farmers. 

Suspiciously missing is any statement to business owners small and large, to the people in this country legally, to Doctors and Nurses, to the people who are paying their mortgage, to the people saving for their own retirement, to the people who have health insurance, the people who did pay (and are still paying) for their higher education, to the people who saved, to the people who didn't make bad decisions during the housing bubble, to the people without credit card balances.  These people don't count.  These people can not be appealed to give up more of their freedom and offer more tax dollars to the government for the illusion of security.  These people are less likely to have usable sympathy for their less responsible fellow citizens.   No doubt we can expect these people to be sacrificed for the sake of providing for everyone in the first group.  But, wait, says Obama:  Any family making less than $250,000 per year can expect that their taxes won't go up!  Well, I've seen that said in the debates and such, but his plan has some sneaky ways around that fact.

  • Currently we only pay social security taxes on income up to $97,000.  Obama's plan calls for removing this cap to help meet the obligations of Social Security.  So, if you make more than $97,000, you and your employer can count on a 13% tax hike on that income.  Obama is pretending this tax isn't a tax?
  • Employers who can't or won't provide health care for their employees will be taxed (via payroll) so that their employees can participate in his Federal plan.  Some businesses may just absorb this new cost.  Some may not be able to and will pass it on to their customers, or from their employees in the form of smaller raises; some will have to spend less money elsewhere and hire fewer employees.  Lacking specifics on what "qualifying" businesses are, the plan seems to operate on the assumption that business owners are Fat Cats who have plenty of margin in their business to do anything we pass a law forcing them to do.  What about the additional cost in time and money of all the paperwork required to meet these obligations?
  • Obama plans to raise the minimum wage.  Once again, he assumes that the money is just sitting there and needs to be spread around.  Business owners who can't or won't sacrifice their profits to accomplish this will simply hire fewer employees, spend less money rewarding the employees they already have, and pass the cost on to their customers.   We cannot simply declare the Mediocre the equivalent of the Good and walk away.

Like so many politicians, Obama is pretending he can make laws that will "spread the wealth" with no negative side effects.  We need only look at the chronic 12% unemployment rate in Worker's Paradise countries like Germany to gain insight as to where these policies will lead us.  Sure they have health care and 5-weeks of vacation, but the cost is a near-zero GDP growth for a decade and more than double the unemployment of our "broken" system here in America.  When we simply declare that people ought to behave a certain way without regard for Reality and Rights the historical result has always been bread lines and homes that aren't warm in the winter.

If I get time, I will post a more detailed analysis of the Obama plan, possibly before Election Day.


Designing Code Demos

by Administrator 21. October 2008 17:59

When one is giving a technical presentation, issues around source code can be some of the more difficult to plan for.  Do you have the code done already?  Do you write the code on the spot?  If you write code on the spot do you have the code divided into various snippets you can instantly drop in, or do you really type everything?  Is it OK to use a tool like CodeRush or ReSharper that not everyone will be familiar with?  Do you need to be prepared to offer code in both C# and VB.Net?

There has been a "current" or "meme" going around the local community here regarding how the code used in demonstrations is structured.  Some people, it seems, are tired of seeing Database Driven examples or One-Tier samples for .NET topics.  Most commonly picked on is LINQ-to-X: I have heard multiple complaints that it is bad form to bust out "var query = from x in context select x;" from an ASP.Net code behind to show how LINQ works.  In a real application one would have data access classes, Presenters or Controllers, possibly extra business logic classes, and so forth.  The argument goes on that giving a talk and failing to use appropriate separation of concerns like this teaches bad habits to developers and makes the members of the .NET community look like we all implement the Simpleton Pattern.

David Palfery vented to me that after his recent User Group talk on some Silverlight concepts someone approached his boss and gave a reproach for not using more a appropriate separation of concerns in his code demos.  What's the deal with that?  If you can't raise your hand to ask about this, talk to the presenter after the show, or comment on their blog - you are a coward.  Whatever your lot in life, it seems to me to be the most basic of courtesies to extend to someone who's taken their time to hopefully help you grok something.  But, leaving etiquette aside, was this person more or less correct?

The answer is - it depends. 

Was this a talk about Design Patterns or Silverlight Concepts?  What are the chances that an argument over Model-View-Presenter vs. Model-View-ViewModel would erupt?  I'm of the opinion that there are some basic questions that should be asked by an audience member if these things are a concern. 

Q: Excuse me, could you say a few words about what shortcuts you might be taking when demonstrating this concept? 

That's not hard, and assuming the presenter is knowledgeable and experienced they should be able to quickly describe how the quick sample app they are showing you differs from the real-world applications they have probably written before giving a talk in front of an audience.  If a quick description isn't enough to satisfy an audience member, you can put it on the back burner for after the talk.  If my talk is on the ins and outs of Silverlight Data Binding I might rather not spend time explaining how my data access layer, my presenters, my Commands, and my View Models work.  I have to make an assumption here.  If I'm going to use good patterns in my demo code, I'm going to have to assume that most or all of the audience members have at least passing familiarity with said patterns.  If I'm wrong, I'm going to have to set aside part of my presentation to explain the patterns.  This might be very enriching indeed, but myself and my audience may not be as satisfied as if we'd more thoroughly covered the intended topic.  If I'm right and the audience does have a certain level of pattern knowledge, they'll be thinking themselves about what the appropriate abstractions might be.

There are definitely cases though, beyond just knowing your audience, where it is absolutely important to utilize some patterns and practice separation of concerns within your demo code. 

  1. If the nature of the design affects your overall message
  2. If demonstration of a proper design would help neophytes fall into the Pit of Success easier and not detract from time spent on the Core Concepts of your talk
  3. If the quick-and-dirty demonstration method will not work for common situations

The last one probably needs some explanation, and I'm going to pick on Entity Framework here.  I generally like the Entity Framework, but every single early example I saw was creating an easy to follow breadcrumb trail to the Pit of Failure.  Consider a fairly common ASP.Net web forms scenario:

  1. Get some data objects on page load
  2. Bind objects to web controls
  3. Objects are likely to be updated, throw them in the session
  4. On some event, take data out of the web form controls, merge with object data in session, push back down to the data access layer

There were tons of quick and dirty LINQ to Entities examples with the LINQ query against an EntityContext in some Page_Load event, code behind, or other inappropriate place.  These set you up for disappointment.  If you try to push these objects back down to the database (after a couple of postbacks) using the Entity Framework you're going to get an exception saying that these objects are already a tied to some other EntityContext which is now lost.  If you destroy the EntityContext to get around this, you're going to find that you lost change tracking for your entities and wonder why your updates are updating Zero objects every time.  If you Detach() your objects from the EntityContext, thinking you'll re-attach later, you may find that your Entity relationships have disappeared.  You probably don't want to keep an EntityContext open for the lifetime of a Use Case for all sorts of reasons that should be obvious.

As it turns out, hiding the Entity Framework behind a traditional Data Access Layer and using typical DAO semantics requires some clever Extension methods, a few extra lines of code on your part, resigning yourself to updating more fields than actually changed, and some consideration of how this might cause the whole Entity Framework abstraction to leak out into other parts of your application.  It's still worth it, but I wish I'd seen some more real Entity Framework demonstrations while the excitement was building.

It's my opinion that the level of Architecture you need in demo applications is determined by knowing your audience and knowing how naturally the quick and dirty vanilla demo code can be translated into the design of a production ready application.  Those who attend and present at User Group talks should be ready to ask and answer these questions.


Run time is design time for AGT [14]

by Administrator 19. October 2008 20:50

The AGT (Argentum Tela) series of articles is an effort to do two things.  Usually an idea is presented only in its finished form.  The first goal is to do some Reality Blogging, to show an idea evolve over time without pulling any punches.  The second goal, and the example vehicle for the evolution aspect, is an extensible Design Surface for Silverlight similar to what we have in Visual Studio 2008.   This type of application has all sorts of interesting uses.  My example is a Home Theater layout tool.  Read the entire saga:

Moving the Selection with the mouse

Now that select and multi-select are working the next logical step is to allow the user to move things around on the design surface, and I have an idea of what I’d like to support. 

·         A single selected component is straightforward: drag and move.

·         If there are multiple components selected, clicking on any one of them should move the entire selection without changing relative space.

The first item is probably best accomplished by handling mouse events and mouse capture on the invisible “Glass” component of the DesignSite.

Refactor: Some of the mouse event handlers in DesignSite were still named Visual_MouseXXX and should be called Glass_MouseXXX now.

Refactor: Right about this time, Silverlight Release To Web came out.  So far, I’ve not had to change anything from my RC0 code.

We need to decide where to wire up the mouse events associated with moving – in the DesignSurface or in the DesignSite.   Since we are already using the ISelectionService within DesignSite, I’ll try there first.  Remember that the “Glass” control in the DesignSite is the 99% transparent overlay on top of the hosted content.  We need to capture the mouse from the Glass component:

        void Glass_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)


            _selSvc.Select(new List<IDesignableControl> { this });

            _isMoving = true;

            _localMovePoint = e.GetPosition(Glass);

            _surfaceMousePoint = e.GetPosition(DesignParent);

            e.Handled = true;



First I test to make sure I can move a single selected component around:

        private void Glass_MouseMove(object sender, MouseEventArgs e)


            if (_isMoving)


                Point surfacePoint = e.GetPosition(DesignParent);

                //Since we can't grab from outside ourself:

                double left = surfacePoint.X - _localMovePoint.X;

                double top = surfacePoint.Y - _localMovePoint.Y;


                SetValue(Canvas.LeftProperty, left);

                SetValue(Canvas.TopProperty, top);



This works exactly as I’d expect it to.  In order to move multiple selected components at once, I’m expecting that I’ll have to calculate a relative change from the previous mouse location and iterate across all IDCs in the selection, updating their positions.

My selection-code-under-Glass was clearing the multi-selection and replacing it with a single selection, so when I update the Glass_MouseLeftButtonDown method, everything works.

        void Glass_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)


            //if this is already selected, we might want to move.

            if ( (_selSvc.SelectionCount > 0 && _selSvc.GetSelection().Contains(this)))




            else if (!_selSvc.GetSelection().Contains(this))


                _selSvc.Select(new List<IDesignableControl> { this });



            e.Handled = true;



        private void StartMove(MouseButtonEventArgs e)


            _isMoving = true;

            _localMovePoint = e.GetPosition(Glass);

            _surfaceMousePoint = e.GetPosition(DesignParent);



Refactor: I found the app behaved more intuitively when I set it so that clicking on the surface itself would clear the current selection.  This is done by passing null to ISelectionService.Select().

I can now select and move things around on the surface.

In the next article I’m going to finally start working on replacing that section on the right that has said “I am a property grid” for 15 articles so far.  The live demo has been updated, which means you’ll need Silverlight RTW to run it.

Source code: DamonPayne.AGT[14].zip (805.28 KB)


Argentum Tangent - adding another project

by Administrator 19. October 2008 15:19

Back in the first Code Refactoring article in the AGT series I mentioned that I'd like to keep in mind flexibility for using aspects of the framework that were not specific to the designer issue on other projects.  I sat down to do some work on another Silverlight project tonight, and found that I needed to do make some changes to the DamonPayne.AG.IoC framework.  I didn't have to change much, and indeed many people would have foreseen these things before now.  I am a big believer in Just in Time Design - plan for just as much as you know you need, or at least strongly suspect you'll need, and let other patterns emerge through use.  This only works if you're doing enough Use to actually facilitate some meaningful Learning.  Branching out to the second client project, one that does something utterly different than AGT, is a good step forward.

Refactor: I immediately found that I needed a way to Remove an IView that had served its purpose, and that this method was missing from the IRegionManager interface, so I added this.

Refactor: I found that there were some cases where I wanted an AggregateEvent to signify that something had happened, but there was no event payload type necessary.  I changed EventAggregator to allow this and created AggregateEvent, differentiated from AggregateEvent<T>.  While doing this, I found another instance where I was wasting time with ConstructorInfo instead of just using Activator.

In the end, that's not much refactoring for a first attempt at using a framework for another project.  I'm getting ready to possibly use this for more Silverlight projects at CarSpot which should further increase the quality and flexibility of the codebase.


Dead Space

by Administrator 16. October 2008 04:12

We interrupt normally scheduled article writing to bring you a public service announcement concerning the PS3/Xbox360/PC game called Dead Space, widely available today.  I pre ordered this game thinking I'd take a chance; survival horror Movies are my thing, games not so much.  The early impressions started rolling in and they were so overwhelmingly positive I started to get excited.  Two-channel music and gaming in my home theater are excellent sources of stress relief, but Cod4 has started to get old.  I've been eagerly awating Dead Space and the Ars Technica Review did not encourage patience.  These days I do my gaming in a very large dedicated room on a 106" screen with good surround sound.  Let me just say that barely 2 hours into this game, it is executed so well it's unbelievable.  The use of immersive sound scares you, you'll ooh and ahhh at the attention to detail, and then you will witness something horrific that requires a a forceful and horrific response on your part.  This game has flow down to a science, and has other reviewers have noted, they took an innovated approach to the necesary evils of inventory and weapon switching and such: it's all integrated into the game.  You never leave the action.  Enemies will ambush you while you are reading the various logs that you find.  This game is awesome.  If you like horror, do not have a weak stomach, and can play games in the dark, you must buy it.



Silverlight 2 RTW

by Administrator 14. October 2008 14:13

Silverlight 2 is a real, shipping product today.

Later this week, I'll be converting my development environment and projects (including AGT) over to the Real Deal, and hopefully releasing some stuff at CarSpot too.


Wisconsin .NET User's Group Silverlight Presentation

by Administrator 13. October 2008 19:22

I will not be there due to family being in town, but I encourage you to check out David Palfery's presentation in the Milwaukee area tomorrow night:  If you'd like a preview of what he's presenting, check out his blog at .

There's also a Silverlight SIG branch of our User Group now, and I sadly missed the first meeting.  Perhaps in the future Milwaukee Silverlight coders would like to see a presentation on a Silverlight IoC framework and its application to a Visio-type drawing tool?


About the author

Damon Payne is a Microsoft MVP specializing in Smart Client solution architecture. 

INETA Community Speakers Program

Month List

Page List

flickr photostream