DataGridView.Rows.Height property is faulty - by Rob Sherratt

Status : 


Sign in
to vote
ID 782037 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 3/25/2013 8:26:33 AM
Access Restriction Public


Using: Microsoft Visual Studio Express 2012 for Windows Desktop

DataGridView.Rows.Height property is faulty - the property is inoperative

Steps to reproduce:

Private Sub Format_DGV(ByRef MyDGV As Windows.Forms.DataGridView)
    MyDGV.RowTemplate.Height = 180
    For n = 0 To MyDGV.Rows.Count - 1
        MyDGV.Rows(n).Height = 100
    Next n
End Sub

The RowTemplate.Height setting of 180 is applied.
The Rows(n).Height setting of 100 is ignored.


It is impossible to set individual row heights programattically using the DataGridView class.
Sign in to post a comment.
Posted by Rob Sherratt on 4/18/2013 at 12:18 PM
Hi, thanks a lot for looking into this. Yes, MyDGV is bound to a DataTable. When I remove the statements setting MyDGV.Rows(n).Height and use only MyDGV.RowTemplate.Height then all row heights change whenever MyDGV.RowTemplate.Height changes. The individual row height can be changed by the user dragging a particular row boundary in the visible MyDGV instance in the Windows Form. So I find it hard to accept why this behavior is implemented by design (unless it was a design accident). Please note that (i) such a design limitation is not mentioned in the available documentation; (ii) user interactions do allow individual row heights to be changed in a MyDGV bound to a DataTable; (iii) if the restriction was by design, then why is there no error message or exception returned when the function is called?

The processor hang appears to be caused because the calls to set MyDGV.Rows(n).Height take a lot longer to process than other calls to the DGV class. If the behavior is by design then I would expect a quick return after testing for a bound DataTable, which is about 5 processor cycles. It seems to be taking several thousand processor cycles. Why is that?
Posted by Microsoft on 4/18/2013 at 11:24 AM
Thank you for your feedback. The DataGridView issue that you have reported is actually by design. The rows of a data-bound DataGridView use the same template for each row. When the the DataGridView is not data-bound, variable row heights are supported.

Unfortunately, we were unable to reproduce the processor hang. If you continue to experience this issue on a clean machine, please file a seperate bug and attach a project that can reproduce the issue.

Many customers have found it useful to discuss issues like this in the forums ( where Microsoft and other members of the community can recommended ways to achieve the behavior you interested in.

The Windows Forms Product Team
Posted by Microsoft on 4/8/2013 at 11:21 PM
Hi Rob,
Is your DataGridView control databound? We could reproduce the "row Height not applied to DataGridView rows" part only on data bound controls where individual height is overriden by the corresponding template value. We had not seen the application hang. Do you experience the hang if you don't set the template height?
Thank you,
The Windows Forms Product Team
Posted by Rob Sherratt on 4/8/2013 at 3:56 AM
I have done further testing and the bug is more serious. It can cause a processor hang - unresponsive user application. Therefore in my application I have removed all attempts to programmatically set DataGridView.Rows(n).Height. Please could Microsoft let me know if you have validated this as a Bug? Thanks.
Posted by Rob Sherratt on 4/8/2013 at 3:53 AM
Posted by Microsoft on 3/27/2013 at 1:08 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 3/25/2013 at 8:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(