Selfelected

Operation cannot be performed on a shared row

On http://msdn.microsoft.com/en-us/library/ha5xt0d9.aspx one finds some good advises on how to use Dotnet’s DataGridView with large data.  Amongst others one is told to care about Shared Row for data reuse.

A solution of mine was to populate the grid with objects of my own creation and then call SetValues; but when I refactored my solution and put the calls in the “right place” I got an InvalidOperationException exception with the message “Operation cannot be performed on a shared row.”

The SetValues call was made from a class that inherited DataGridViewRow.  The solution was to move the call out of the class (to my class that inherited the UserControl).

This article might hopefully help someone in the future with the same problem.

Update:

6.5 years later and no comment shows that I probably was alone with this problem. Or that my site doesn’t rate high enough.

Do inherit from your controls

It is very easy to inherit from your controls in dotnet/VS.Net.  Just add a class and let it inherit from any Control.  That’s it!

To use it either reload the project (possibly the IDE) and drag it from the toolbox to the left.  This is only possible in VSNet2005 I think.  Or do as I, open the myclass.designer.cs file and edit the declaration in the bottom.  Recompile and edit the compiling error at the instantiation.  That’s it!

VSNet2005 does not interfere with your hacking of the .designer.cs file.  Unless you are building for WinCE that is.

Why inherit then?
There is really no need to do it all the time.
But keep it in your head so the moment you need some common functionality in your form you can put it in BaseForm.

Update:

Always inherit from the grid control.  There is a very good reason regarding type safety and differentiation of data and view for this.  I hope to write about this in a not to far future.

Update:

Hacking designer.cs in VSNet2008 for WindowsMobile(6.1) works alright but you will probably get an “InvalidCastException” and a pointer to  something like
((System.ComponentModel.ISupportInitialize)(this._myControl)).BeginInit();
The error is explained here and the solution is to just comment/delete the rows
    ((System.ComponentModel.ISupportInitialize)(this._myControl)).BeginInit();
and
    ((System.ComponentModel.ISupportInitialize)(this._myControl)).EndInit();

Hungarian notation

Hungarian notation was, and is, a good idea.
Unfortunately prefixing the variable with the type has today become suffixing:
sCustomerNumber -> customerNumber
sPassword -> passwordString
nMax -> maxValue

What is the reason for this? Is it harder to read nCustomer than customerNumber? I don’t think so. Instead more space/characters are used for communicating the same information.

Think of the ever present”customer number”. Written as customerNumber at first look it looks like a number, a series of figures. Now we know that a customer number has dashes and letters in them so it is really a string, like customerNumberString. Written with hungarian notation it is sCustomerNumber and clearly a string.

Now I have come to use PascalCasing or camelCasing like everyone else but only for strongly typed languages like C# which can by itself differ between strings and integers. For loosely typed languages like Javascript or PHP i still use hungarian notation.

My rules for hungarian notation in Javascript is like:
sXXX for strings
nXXS for integers (bytes, long integers, whatever)
fXXX for floats (doubles, decimal, whatever)
oXXX for many objects (oUser, oBoat, whatever)
myclassXXX for other object (userProtagonist, accountMain, accMain, whatever)
rsXXX for record sets
bXXX for booleans
anXXX for arrays of integers
asXXX for arrays of strings
cXXX for constants and characters – I am not totally happy with this

There has been no reason to make it more complex than that.