It is all about handling values that are not Integers, Overflow values and Nulls. There are subtle differences, in the handling of the methods, and the exceptions they could throw: ArgumentNullException, FormatException and OverflowException.
Setting ForeColor = Color.Red (funny there is a plural in SystemColors but not in Color) it doesn’t display it as such:
To my surprise, the TextBox had ReadOnly text (you could copy, but not modify it), which showed with a a grey (SystemColors.Control) BackColor and a black (SystemColors.WindowText) ForeColor: the defaults for a ReadOnly TextBox, not using my ForeColor = Color.Red;
I vaguely remembered there was some odd way of solving this, but since I hadn’t written a blog article about it back then (somewhere around .NET 1.x or 2.0 I didn’t have a blog yet), I was glad that Cheetah posted this answer on StackOverflow: Read the rest of this entry »
Reuse the VB.NET built-in Replace Function (Visual Basic) which works at least as of Visual Studio 2003 (.NET 1.1) and probably in Visual Studio 2002 (.NET 1.0, which I don’t have any more)
Normally you would not want to use a reserved word as an identifier. But sometimes it can be very convenient, for instance for a code generator that wraps remoting calls or does ORM.
Turning off Option Strict can be OK under many circumstances (the default is off), but having Option Explicit off is usually a code smell as well, just like On Error Resume Next (which was also in plenty of the source code).
I do understand a lot of VB.NET source comes from people having programmed in VB 6, VBScript or VBA for a long time where those constructs were more common. But writing code in the 21st century is much more about writing code that you can prove to be right. Having proper error handling and compiler type checking is a big part of that.
Back to CType: basically you have do distinguish between conversions and casts. The reason is that when you know it will be a form of cast, CType is way to expensive. And if you know you will be doing conversions, than casting is not what you want.
How do I create the default for a generic in VB.NET? in C# I can call: T variable = default(T);
How do I do this in VB?
If this just returns null (C#) or nothing (VB.NET) then what happens to value types?
Is there a way to specify for a custom type what the default value is? For instance what if I want the default value to be the equivalent to calling a parameterless constructor on my class.
Dim variable As T ‘ or ‘ Dim variable As T = Nothing ‘ or ‘ Dim variable As New T() Notice that the latter only works if you specifiy either the New or the Structure constraint for the generic type.
Question 2:
For value types all members of the struct are “nulled” out, i.e. all reference type members are set to null (Nothing) and all value types are in turn nulled out. And no, since string is a reference type, it does not result in "" for strings as suggested in the other answer.
Question 3:
No, there’s no way to specify this. There are some threads about this on Stack Overflow already, e.g. here. Jon has posted an excellent explanation why this is.
Before showing the code at the bottom of this blog post, let me explain the question in more detail:
Basically I was in the midst of refactoring some ‘inherited’ business logic code that – before refactoring – for the ASP.NET side needs to be initialized with an absolute path, but on the WinForms / WPF side only with a relative path to a GetExecutingAssembly directory.
To ease xcopy deployment, I wanted all configuration settings to be relative. But I hadn’t found a common means for these platforms to obtain a directory usable as a root for accessing relative files.
That way I could put identical settings in both the Web.config and App.config, heck even generate them based on a common fragment, whithout having to hard-code absolute path names.
I knew about Assembly.GetExecutingAssembly, but in ASP.NET that location is not where the web site is (both IIS and the WebDevelopment server make use of temporary locations to store the assemblies).
ASP.NET does have Server.MapPath and HostingEnvironment.MapPath, but I didn’t want to make the business logic depend on ASP.NET.
Igor Ostrovsky wrote a few very nice MSDN magazine articles. Not all of them have ended up in the list at MSDN magazine, so here is a more complete list:
Though the articles show the majority of sample code in C#, the actual topics are of great interest to any developer writing .NET code or interfacing to it.
When you have a layered exception handling (for instance to translate general exceptions into domain or business exceptions, and want to control which exceptions trickle up to where), then from a debugger perspective, most exceptions actually handled.
However debugging those layers, it often makes sens to be able to break where all these exceptions are actually fired.
The screenshots (click on each to enlarge) are for Visual Studio 2010, but it works in any Visual Studio version and (since it is a debugger feature, not a language one) for all .NET languages I tried so far.
This is a setting stored on the Solution level (.suo file) in Visual studio which by default is turned off. Luckily, it is very easy to turn this feature on, for instance for CLR (.NET Common Language Runtime) exceptions:
In the “Debug” menu, choose “Exceptions” (or Press Ctrl+D, E),
Wait a few moments for the dialog to appear
Put a checkmark in the “Thrown” column for the “Comon Language Runtime Exceptions” row.
The Wiert Corner - irregular stream of stuff 