New TryParse method in .net 2

.net 2 introduces new TryParse method for many base structures such as Int32. However, it is not limited to structs only (IPAddress has its own TryParse, too). Why .net 2 introduces this method at all, since we already have Parse method you might wonder? Let's look at the example how you would use Int32.Parse method:

tring s = "1";

try

{

int i = Int32.Parse(s);

}

catch (Exception ex)

{

// ... deal with bad input

}

This code works, but it is expensive in terms of performance because handling exceptions is always more expensive than handling return values. Also, it is somewhat verbose. That's why there is TryParse:

string s = "1";

int i;

bool result = Int32.TryParse(s, out i);

At first glance it is obvious that the code is far more explanatory. Also note that instead of getting an exception if the input is not correct, you get a false value. And TryParse internally doesn't use exceptions handling mechanisms which make it faster, too. One thing that you might pay attention to, is that you get some sort of value stored into the variable you pass regardless if the operation succeeds or not (the consequence of out keyword). IOW even if there is a conversion error you variable will be set to 0 (in numeric case) and not left as is as in Parse example.

Anyway, the bottom line is that there is no reason for you to not to deprecate Parse and build your code using TryParse instead.

Why are dialogs in Visual Studio fixed size?

Why are many dialogs within Visual Studio 200x made fixed size without option to resize them is beyond me. Take for example Choose Items... dialog for Toolbox. It looks ridiculously small on my 20" LCD and I struggle to find the right components, specially as they usually have long namespace, assembly name and directory. It is really annoying all that scrolling and I wonder why is this pain really necessary? Just set it as resizable and resize the list accordingly - is this so difficult? Another example is WWF's type picker, though this one is larger at least and I am sure that they are plenty of others. I don't know - I've made suggestions to made all dialog resizable (those that make sense) a way back in time of Visual Studio 2002 or 2003. It was postponed.

IMO this is really an unnecessary annoyance dragging along all Visual Studio versions. Oh well, time to make suggestions for Orcas. I must hurry, otherwise they'll be postponed.

WPF samples not working and how to fix them

At least some samples that come with WinFX November CTP don't work because of breaking changes (I've got link via Karstern Januszewski). Take for example first page of ExpenseIt sample that you find in Demos\ExpenseIt folder of samples you unzipped. Run it and few moments later an exception sourcing from baml will be thrown saying something about VerticalGradient. If you take a look at breaking changes you'll see that VerticalGradient is mentioned. Open App.xaml, find the following line:

<Style x:Key="TotalRectangle" TargetType="{x:Type Rectangle}">

There are two setters containing VerticalGradient in their values and since the constructs inside Value are strings the errors aren't picked by compiler:

 <Setter Property="Stroke" Value="VerticalGradient #4E87D4 #73B2F5">

 <Setter Property="Stroke" Value="VerticalGradient #73B2F5 #4E87D4">

They should be transformed to this constructs:

<Setter Property="Stroke">

<Setter.Value>

<LinearGradientBrush StartPoint="0,0" EndPoint="0,1" >

<LinearGradientBrush.GradientStops>

<GradientStopCollection>

<GradientStop Offset="0" Color="#4E87D4" />

<GradientStop Offset="1" Color="#73B2F5" />

</GradientStopCollection>

</LinearGradientBrush.GradientStops>

</LinearGradientBrush>

</Setter.Value>

</Setter>

and

<Setter Property="Fill">

<Setter.Value>

<LinearGradientBrush StartPoint="0,0" EndPoint="0,1" >

<LinearGradientBrush.GradientStops>

<GradientStopCollection>

<GradientStop Offset="0" Color="#73B2F5" />

<GradientStop Offset="1" Color="#4E87D4" />

</GradientStopCollection>

</LinearGradientBrush.GradientStops>

</LinearGradientBrush>

</Setter.Value>

</Setter>

respectively. That's a bit verbose, isn't it. For some reason they removed mini language constructs - didn't have time to check it out why. Anyway, after these two changes the first page works but not the second which yields another exception. I don't go into this one though. Just wanted to show you how to fix the incompatibilities. I guess that not-all-samples-are-working syndrome is the consequence of CTP release (and not beta which is normally better prepared).

Is Windows Workflow Foundation missing generics, too

A while ago I've blogged about missing generics in Windows Presentation Framework. Now I took a look at Windows Workflow Foundation and I immediately bumped over an object (ParameterDeclaration.Value) that should be a generic instead. There appears to be a general shortage of generics in WinFX. Not sure why. Perhaps it has something to do with the fact that it is ParameterDeclaration is editable in designer and designer doesn't deal with generics at all. Ok, later on I saw signs of generics here and there. It would be nice if designer learns what to do with generic parameters though.

WinFX November CTP compatible with VS 2005 RTM is here...well, sort of

Tom Archer blogged that WinFX November CTP drop compatible with Visual Studio 2005 RTM/.net 2 RTM is available for download. Now, don't be too enthustiastic. While he gives MS internal hyperlinks (useless is you don't have access to MS internal network) and the drop is actually not yet available through MSDN Subscriber Downloads, this is a good sign that WinFX is soon to be released.

Mother of all Visual Studio 2005 RTM bugs

Sit down, this one is huge.

Apparently Microsoft doesn't have Windows Forms Designer support for complex controls on derived forms, in other words, if you created a form with a complex control (DataGridView is perfect candidate), made this control protected or more, derived a new form then you have problems. Nasty, huge problem if this is caused by a bug in Windows Forms Designer in 2005. The control on derived form is readonly (1) for designer - no more visual editing. Even worse, if you implemented control's events on derived form with previous Visual Studio 200x versions designer will yield an exception (2). And this "feature" affects third party controls, too. This bug is a joke compared to this "lack of feature".

In my view, this lockdown feature is horrible. I always used visual inheritance with 3rd party and it always worked just fine. Needless to say that this impacts design of my application tremendously. Again, if this is a new problem in WFD this has to be fixed as soon as possible - Microsoft, please?

UPDATE: The situation is unclear so far. It isn't clear so far what is wrong with designer and if this problem was introduced with Visual Studio 2005 or if it was there before in 2003 or even 2002.

UPDATE: I checked and saw that DataGridView was locked even in beta 2 this leads me to the conclusion that the problem was always there in VS 2005.

UPDATE: To be more precise, it is up to the control itself to deny its editing in designer when it is inherited.  The readonly status was therefore implemented by Microsoft (in case of DataGridView and ToolStrip) or Developer Express guys (in case of XtraGrid, XtraBars and few others).

UPDATE: I checked the Prouduct Feedback Center and of course, I am not first person to notice this problem. This is one of the MS' response on the subject:
"Thanks for your problem report. I understand your frustration around this issue, but we disabled this scenario intentionally. We chose to not make the engineering effort it would have required to enable this scenario for Whidbey. This decision was not make lightly and we understand customers would like this functionality, but the existing visual inheritance architecture in combination with collection based controls makes it extremely costly to address. We hope to enable this in future versions. Until then, you'll have to use code to achieve this. Thanks again for your support of Windows Forms and ToolStrips." See the entiries here, here and here.
Now, my only hope is reduced to the fact that this problem might have been around since previous Visual Studio versions (and for sure it has been around since 2005 beta 2) which means, that, when carefuly using designer you shouldn't have problems (assuming  as I worked with Developer Express controls normally until they disabled editing in the last version.

Funny - I would be happy to know that this bug has been around for a while.