Microsoft has released a free LibCheck tool that allows you to compare two versions of an assembly, and determine the differences. The tool reports the differences as a combination of 'removed' and 'added' APIs. The tool is limited to looking only at APIs (i.e, it can't check for behavioral changes), and only compares public differences, or changes which are deemed to be 'breaking'. The tool can be used to quickly determine what has changed between one version of your assembly and another, and can help ensure that you won't introduce any breaking changes to clients of your assembly. Instructions and intended use of the tool are described in the 'libcheck tool specification' document with the zip file.
This was a feature I always was missing. VB6 had this, VS.NET didn't. Thanks MS.
I received a mail today from Rolf Gasber asking me whether I could help him with a VB.NET version of the AsyncHelper which I used in an earlier post. Here it is:
Public
Class
AsyncHelper
Private
Delegate
Sub
DynamicInvokeShimProc(
ByVal
d
As
[Delegate], _
ByVal
args()
As
Object
)
Private
Shared
_dynamicInvokeShim
As
_
New
DynamicInvokeShimProc(
AddressOf
DynamicInvokeShim)
Private
Shared
_dynamicInvokeDone
As
_
New
AsyncCallback(
AddressOf
DynamicInvokeDone)
Public
Shared
Sub
FireAndForget(
ByVal
d
As
[Delegate], _
ByVal
ParamArray
args()
As
Object
)
_dynamicInvokeShim.BeginInvoke(d,
args,
AddressOf _
DynamicInvokeDone,
Nothing
)
End
Sub
Private
Shared
Sub
DynamicInvokeShim(
ByVal
d
As
[Delegate], _
ByVal
args()
As
Object
)
d.DynamicInvoke(args)
End
Sub
Private
Shared
Sub
DynamicInvokeDone(
ByVal
ar
As
IAsyncResult)
_dynamicInvokeShim.EndInvoke(ar)
End
Sub
End
Class
For a long time I thought that I only had to set the Cursor.Current to a WaitCursor before a long running operation, the .NET runtime would reset it back to the Default cursor. Turns out that this is only true when the mouse is moved. Bummer.
Cursor.Current = Cursors.WaitCursor;
The solution for this problem is very easy. I created a helper class called WaitCursor which set the Cursor.Current and restores it to the original value when it it disposed.
public
sealed
class WaitCursor : IDisposable {        
 private Cursor _prev;
 public WaitCursor(){
   _prev= Cursor.Current;
   Cursor.Current = Cursors.WaitCursor;
 }
 publicvoid Dispose(){
   Cursor.Current =_prev;
 }
}
I create the instance of the WairCursor class inside a using statement. This will automatically call the Dispose() method when it goes out of scope.
Microsoft has invented a new name Micro-ISV, which are software companies that are comprised of only one person. So, I'm a Micro-ISV. Planning to launch my product this year. I hope to succeed.
There is a difference in disposing Modal and Non-Modal forms. In a training I gave last week I noticed that even experienced developers didn't know that Modal Dialogs don't dispose automatically, Non-Modal do.
private
void
buttonShowNonModalForm
(
object
sender
, System.EventArgs e){
 new TestForm().Show();
}
privatevoidbuttonShowModalDialog(objectsender, System.EventArgs e){
 new Form2().ShowDialog();
}
The solution to this problem is very simple by creating the Form instance within a using block. This will dispose the Form when it is closed.
private
void
buttonShowModalDialog
(
object
sender
, System.EventArgs e){
 using(TestForm f =new TestForm()){
   f.ShowDialog();
 }
}
An alternative solution uses a try/finnaly. Personally I prefer the previous, it is easier to read and write.
look.
The C# code editor in Visual Studio.NET 2003 does not handle whitespaces automatically like the VB.NET code editor does. This Add-In solves this problem by adding the 'Handle WhiteSpace' menu option to the Visual Studio.NET 2003 Tools menu. This option formats the C# code of the active code editor. This includes:
-
Space before: method declaration parentheses, method call parentheses, statement parentheses, braces and brackets
-
Space after: comma and semicolon
-
Space around: operators
-
Double space
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!
