Now, the derived classes are already IDisposable from DriverWrapper, but if they only hold delegates, which aren't IDisposable themselves, is there any need to override Dispose(bool) in these? I think not, but I'm no expert on C#.
No. As you say they already implement IDisposable through inheritance, and if they don't specify any expensive resources that you need to clean up before the GC gets around to collecting your object, then you don't need to specify additional dispose behaviour.
Would Model have to be IDisposable?
If you want it to be cleaned up before the GC notices it, then yes. And since it's wrapping a class which you already decided should be disposable, then so should the wrapper, and its Dispose should call the driver's Dispose. These two sets of classes seem so closely related that I wonder if you need to have two sets of classes at all, though.
If not, would ModelA-C need to override Dispose even if they have no further data?
No (see first point).
You need to implement IDisposable if you are allocating resources that you want to have guaranteed return at a known time on, but you don't have sufficient control over the context to explicitly call a close method to release them. It's also convenient to implement it when you do have that context, but you want to use the class in a using(x) block, or if you might forget you're supposed to call a close method (as Dispose will get called in GC cleanup too).
You don't need to implement it if the resources you're allocating in a class are so small and unlimited in number available that you don't mind if they don't get collected for a while. That applies to most managed objects, unless they're really huge and there's a memory impact (though the GC will notice this and run a collection sooner than otherwise), and to unmanaged resources that aren't limited (e.g. non-locking file handles, sockets, bitmap handles etc). The other case is that if you know you need a resource for the entire lifetime of your process you don't need to implement IDisposable either, as the one time that finalisers are guaranteed to be called is in process shutdown (assuming it's a clean shutdown), and even if it doesn't get run, the OS will clean up after you.
In my winforms project I have a PropertyGrid which can be changed at runtime. I need to capture the double mouse click events to open a dialog window where you entered the code of the event. Can anyone help me?
I am testing various methods and events of the PropertyGrid class but could not capture the double click an event, nor the automatic generation of the event name using the method CreateUniqueMethodName.
I need to intercept this action toopen my dialogue will be informed where the event code.
Can you be more specific?
It would appear that the documentation is not very clear. Since almost everything within the property grid is a control, they are all consuming the mouse clicks. I found the only place where it responds is by clicking in the small space between the main property table and the description below it.