One very common requirement is for the number of days elapsed since a particular Date and Time. In C# this can be accomplished through the use of the TimeSpan class.
The easiest way to create a TimeSpan is like this:
TimeSpan tsMySpan = DateTime.Now.Subtract( dtCompareTime );
// The number of days elapsed can be accessed like this:
// tsMySpan.Days
One of the nicest features in ASP.NET is its out-of-box support for relative paths in hyper links and other controls. This is very important for developers whose code resides within the root of their testing environment but within a sub-directory of the production server.
Whereas one would have to carefully program things like image links to point at “/applicationbasepath/images/”, in ASP.NET we can simply use “~/images”. Genious!
When writing custom code, however, the work isn’t done for us automatically. We have to pass our URL to a server-side function in order to convert the “~/” into a base path usable by our visitors.
There are two ways of doing this:
If we are programming a page template or a server control, we can use the ResolveUrl() function provided by our environment context.
string resolvedUrl = ResolveUrl( “~/index.php” );
On AlwaysGetBetter.com, “~/index.php” would resolve to http://www.alwaysgetbetter.com/blog/index.php. On another site, it might resolve to the root such as http://www.abetterblog.com/index.php. Programming this way makes our solution more portable.
Sometimes we need to use relative paths from outside the context of a web page. For example, if we were to make a change in our Global.asx file, the program code we use may not be considered to be within a web page scope.
Fortunately, .NET provides us with the static helper class VirtualPathUtility.
string redirUrl = VirtualPathUtility.ToAbsolute(“~/redirPage.aspx”);
Response.Redirect( redirUrl );
The project I am currently working on has several dozen different types of Form classes, each of which is accessible from a common menu strip. Rather than repeatedly instantiating each of the forms from the menu item handlers, I wanted to funnel the request to a single function.
The problem is: How do you instantiate a form when the type is unknown?
The code snippet is:
CreateForm( typeof(CustomFormType) );
Form CreateForm( Type formType )
{
return (Form)Activator.CreateInstance(formType);
}
When working with a Windows GUI, it may seem unclear whether to use Form.Close() or Form.Dispose() to get rid of a dialog at runtime.
Form.Close() removes the dialog from sight and calls the Closing() and Closed() methods. You can still access the form and bring it back later on.
Form.Dispose() destroys the dialog and frees its resources back to the operating system. It does not call the form’s Closing() and Closed() methods. Once disposed, you may not recall a form.
Which to use? If you have no logic in the form’s close methods and don’t intend to re-use the form, go with Dispose(). Otherwise, go with Close(). Some programmers aren’t sure which to use, and they use both – Close() then Dispose()!