I have written an article two years ago with the title 'WinForm DualList Component'. In this article I mentioned the desire to extend the DualList component with Drag & Drop support. Finally it's done. Not by extending the original DualList component but by creating an new DualListDragDrop component (reason: cohesion).
Programming Drag & Drop (D&D) between listboxes is quite difficult. It requires at least 60 lines of code for every two listboxes. Therefore not many application support D&D. This component eliminates need of writing the code. You only have to set properties on it. Making it easy to support D&D in your applications.
I have found a solution for a problem which I had for a long time. I was unable to set the ToolboxBitmap attribute for a component using the (type, string) constructor. I found the solution for this problem (using an internal ResFinder class) on www.bobpowell.net. This site has also some other Windows Forms Tips and Tricks. Great!
I have changed the layout of my website this weekend. A friend of my helped me with the design, thanks Loek
I'm not really finished. I still have to translate some pages to Dutch. I also want to add 'comments' to the Blog. Hope to do this soon.
This table gives you an overview of all collections in the System.Collections and System.Collections.Specialized namespaces.
Class |
Key |
Value |
Remarks |
System.Array |
|
? |
Predefined size, used for passing data around. |
ArrayList |
|
Object |
Easy to work with, provides basic collection functionality and can easily be
converted to an Array. |
BitArray |
|
Boolean |
Manages a compact array of bit values, which are represented
as Booleans
|
CollectionBase |
|
? |
Abstract base for building your own collection classes. |
DictionaryBase |
Object |
? |
Abstract base for building your own collection classes using a key-value pair. |
HashTable |
Object |
Object |
Provides high performance access to items in the key-value pair collection, by
a specific key. |
Queue |
|
Object |
Implements the FIFO mechanism. |
ReadOnlyCollectionBase |
|
Object |
Abstract base for building your own read-only collection classes. |
SortedList |
Object (sorted) |
Object |
Provides access to items in the collection by a specific key or an index
(GetByIndex(int)). |
Stack |
|
Object |
Implements the LIFO mechanism. |
Specialized.HybridDictionary
|
Object |
Object |
Uses internally a ListDictionary class when the collection is small, and
switches automatically to a Hashtable class when the collection gets large. |
Specialized.ListDictionary |
Object |
Object |
Is designed to be used for collections with 10 or less items, while the
Hashtable is designed to contain more items. |
Specialized.NameObjectCollectionBase |
String |
? |
Abstract base for building your own collection classes using a key-value pair. |
Specialized.NameValueCollection |
String (sorted) |
String |
NameValueCollection class is the strong type equivalent of the SortedList
class, for the String class. |
Specialized.StringCollection |
|
Object |
Strongly typed ArrayList for the String class. |
Specialized.StringDictionary |
String |
String |
Strongly typed Hashtable for the String class, not sorted. |
Read also Jan Tielens article on the MSDN Belux website.
I have used the EventsHelper class to fire events asynchronical. I came across this class in the TechEd 2003 presentation C# Best Practices from Eric Gunnerson and Juval Löwy. Today I noticed a bug. The FireAsync() method uses the 'Fire and Forget' pattern incorrectly.
The 'Fire and Forget' pattern is used when the return value and returned parameters of the call are not required, and when there is no need to synchronize with the asynchronously executing method. In this case, the caller simply needs to call BeginInvoke, passing any normal and ref parameters, and null for the callback and asyncState.
This has been a commonly used pattern. However, there has been a documentation change in version 1.1 of the .NET Framework that has big ramifications for this technique of making async calls. The documentation now states that EndInvoke must be called for a corresponding BeginInvoke--otherwise Microsoft say they may now, or in the future, leak resources. It appears that no resources are leaked under version 1.0 of the framework; however, with this type of warning in place, it is recommended that a call to EndInvoke be made even if the return values of an async call are not required.
It is relatively straightforward to create a helper class that handles this for you--one example I found here.
public
class AsyncHelper {
 delegatevoid DynamicInvokeShimProc(Delegate d,object[]args);
 static DynamicInvokeShimProc dynamicInvokeShim=new
   DynamicInvokeShimProc(DynamicInvokeShim);
 static AsyncCallback dynamicInvokeDone=new
   AsyncCallback(DynamicInvokeDone);
 publicstaticvoid FireAndForget(Delegate d,paramsobject[]args){
   dynamicInvokeShim.BeginInvoke(d,args,dynamicInvokeDone,null);
 }
 staticvoid DynamicInvokeShim(Delegate d,object[]args){
   d.DynamicInvoke(args);
 }
 staticvoid DynamicInvokeDone(IAsyncResult ar){
   dynamicInvokeShim.EndInvoke(ar);
 }
}
I have written the following DateDiff() function in C#. VB.NET users already had it using the Micrsoft.VisualBasic.dll assembly. Now you can use it without referencing this 'ugly' extra assembly.
using System;
namespace ReflectionIT.System {
 publicenum DateInterval {
   Year,
   Month,
   Weekday,
   Day,
   Hour,
   Minute,
   Second
 }
 publicclass DateTimeUtil {
   publicstaticlong DateDiff(DateInterval interval, DateTime date1, DateTime date2){
     TimeSpan ts=date2-date1;
     switch(interval){
       case DateInterval.Year:
         returndate2.Year -date1.Year;
       case DateInterval.Month:
         return(date2.Month -date1.Month)+(12*(date2.Year -date1.Year));
       case DateInterval.Weekday:
         return Fix(ts.TotalDays)/7;
       case DateInterval.Day:
         return Fix(ts.TotalDays);
       case DateInterval.Hour:
         return Fix(ts.TotalHours);
       case DateInterval.Minute:
         return Fix(ts.TotalMinutes);
       default:
         return Fix(ts.TotalSeconds);
     }
   }
   privatestaticlong Fix(double Number){
     if(Number >=0){
       return(long)Math.Floor(Number);
     }
     return(long)Math.Ceiling(Number);
   }
 }
}
NDoc 1.2 generates class libraries documentation from .NET assemblies and the XML documentation files generated by the C# compiler. NDoc uses add-on documenters to generate documentation in several different formats, including the MSDN-style HTML Help format (.chm), the Visual Studio .NET Help format (HTML Help 2), and MSDN-online style web pages.
This article explains the four steps to take in order to integrate the HTML Help 2 file you generated into Visual Studio.NET.
- Comment the Library using XML documentation tags
- Create HTML Help 2 using NDoc
- Registering the Help File using H2Reg
- Include Help Collection to VSCC
Download DotNetRefCard.pdf
I have created a small quick reference card for Microsoft .NET with some hard to remember details. My printer supports two pages per side and double sided printing. This makes it possible to print the 4 pages on a single sheet which makes it easier to use.
Contents:
- C# String escape sequence
- C# Numeric & Char Literals
- String Formatting
- Standard Numeric Format Strings
- Custom Numeric Format Strings
- Standard DateTime Format Strings
- Custom DateTime Format Strings
- Regular Expressions
I hope you will find it useful.
Any suggestions and feedback for improving this reference card is most welcome. Send your suggestions and feedback to Fons.Sonnemans@reflectionit.nl
I have read that the .NET framework has great features to localize your application. I had to use them recently to create an English, Dutch, French and German "version" of one of my applications. I found out they worked well but it was very time consuming to set all the text properties of all controls for each language. Even worse you have to translate common terms like: OK, Cancel, New, Open, Close, etc. on every form if you want to use the designer. You can, of course, write code to fetch them all from one resource file. But I don't like to write code, especially if you don't have to.
I came up with a solution for this problem, called the LocalizedTextProvider component. This component is actually an extender which, adds a LocalizedText property to a Control or MenuItem. When you add this component to a WinForm it will allow you to set the LocalizedText property ('Misc' category) of all controls on your form. You can select a Key from a predefined list. This list contains all keys from the string resources in the component. I have filled the list using the International Word List from the 'Microsoft Official Guidelines for User Interface Developers and Designers' website.
Example: the LocalizedText property for the Cancel button is set to Microsoft.Cancel
The Text for the Cancel button will automatically be translated to 'Annuleren' for Dutch users, 'Abbrechen' for German users and 'Annuler' for French users. You can test this by setting the CurrentUICulture property of the CurrentThread to a Dutch, German or French CultureInfo.
I have found a great tool on the GotDotNet user samples website
WinChurn allows you to compare two versions of the same managed assembly. This is extremely helpful when tracking changes in your assembly. The tool comes with a help system, as well as some examples to get you started. Optionally, the tool allows you to generate a policy file, however caution is urged when using this feature. While the tool is extremely robust and accurate at detecting public API changes, it cannot detect internal changes. The tool uses Reflection to generate the results.
Assembly Comparison Tool (WinChurn)