Dreaming away.

Dreaming away.

• Kartit

  Excellent suggestions. Some comments:
  
  1. A DataGrid that we don't have to hack the bejezus out of to customize the interface. Don't get me wrong, I think the DataGrid is great for databinding, etc, but have you ever looked at code for a ComboBox column style  The amount of work required to customize the datagrid is extraodinary
  
  >> I couldn't agree more. Man, is it a pain to customize the DataGrid control. 
  
   3. Read Only -- Please, make ReadOnly a property of Control. Everytime I hit a control that doesn't implement ReadOnly it makes me mad. In my humble opinion, Enabled and ReadOnly should be at the same level in the inheritance heirarchy. 
  
  >> Again, I agree. Every control should have the capability of being read-only. 
  
  5. Better support for Asynch with winforms/controls. It would be ideal if I could just use any thread to work with gui controls, but I understand it might not be possible. At least make the Invoke process a little cleaner. I think the complexity of code to get control back to the main thread is a little out of proportion. It is a complex task and very prone to error.
  
  >> I'm not sure I'm seeing this one. What should they do to improve Invoke  Seems pretty clear to me. Maybe I'm just used to it
  
  7. (VS.NET) Give us the ability to drag a control from a project's references directly onto the designer. The toolbox annoys me -- I know the assembly and the class I want to drag on to the form. Let me do it, please. 
  
  >>Man, every time I create a control and want to test it and have to wait forever to deal with the Customize Toolbox dialog box, I want to scream. This is a MUST.
  
  I like all the rest as well, but one more we're missing: the ability to use the Data toolbox components, but not have to place a separate Connection object on each form. You should be able to drag from the toolbox onto the Solution Explorer, create a class that has the correct properties set, and so on. In addition, we should be able to modify the template for the class that creates typed datasets, and provide our own if we want.
  
  Anyway, great list! 
  

• Narcomancer

  Hmm. I have to agree... though I would not expect the designer to come within 20% of the VB6 form designer's performance.
  
  Why  Let's face it. VB was never a true language until VB.net. The designer was quick and efficient, but the programs it created were sub-par. It's probably just the cynic in me, but I could never justify chalking it up to more than a quaint drawing program. :)
  
  VB.net, C#, and (in VS.net 2003) Managed C++ all write good, clean .NET Windows Forms code through the designer. These are no longer toy applications, but rather, full blown Windows apps written with real industry standard languages.
  
  However, I have found VS.net 2002 to slow to a crawl when I have an extended number of controls on any given form. While the number of controls I'm utilizing would normally be a sign of poor design, I assure you that they are every single one is necessary. Hopefully we will see a performance increase with VS.net 2003 and Forms Designer control arrays.
  
  While at an Academic Alliance VS.net 2003 launch, I was told Forms Designer control arrays have returned to VB.net. Is this true for C# and MC++ as well  (Microsoft guys  :) )
  
  Looking forward to more .NET,
  
  .steve
  
  PS: All kidding aside, I know many enterprise-level applications have been written in VB6. But I stand by my sentiments that doing such things is a bad idea. :)
  

• wd

  Ken,
  
  Thanks for the feedback.  
  
  As far as the Invoke thing goes, here is what I picture...  Instead of declaring a delegate, instantiating the delegate, and then calling invoke on the delegate with an object array of parameters, etc all you would do is something like this:
  this.JoinMainThread()
  and then call the method you wanted originally.
  
  Basically, we had a bunch of controls that were calling web services synchronously.  We recently switched them all to call the web services asynchronously -- all the code and delegates needed just to get back to the main thread seemed a bit much and problematic.  It might be that I'm not used to it yet.
  
  As a side note, it would be nice if controls would throw and exception if you are calling them from the wrong thread -- currently you just get fairly random behavior.
  
  

• The_Drewster

  just wanted to say amen on # 3.  Makes it a pain when you want to say, not let them change any fields on your data entry form and you have to loop through the controls and first check to see if they're a textbox and if they are set it to readonly and if it's not set it to enabled equals false, etc...and yes, it would be excellent to have a combobox that is readonly!
  

• Daniel Bachler

  got to see 2.0 at the MVP Summit and I absolutely agree.  You guys are all on the right track to making it totally freakin' sweet!!!  :p  Keep up the excellent work!
  

• wfsCA

  I like both ideas. Especially the "throw an exception when called from the wrong thread" thing.
  
  Funny, I've run across WinForms developers who have used the tool for a long time who had no concept about the threading issue. Very weird, and it ought not be that way. If it's THAT important, it should be very hard to do it the wrong way!
  

• Omar80

  Ok, so it's time to make the requests now:
  
  #3: If you're going to put in ReadOnly on DateTimePicker (see my earily comments about what needs to be fixed on it) and the Combo, in read only mode, both the Combo and DateTimePicker should hide the drop down arrow.
  
  And if you do nothing else for V2, please please please (x1000) speed up the WinForms designer. It's truely hidieous. I would tell your developers to go into a corner and until the speed is within 20% of VB6's form designer, they're not allowed out.
  
  10 seconds for a simple form with a grid and a few other controls (most notably, tab controls slow things down the most) is rediculous, and I'm routinely running into forms that take 45 seconds to open in the designer (and take < 2 seconds to load at runtime!)
  

• sParc134758

  Thanks -- good to hear that we're not the only ones who think so! <G>
  

• lisa52

  Thanks Mike.
  
  3.  ComboBox for one does not have a read-only property.  So, to lock it from user changes, you have to disable it -- This means they can't select/copy/paste values from the control.  I just wish it was a little more consistent.
  
  6. ComboBox again... Here is an example of wacky behavior: With an unbound ComboBox control, if you set the text of the combo box to something _not_ in its item list _before_ the combo is visible it works fine and uses the value you set.  With a bound control, when the control loads, it seems to reset its selected item to the first in the data source.  (Its a little hard to follow.  I can send sample code if you are interested.)  It looks like a bug in the load event of the ComboBox, in my opinion.
  
  Quick sample:
  
              DataTable dt = new DataTable("Test");
              dt.Columns.Add("Name");
              dt.Rows.Add(new object[] {"Test1"});
              dt.Rows.Add(new object[] {"Test2"});
  
              Form1 f = new Form1();
              f.boundCombo.DataSource = dt;
              f.boundCombo.DisplayMember = "Name";
  
              f.unboundCombo.Items.Add("Test1");
              f.unboundCombo.Items.Add("Test2");
  
              f.unboundCombo.Text = "Not in list";  // works fine.
              f.boundCombo.Text = "Not in list";  // doesn't work.
  
              f.Show();
              
              // bound combo text can only be set after the combo is visible!
              //f.boundCombo.Text = "Not in list";
  
  

• Jordi73757

  Regarding Custom Datagrid columns,
  
  I remember seeing a DataGridComboBoxColumn sample which was working very nice except for 1 simple thing.
  
  Why cant i add it to the DataGrid Wizard where it makes me select either textbox or checkbox columns 
  
  Customizing VS.NET to add our own design tools is the BEST FEATURE you guys could think about, i couldnt live without that now that i've tasted it.
  
  
  

• pxgator

  First off, the next version of VS and the .NET Framework (7.1 and 1.1 respectively), don't contain many new features.  Especially for the .NET Framework.  1.1 is essentially a bug fix release.  Although, we did manage to shoehorn in a few features (FolderBrowser anyone  :))
  
  That said, we're now hard at work on the next version of the product and this is <b>the</b> time to give us your feature requests, before things are locked down to the point we can no longer make changes.
  
  Regarding your wishes: 
  
  1. Everyone, sorry <b>Everyone</b>, wants a data grid that is more easily extensible than the current version shipped with Windows Forms.  I can't officially say more than "we hear you"  ;)
  
  3. Interesting idea.  I understand your complaint, but which controls do you find don't have read only, but you really need it   Conrete usage examples would be helpful
  
  4. If you see an out of date KB, please let MSDN know, they are very good at responding to broken content and updating it.
  
  5. Async is actually a pretty big deal, especially in the era of lengthy webs service calls.  UI that hangs on a WS call, or equivilent (*cough* Outlook *cough*) is a poor user experience.  There's definitely a place for easier, more seamless async in a future Windows Forms release.
  
  6. Wacky differences   Do tell.
  
  7. Yeah, this works in the ASP.NET designer and not in ours.  Good idea.
  
   - mike
  

• SD Diver

  I'm actually going to go a bit farther than Mike here.  I think you'll be *very* happy with what we're working on for Version 2.0...we should be able to realize most of these "dreams" ;)
  

• Youcef

  <*sigh*> I know, that was such a shenanigan...
  

• zicovn

  yup...unfortunately though the computer that Mark Boulter was using wasn't really working so we didn't actually get to SEE any of it, but it all sounded great  ;)  I guess I'll just have to wait for the first round of bits.
  
• Dreaming away.