Cool Client Stuff : Whidbey

Visual Studio Express will be free permanently!

rprabhu — Fri, 21 Apr 2006 10:53:00 GMT

Great news - it was annouced a couple of days back that Visual Studio Express, originally offered free for one year, will now be free permanently!

Haven't heard of Express products before? Read this FAQ.

Not only are the Express products free, they are pretty lightweight and quick to install as well. They are awesome especially for hobbyist and student programmers who want to learn how to code or develop something quickly.

Per the FAQ, SQL Server 2005 Express will continue to be a free download as well.

Saving out a Form's Size and Location using the Application Settings feature

rprabhu — Tue, 29 Nov 2005 10:30:00 GMT

A very common requirement for Windows Forms applications is the ability to 'remember' the location and size of forms when they are closed, so that the next time they are shown, they can be restored to the former position. The Application Settings feature is .NET 2.0 makes it simple to do this, but unfortunately, it is a little hard to get it 'just right'. This question is asked frequently on internal and external Microsoft forums, so I thought it warranted a blog post.

Now, the Windows Forms designer in Visual Studio 2005 provides a simple UI to data bind properties on controls to application settings. So the first thing that might occur to you is to simply bind the Form's Location and Size properties to settings, add a line of code to save the settings class, and that's it! Unfortunately, this is not the best option for a few reasons:

First of all, you may notice that the Form.Size property is not offered up in the settings binding UI. This is because this property is marked DesignerSerializationVisibility.Hidden, so the designer doesn't know how to serialize it, let alone generate a data binding for it. Instead, for Form, the ClientSize property is the one that gets serialized.
So okay, maybe you can bind Location and ClientSize then? Well, yes, but this has another problem. Try setting it up and then attempt to resize the form from the left or top edge. You will see weird behavior. Why is this? It is beyond the scope of this post to give the full explanation, but it suffices to say that it has to do with how two way data binding works in the context of property sets that mutually affect each other (in the case of Location and ClientSize, both eventually call into a common method, SetBoundsCore()).
This solution does not do the 'right' thing in the situation when the user maximized the form before closing it. In this case, you probably want to remember that the form was maximized, but also keep track of the last location/size before it was maximized, so you can restore it the next time the user hits the Restore button. You may want to handle the minimize case in a similar way too. The simple data binding solution does not do this right.
Data binding to properties like Location and Size is just not efficient. Each time the user moves the form or resizes it, Windows sends hundreds of messages to the form, causing the data binding logic to do a lot of processing, when all you want is just to store the last position and size before the form is closed.

The good news is that this is very easy to do with a few lines of code:

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{

     Properties.Settings.Default.MyState = this.WindowState;

if (this.WindowState == FormWindowState.Normal)

{

   Properties.Settings.Default.MySize = this.Size;

   Properties.Settings.Default.MyLoc = this.Location;

}

else

{

   Properties.Settings.Default.MySize = this.RestoreBounds.Size;

   Properties.Settings.Default.MyLoc = this.RestoreBounds.Location;

}

Properties.Settings.Default.Save();

}

private void Form1_Load(object sender, EventArgs e)

{

this.Size = Properties.Settings.Default.MySize;

this.Location = Properties.Settings.Default.MyLoc;

this.WindowState = Properties.Settings.Default.MyState;

}

By the way, speaking of Windows Forms 2.0, there is a lot of great new content on the WindowsForms.net site. Jessica has been actively blogging on interesting Windows Forms topics too.

I have heard of the BSoD - what's a WSoD?

rprabhu — Thu, 11 Aug 2005 11:59:00 GMT

If you have used the Windows Forms designer in Visual Studio 2005 enough, chances are you may have occasionally seen a white error screen instead of the design time form. This screen, fondly referred to as WSoD in our team, shows up when error(s) are encountered in the process of loading the designer. Now, if you have used Visual Studio 2002/2003, you may recollect that in the face of errors, the designer would usually continue the load and quietly display the errors in the tasklist. That was much less intrusive and did not require the developer to drop whatever they were doing and fix the errors. Why then did we take this seemingly retrograde step back into the Windows 95 era?

There is a very good reason for that. If an error is encountered while loading the designer and you ignore it and make modifications to the design time form, there is inevitably one result - data loss. This is because the next time the designer flushes, it will wipe InitializeComponent() clean and serialize out code for the current state of components in the designer (this is how the designer always works). If there were lines of code in there that it failed to parse during the load, at this point they will be lost. This could mean property sets or even whole components 'disappear' from the designer.

It is to prevent this inadvertant data loss that we introduced the WSoD in VS 2005. The WSoD makes it very obvious to the user that there were errors, and does not allow modifications to be made to the designer till they are resolved. Now, unlike its blue counterpart, the WSoD actually contains information useful to the user. It shows a list of errors that were encountered along with stack traces and very often, the line of code in InitializeComponent() that is responsible for each error. Equipped with this information, the developer should be able to open the code behind file (which is now thankfully in a separate partial class, distinct from user code) and fix up the lines that caused the problem.

Now, clearly, not everyone is a huge fan of this idea. Developers don't like being blocked from making progress this way. For example, let's say you have a DataGridView and some other controls on your form referencing a DataSet in the project. If you delete the DataSet when you have the form designer window open, you will likely see a WSoD. This can be frustrating - why wasn't VS clever enough to auto-correct the problem for me?

Well, the problem is: what is the right solution?

Should it delete all the controls referencing the dataset automatically? What if the developer wanted them to remain there so they could set them up with a new dataset?

Should it keep the controls, but ignore the error and continue to load? Well, if the developer misses the warnings in the task list, all of a sudden, they might end up with controls in a bad state and lose some data.

So you see, there is no good 'automagic' solution. We thought it best to leave the developer in control of the situation and decide the best way to fix the issue. Essentially, we weighed user-friendlyness with data loss and ruled in favor of preventing data loss as much as possible. I don't know about you, but I would prefer to spend a few minutes fixing stuff up rather than inadvertantly losing hours of hard work with the next flush.

P.S.> If you have never heard of the BSoD (I am sure there are plenty of you that haven't :-)), here is a good description.

WinRes: Improvements in Whidbey

rprabhu — Fri, 18 Feb 2005 09:41:00 GMT

One of the first posts I made, after starting this blog, was about WinRes, a UI localization tool that ships with the .NET Framework SDK. The reason I wrote that post was that I had been increasing noticing how many people had the same set of issues with WinRes, and were having trouble resolving them, given that there isn't much documentation on MSDN about it. The information in that post gives a general understanding of how WinRes works and helps you debug the most common problems you may run into.

Ofcourse, simply documenting the issues is not enough, so we have attempted to improve the tool in Whidbey (.NET 2.0). Here are some of the improvements we have made:

1) Better error reporting - The single biggest problem users had with WinRes was not the errors, but the fact that it was very difficult to diagnose them. Many a time, WinRes simply failed to load a resource file and displayed an extremely informative message like 'Unknown item' or ' Item not found'. Not surprisingly, the user was left with no clue with what to do next. What's worse is that the typical user of WinRes is a localization/language expert, not a developer who can be expected to debug his/her way through the problem. I am happy to say that the error reporting is much improved in Whidbey. In typical cases, WinRes should be able to give a clear and specific indication of what the problem is, like the particular element in the resx that is invalid or which component it was not able to parent correctly and so on. It still may not be totally obvious how to resolve the problem, but you should atleast have something specific to go on. There will still be cases when WinRes will not be able to clearly pinpoint the problem, but it should, as a last resort, atleast show you what exception occured.

2) Robustness - A related issue with WinRes' loading mechanism was its sensitivity to problems. For example, it used to often fail to load an entire dialog just because it couldn't find one component's assembly or found one property it could not interpret. In Whidbey, WinRes is much more resilient to issues like these. In most cases, it will load the dialog inspite of such errors and report to you what errors occured in a textbox below the designer (much like the tasklist in Visual Studio). For example, if a component's type is not found, it will load the dialog and use a place holder control for that dialog, so that you can continue localizing (although I strongly recommend you ensure all the assemblies that are referenced in the resource file are placed either in the GAC or in the same directory as WinRes.exe, so it can locate and load them).

3) Support for VS localized resx files - One limitation of WinRes in v1.0/1.1 was that it required localized resx files (like Form1.ar.resx) to be self contained, in the sense that they had to have all the localizable properties defined in them. However, if you used Visual Studio for localization, the resx files it produced only contained diffs from the parent culture, which is more efficient and fits into the runtime resource loading behavior. These VS localized resx files could not be opened in WinRes, since it did not support the use of multiple resx files to load the dialog. In Whidbey, WinRes has the ability to do this and if you place the parent culture resx files in the same directory as the file you are trying to open, it should be able to pick them up and load the dialog.

4) Some support for public inherited controls - In v1.0/1.1, WinRes had trouble loading dialogs that had public inherited controls. We have fixed this issue in Whidbey and it should now be possible, in typical cases, to open these dialogs without problems. Note though that there will always be limitations in this area. There are many complex inheritance cases that we will still not be able to support (not only in WinRes, but even in the VS designer). Visual inheritance, though a tempting design choice, is fraught with many problems - but let me save that rather controversial topic for a separate post :-)

These are the major issues - besides these, we have fixed several small (yet irritating) bugs and improved the UI a bit. WinRes also supports the new designer improvements like snap lines for layout, since its designer has been rewritten to use the Whidbey designer hosting API. See also this post for improvements to localization in general in Whidbey.

If you have a chance to try out WinRes in Whidbey builds and find any issues you would like resolved, do let us know through MSDN Product Feedback. Note that some of the improvements mentioned above may not have made it into Beta 1 or the recent CTP builds, but should be available in the Beta 2 release.

In summary, WinRes is a useful, free tool that handles the most common and basic UI localization scenarios. For more advanced cases, users may prefer to use one of the third party localization tools available.

Smart Client in focus again

rprabhu — Wed, 09 Feb 2005 10:42:00 GMT

Good to see that Soma's keynote at VSLive! San Francisco brings the concept of 'smart client' back in focus. This is something I am personally passionate about and it is also the theme of this blog. Here is Soma's blog post on the topic and you can view the keynote video here.

Still not sure what a smart client is as opposed to a simple client application or a 'rich client'? I don't blame you - there are too many of these terms floating around. Believe it or not, 'smart client' isn't just a fancy new term for the same old thing - it is indeed a new kind of application model that attempts to combine the best of the client and web worlds. Check out the Smart Client Developer Center on MSDN to understand exactly what smart client means.

With features like ClickOnce and Client Settings, not to mention the very significant advances in Windows Forms, .NET Framework 2.0 is going to be a great platform for smart client application development!

Windows Forms Bug Reporting Challenge

rprabhu — Tue, 23 Nov 2004 04:56:00 GMT

Feels good to return to blogging after a long break! We in the developer division have been pretty busy last few weeks working towards a stable Whidbey Beta 2. ScottGu's blog post has a good description of where we are in the Whidbey product cycle.

If you are beta testing Windows Forms 2.0 or Clickonce, you might be interested in the bug reporting contest. As I mentioned in a previous post, the feedback we have received through the MSDN Product Feedback Center has been simply awesome. This has given us a chance to know what changes you would like to see in the product before we ship. Do keep the bug reports and suggestions coming!

Impact of the MSDN Product Feedback Center

rprabhu — Thu, 07 Oct 2004 06:39:00 GMT

Its been quite a long time since my last blog post. We have been pretty busy over the last couple of months (and will be for a few more weeks) driving towards a high quality Beta 2 of Visual Studio 2005 (Whidbey). This next release should be far more stable, secure and complete than Beta 1. We have been resolving all kinds of bugs and design issues over the past few weeks and looking back, I am greatly impressed at the impact the recently launched MSDN Product Feedback Center has had on VS 2005.

As a sample, here are some of the issues/suggestions I personally have had a chance to look at. I think the most useful product feedback falls into the following categories:

Obscure scenario - a scenario we missed in our own tests. For example, trying to import a resource in Visual Studio with an unusual filename, like '0'. While such scenarios are quite rare, they are a source of irritation if when you do run into them, Visual Studio behaves unpredictably.
Great suggestion - we get quite a few suggestions for improving a particular feature or behavior, and some of them are real gems. I have personally seen a couple related to the Client Settings feature that fall into this category.
Feedback from third party component developers - this set of customers give us very valuable feedback about things like our component model, localization and designer infrastructure. This helps us tune these classes to allow better customization and extensibility of our feature set.

While there are (and have been) other sources of feedback like newsgroups, direct emails and dev labs, I think the product feedback center has some distinct advantages. First of all, the reach - pretty much anyone can give feedback. Second, there is a clear process for tracking every bug/suggestion we get. Nearly every single bug is looked at by the product teams. Third, due to the voting feature, we get a good idea of how many customers ran into a particular issue and consider important.

Finally, and I think this is the most important, the person who entered the bug, and also the whole community, has a chance to find out what the product team decided to do with the bug. So this is not like one of those surveys you fill out and never hear about again - you can track the bug at every stage of the process.

So once again, a big THANK YOU to everyone who gave their feedback and continue to do so! For me personally, it is very nice to see the features I implemented being put to use and a great source of satisfaction being able to address the issues real customers are seeing with the product. I am sure everyone else in the product teams feels the same!

Localization in Whidbey

rprabhu — Wed, 04 Aug 2004 11:10:00 GMT

Before I describe how Windows Forms localization works in Whidbey, let us first take a look at how it works in VS 2002/2003. Consider a Form with a Button control on it. When you mark it Localizable = True in the property grid, the designer generates code for the Button that looks like this:

this.button1.AccessibleDescription = resources.GetString("button1.AccessibleDescription");
this.button1.AccessibleName = resources.GetString("button1.AccessibleName");
this.button1.Anchor = ((System.Windows.Forms.AnchorStyles)(resources.GetObject("button1.Anchor")));
this.button1.BackgroundImage = ((System.Drawing.Image)(resources.GetObject("button1.BackgroundImage")));
this.button1.Dock = ((System.Windows.Forms.DockStyle)(resources.GetObject("button1.Dock")));
this.button1.Enabled = ((bool)(resources.GetObject("button1.Enabled")));
this.button1.FlatStyle = ((System.Windows.Forms.FlatStyle)(resources.GetObject("button1.FlatStyle")));
this.button1.Font = ((System.Drawing.Font)(resources.GetObject("button1.Font")));
this.button1.Image = ((System.Drawing.Image)(resources.GetObject("button1.Image")));
this.button1.ImageAlign = ((System.Drawing.ContentAlignment)(resources.GetObject("button1.ImageAlign")));
...

where 'resources' is an instance of the ResourceManager class. Basically, the serializer pushes the values of all properties on Button that are marked with LocalizableAttribute.Yes to the resource file and generates code to pull these values when the form is constructed. This allows the localizer to set different values for these properties based on the culture. Depending on the culture the application gets run under, the property values will be pulled back from the appropriate resource (with fallback to neutral and default culture resources when values are not found in a specific culture resource file).

So if you are developing a component, all you need to do is mark the set of properties on it that you think can vary based on culture with LocalizableAttribute.Yes and you are all set. If you are an app developer, things are even simpler - just set Localizable = True on your Form.

You will notice, though, that there is some room for improvement in this model. Here are some drawbacks:

1) Does not scale very well - Components typically have a large number of localizable properties - for example, the Button control has about 20 of them. This means that each time the form is constructed, 20 property values are retrieved from the resource file and set on the Button. For a large form with 100 controls, that adds up to 2000 properties on average. The interesting thing here is that these properties are only potentially localizable - it is possible and even likely that only a small number of them have actually been localized in different cultures. For example, if the button does not have a background image in the default culture, it most likely doesn't in other cultures as well. Yet, the code will retrieve the value (null) from the resource file on form construction.

2) Code bloat in InitializeComponent - In a non-localized form, the serializer will typically only generate code for properties that have been set to non-default values. However, when you turn localization on, it will generate code for all localizable properties, as shown above. This usually means a lot more lines of code in InitializeComponent.

3) Clutter in the resource file - Each of the localizable properties also get their values pushed into the resource files, even properties that have default values and for which the developer probably has no intention of setting non-default values.

So in Whidbey, we spent some time thinking about how we could improve this model and address these drawbacks. Obviously, we had to remain backward compatible, so we couldn't simply start over and invent a new model. I will now describe what we did come up with.

In Whidbey, we support two localization models - PropertyAssignment and PropertyReflection. PropertyAssignment is similar to the model described above. PropertyReflection indicates that the designer will use the ComponentResourceManager class to reflect on properties by name to fill them at runtime. This uses reflection at runtime so it can be slow, but it scales better for large numbers of properties with default values. The designer loader can specify how localization should work through a CodeDomLocalizationProvider, but let's not discuss those details now - what's important is that the Visual Studio designer in Whidbey uses the PropertyReflection model by default.

This means that the code in InitializeComponent will look simply like:

resources.ApplyResources(this.button1, "button1");

As mentioned above, this call will use reflection to pull values from the appropriate resource file. The designer will only push non-default property values into the resources, so typically these will be far fewer than in the VS 2002/2003. So essentially, we are now optimizing for the common case - where a large number of properties have default values. The code in InitializeComponent is very concise and we only push non-default values into resources, so (2) and (3) are addressed too.

Visual Studio 2005 Beta!

rprabhu — Tue, 29 Jun 2004 15:29:00 GMT

It's finally out - Visual Studio 2005 and .NET Framework 2.0 Beta 1! Here are the relevant links:

VS 2005 Beta Developer Center - portal for all VS 2005 Beta related information, including links to download.
VS 2005 Express Products - described as “lightweight, easy to use, easy to learn tools for hobbyists, enthusiasts, and students to learn and evaluate programming for Windows.“
VS 2005 Beta Online Documentation
MSDN Product Feedback Center - a great place to report bugs and make suggestions.

Releasing a product (even a Beta) after months of hard work is such a great feeling! I am particularly excited about the Express products, since they offer beginners a super-easy way to get a feel for programming on the Windows platform. See how simple it is to write your own application to keep track of your movie collection or a screen saver that displays RSS feeds.

Don't miss the Summer of Express Contest on Channel 9! And here is Scoble's nice summary post on the new annoucements.

Client Settings - Part 3

rprabhu — Fri, 18 Jun 2004 17:00:00 GMT

RichB has some interesting questions in his comments about my earlier post on the client settings feature. I thought it might be worth a separate post to answer them.

I don't have the CTP available, but from the documentation it appears that ApplicationSettingsBase can read and write to a collection of providers. I can understand the writing to multiple providers (saving the same values into multiple locations) but how does it read the same values from multiple locations.

Yes, a settings class can talk to multiple providers, but each setting (or property) in it is associated with a single provider. This just means that you can have different providers for different settings in a settings class.

I also hope you have a good "story" for plug-in based applications. For example, Lutz Roeder's Reflector and Nikhil's Web Matrix are both heavily pluggable. Is there a prescribed way for each plug-in/component to obtain and save configuration information to the same store?

Yes, we have a story for this scenario. There is an interface called IPersistComponentSettings that any component can implement to save its own settings when hosted in an application. For example, the ToolStrip control implements this. Someone using the ToolStrip in their app can just set a property called SaveSettings to true and the ToolStrip will save/restore settings automatically without the user having to set anything up.

I'm also a bit hazy on Setting Groups. I've noticed the SettingsGroupNameAttribute - but am not entirely clear on how it's meant to be used.

Usually, the settings class name is used to identify your settings in the store. If you want them stored with a different name or share settings with some other class, you can use the SettingsGroupNameAttribute to rename/redirect your settings.

Finally, do you have generic methods for loading from the store to prevent boxing?

No, but that's a good suggestion. We will consider doing this.

Designer Hosting in Whidbey

rprabhu — Tue, 15 Jun 2004 09:07:00 GMT

If you have had a chance to play with Visual Studio Whidbey, you may have noticed some of the cool new features in the Forms designer - snap lines, smart tags and so on. Now what if you desire to expose some of this design time UI in your own application? Guess what, Whidbey makes this super easy to do! As I will show below, with less than 10 lines of code, you can display a form that hosts the Windows Forms designer.

The designer classes you will need are located in the various System.*.Design namespaces, particularly System.ComponentModel.Design. These are part of System.Design.dll, so you will first need to add a reference to this assembly (that ships as part of the .NET Framework SDK).

The first thing you need to do is create a DesignSurface. This is the class that represents the user interface that you would think of as the “designer”.

DesignSurface surface = new DesignSurface();

There, now we have a DesignSurface. Next, we need to indicate what the type of the root component is, and ask the DesignSurface to load it. We want a Form designer, so:

surface.BeginLoad(typeof(Form));

BeginLoad begins the process of loading the designer, and will continue asynchronously. However, the “view” that represents the root component at design time is immediately available after this call.

Control view = (Control) surface.View;

Cool, now we have a Control that represents the View. We can manipulate this Control just like any other Windows Forms Control. In this case, lets dock fill it and add it to a Form.

view.Dock = DockStyle.Fill;
Form myDesigner = new Form();
myDesigner.Controls.Add(view);
myDesigner.Show();

That's it! You now have a form hosting the Windows Forms designer, complete with support for snap lines, smart tags etc! Ofcourse, to create a little more functional designer, you need to provide a way to add components to the Form, set properties etc. You may also need to implement a couple of designer services along the way. But the 7 lines of code above are all you need to get started!

Strongly typed resource model in Whidbey

rprabhu — Tue, 25 May 2004 07:49:00 GMT

In Visual Studio 2003 and earlier, managing resources like images and icons in your project is somewhat difficult. For example, when you try to assign an image to a PictureBox through the property grid, you get the FileOpenDialog. When you pick an image file, the image is dumped into the form's resx file as a binary blob. If you want to use the same image in a different form (lets say all your forms have the same background image), you would need to pick the same image over and over again, thereby duplicating the binary blobs in each form's resx file. Now, what if you needed to edit the image, say, to insert a company logo? Not very easy. What if you decided to pick a new image? You need to do so all over again for all your forms. Also, the code to access the resources is weakly typed, i.e., something like:

this.BackgroundImage = (System.Drawing.Image) resources.GetObject(”MyImage.jpg”);

where 'resources' is of type ResourceManager.

One other thing: the default editor for resx files is a table of resource names. It isn't very easy to add new resources or edit existing ones.

Ofcourse, you can work around these limitations through code, but this is the default design time experience.

In Whidbey, we spent quite sometime thinking about how we could improve this experience. The result was that we designed a new model to store and access resources in Visual Studio projects. Here are some of the highlights of the new model:

When you try to assign an image to a control in the Whidbey designer, you will see a 'Select Resouce' dialog. This dialog will help you “import“ resources into project resource files. The imported resources, by default, will not get embedded into the resx files, but instead copied to a Resources folder in the project and referenced in the resx files by means of ResxFileRef.
For each resx file, you can enable strongly typed access (whch typically will be automatically enabled for the default project resx file and any file you import resources into using the Select Resource dialog). This means that we will generate a class that allows you to access resources through strongly typed properties. For instance, the code in InitializeComponent will look something like:

Me.BackgroundImage = My.Resources.MyImage

in VB, and something similar in C# and J#.

Since the entries in the resx files are file references rather than binary blobs, you can edit the images and the changes will automatically be picked up wherever those images are referenced. Since these resx files are project level rather than form level, you can access the resources across forms in your project.
There is a new Managed Resource Editor in Whidbey that allows you to easily edit resx files - update entries, add entries, import resources, delete entries etc.

This should help improve the overall experience around managing project resources. Do let us know how you find this new model when you get a chance to play with it!

Whidbey content on WindowsForms.net

rprabhu — Tue, 25 May 2004 06:57:00 GMT

If you haven't looked at it already, you may want to check out the new Whidbey section on WindowsForms.net. It includes overviews and screenshots of the new Whidbey features for client application development. There is also a link to forums where you can give feedback.

What's this new GenerateMember property?

rprabhu — Thu, 06 May 2004 09:04:00 GMT

If you have played with Whidbey builds of Visual Studio, you may have noticed this new property called GenerateMember that shows up in the property grid for all controls and components you add to a Windows Form. Wondering what it is about? It is actually a design time extender property that allows you to control whether a component added to the form is referenced by a member variable in the class or a local variable in InitializeComponent. By default, it is set to true, but if you have any components that you are not really referencing outside of InitializeComponent, you can set it to false. That way you can limit the member variables in your class to only the components you really need member variables for - just something to prevent clutter.

This is just one of those little features that many will probably not notice, but those that do might find very convenient!

New articles on Whidbey Windows Forms and ClickOnce

rprabhu — Sun, 25 Apr 2004 09:23:00 GMT

Nice overview of some of the new features in Windows Forms and ClickOnce (via Chris Sells' blog).