My wishes...
My Windows Forms wishes:
1) Fixes to the existing reported bugs (we'll see about framework 1.1; many arn't fixed in the "final beta")
2) Faster GDI+, particularly DrawImage with metafiles. Not really a Winforms problem, but winforms only provides hooks to GDI+ functionality. A workaround for me would be to add a DrawMetafile to ControlPaint, optimized for speed. A full GDI wrapper that doesn't require calling Graphics.GetHDC would be nice. Also, fixing the bugs in DrawString would make my life a lot easier.
3) A roadmap for the future of Winforms would be nice. There are rumours that both GDI+ and Winforms are temporary technologies that are intended to be replaced in the future; my business has already bet heavily on Winforms, and if we're going to get screwed we'd at least like some advance notice. Better yet, confirm that Winforms is here to stay so I can sleep at night!
4) Provide Winforms library source code; its very annoying to work around framework issues when I have to make trial and error guesses at what is going on behind the scenes. Case in point, killing that annoying autoscroll reset to upper left corner on a scrollable control recieving focus. Took me about 8 hours to work around it; the simple override of WndProc to ignore WM_SETFOCUS seemed OK at first, but screwed up the setting of the active control property. If I had access to source, it would have taken me all of 5 minutes to find the proper workaround (setting the scroll state to manual during the WM_SETFOCUS handler)-- though I still had to use reflection to access the private SetScrollState method. Which brings me to point #5...
5) Avoid using "sealed" or "private". So many problems could be solved if I could just, say, derive from MenuItem, or call SetScrollState when I need to.
6) TreeView control really needs multiple selection
Hope I'm not being greedy... then again, my company pays 40K+/yr for MSDN universal for our developers. Not sure I'm being greedy, in that light.
Have a nice day,
Robert W. Grubbs
1. Please let us which bugs are on the top of your list.
2. This is a good idea.
3. Although we don't have a formal, public roadmap in place, I can tell you that you've made a very safe bet. Windows Forms are here to stay. We are investing heavily in these classes, their controls, no-touch deployment technology, etc. We are very, very serious about smart client application development. Look out for some very cool enhancements and complements to Windows Forms coming out in future releases."
4. This is something we are considering. In order for this to be effective, we'd have to release the exact version of the sources that the .NET Framework is built with. It would require 3+ months to scrub our source tree to get it to the point of being publicly consuable. And then of course there's all the legal issues.
5. While not always the case, classes and members are marked sealed or private because they weren't designed with inheritance in mind. Onthe flipside, it is not a breaking change for us to open up sealed types or private members to allow subclassing.
BTW - MenuItem isn't sealed. You can inherit from it. As many people have done to add image support.
What are the top types and methods you'd like us to open up?
6. This is a hard problem because the underlying ComCtl TreeView, which the Windows Forms TreeView is a wrapper around, doesn't support multi select. Its not terribly hard to code this functionality yourself, hooking mouse down and up messages and maintaining you're own selected items collection, but things like accesibility and owner draw will be broken.
- mike
Sure, here's my C# code; I put this override into all of my forms and controls now.
/// <summary>
/// Override this virtual method and stop DOTNET getting hold of
/// the WM_SETFOCUS notification. This prevents DOTNET resetting the
/// AutoScrollPosition when this control receievs the focus.
/// </summary>
/// <param name="m">The WIN32 message</param>
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case 0x0007:
// Trap WM_SETFOCUS message
//Ok, this is annoying. Simply ignoring the focus event causes problems with
//the active control and command routing, so instead we'll supress the scroll
//state bits that control autoscrolling. Just to make life more fun and
//enjoyable, Microsoft made the damned thing Private, so we'll use
//reflection to bypass the protection
if(Parent is ScrollableControl)
{
Type scrollableControlType=typeof(ScrollableControl);
System.Reflection.MethodInfo sssInfo=scrollableControlType.GetMethod("SetScrollState",
System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
object [] clearautoparms={1,false};
object [] setautoparms={1,true};
sssInfo.Invoke(Parent,System.Reflection.BindingFlags.NonPublic,null,clearautoparms,null);
base.WndProc(ref m);
sssInfo.Invoke(Parent,System.Reflection.BindingFlags.NonPublic,null,setautoparms,null);
}
return;
}
// Pass all other message to base
base.WndProc(ref m);
}
