Naming conventions on auto-generated bound objects

[cjard]

CustomerIDDataGridViewTextBoxColumn

Don't ask me why MS thought this was a good idea. If you do it by column index it's a lot easier..

Its a side effect of autogeneration within typed datasets and associated hierarchies..

The DataGridView has a column that is typed to be filled with textboxes. This requires a custom component called a DataGridViewTextBoxColumn. It is one of many possible types. Also, there may be more than one of these instances in a datagrid's columns so they are distincted by the name of the column.. In this case CustomerIDDataGridViewTextBoxColumn related exclusively to the customer ID column and has strong typing affording it facilities of a DGVTBColumn that are not present in other types of column.

As a quick example you will notice that DataGridViewComboBoxColumn as an Autocomplete property that DGVTBC lacks. Presumably every Combo cell within such a DGVComboColumn would autocomplete if this property were set on the parent.

The typing notion here is that Columns(0) may well be a ComboBoxColumn, but without a cast, those features are not seen.

Of course, if you are setting property that is present in a DataGridViewXXXColumn's superclass, then Columns(0) will do fine

 

[vis781]

Its a side effect of autogeneration within typed datasets and associated hierarchies..

Not sure what you mean there. The name of a component is determined by the INameCreationService, the class name is used and then a search is made up through the hierachy to find the next appropriate index. After that a name has been declared as simply as it can be done in the designer properties window. There is no real reason for MS to have just appended the field name retrieved from the database. That was the point i was trying to make. Having the type name of the component in the name property of a generated datacolumn seems a bit overkill, and serves no useful purpose from what i can see.

 

[cjard]

Not sure what you mean there. The name of a component is determined by the INameCreationService, the class name is used and then a search is made up through the hierachy to find the next appropriate index. After that a name has been declared as simply as it can be done in the designer properties window. There is no real reason for MS to have just appended the field name retrieved from the database. That was the point i was trying to make. Having the type name of the component in the name property of a generated datacolumn seems a bit overkill, and serves no useful purpose from what i can see.

oh, i disagree. the two part name:


PreferredShippingModeDataGridViewComboBoxColumn
CustomerGenderDataGridViewComboBoxColumn

here lets us tell that both these are columns of our datagridview, they hold combobox types and so we can set combo specific properties on them. Additionally, because our datagrid has more than one column that is a combo type, they are named according to the semantic the user has chosen. We may want to make the shipping mode combo perform an auto complete if there are 20 shipping modes, but the male/female choice means autocomplete might not be necessary for such a small list. hence we can:

PreferredShippingModeDataGridViewComboBoxColumn.AutoComplete = true
CustomerGenderDataGridViewComboBoxColumn.AutoComplete = false

rather than having to guess or calculate which column index to which we wish to refer.


I'm puzzled about two lines of your post:

>There is no real reason for MS to have just appended the field name retrieved from the database
>Having the type name of the component in the name property of a generated datacolumn seems a bit overkill


I'm not sure which you find extraneous.. taking these statements alternately would you prefer these columns to be called:

(preserving field name, regressing type through hierarchy)
PreferredShippingModeDataGridViewComboBoxColumn
PreferredShippingModeDataGridViewColumn
PreferredShippingModeDataGridViewBand
PreferredShippingModeDataGridViewElement
PreferredShippingModeObject

(preserving type through regressing, dropping friendly name)
DataGridViewComboBoxColumn1
DataGridViewColumn1
DataGridViewBand1
DataGridViewElement1
Object1

(dropping both type name and friendly name)
1

(just using collections and casting)
DirectCast(...Columns("PreferredShippingMode"), DataGridViewComboBoxColumn)
DirectCast(...Columns(0), DataGridViewComboBoxColumn)


Personally, i'd take the typed property route of PreferredShippingModeDataGridViewComboBoxColumn over DirectCast(...Columns("PreferredShippingMode"), DataGridViewComboBoxColumn) any day


I must admit i normally prefix the type rather than suffix it:

cboPreferredShippingMode
chkAllowSaturdayDelivery

but some mention of both type and name is made in my variables declarations. Do you prefer to just use collection indexes and casting?

 

[vis781]

Moved this to the debateclub so it doesn't go way of the topic of ckeezer's thread.

No, i'm all for naming conventions. It's just i don't see why MS thought it would be a good idea to add the name of the field and then the name of the type..

Field Name : Id

TypeName : DataGridViewTextboxColumn

to come up with a rather large name : IdDataGridViewTextBoxColumn.

As i say it seems a bit much, the type name in there can serve no useful purpose. If you need the type then you can get it with GetType. The only time i can see that you would use the typename in that manner is to strip out the field name and use a TypeDescriptor to get an object that points to the column. But if you can use GetType then why bother. In a bound datagridview the only part of the name that i would be interested in is the name that matches the name of the field in the database.

DataGridvew.Columns("Id")

Is far better than

DataGridView.Columns("IdDataGridViewTextBoxColumn")

I mean look at all that extra typing!!

 

[cjard]

I'm starting to understand your complaint, I just never envisaged doing it the generic way of:
DataGridView.Columns("IDDataGridViewTextBoxColumn")
because i try to use the type specific stuff wherever possible as i find the DirectCast(obj, type) syntax in vb to be ugly, ungainly and a nuisance to type. I do feel however, that my abhorrence for casting in vb has a beneficial overall effect, as I try harder to find already-typed accessors rather than clutter my code with casts

On a form that has a datagridview where the columns are set at design time, i just say in the form code:
Me.IDDataGridViewTextBoxColumn.Whatever = blah


That's not to say that the first way is wrong; indeed it is more correct than the second because it is a datagridview that possesses columns, not a form


Let's examine the example I've just pulled out of one of my forms:

[SIZE=2][COLOR=#008000]'DataGridViewTextBoxColumn1[/COLOR][/SIZE]
[SIZE=2][COLOR=#008000]'[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].DataGridViewTextBoxColumn1.DataPropertyName = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].DataGridViewTextBoxColumn1.HeaderText = [/SIZE][SIZE=2][COLOR=#800000]"Paymt Ref"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].DataGridViewTextBoxColumn1.Name = [/SIZE][SIZE=2][COLOR=#800000]"DataGridViewTextBoxColumn1"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].DataGridViewTextBoxColumn1.Width = 81[/SIZE]

Unhelpfully, this form's columns are just named 1 2 3 4. I tried making another and got the same result, yet some of my forms have columns named according to the field name in the database. Confusing but I dont think it will invalidate the point.

I wholly support your notion that, if the item is to be part of a collection, adding the typename to the indexing-name is superfluous. Hence i'd like to see the code generated thus:

[SIZE=2][SIZE=2][COLOR=#008000]'DataGridViewTextBoxColumn1[/COLOR][/SIZE]
[SIZE=2][COLOR=#008000]'[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.DataPropertyName = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.HeaderText = [/SIZE][SIZE=2][COLOR=#800000]"Paymt Ref"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.Name = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.Width = 81[/SIZE]
[/SIZE]

I have no problem with the variable being named as Source_ColumnTypeName, but for the .Name property to be set to the same thing does indeed make things an unnecessary headache for accessing a collection, especially since it cannot be autocompleted

As for why it's done this way, i guess you could say that .Name has to be set to the same as whatever the variable name is because its the only way to ensure uniqueness. Adding paymentref column twice, under the "i'd like to see" convention may generate this:

[SIZE=2]
[SIZE=2][SIZE=2][SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.DataPropertyName = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.HeaderText = [/SIZE][SIZE=2][COLOR=#800000]"Paymt Ref"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.Name = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn.Width = 81[/SIZE]
 
 
 
[SIZE=2][SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn2.DataPropertyName = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn2.HeaderText = [/SIZE][SIZE=2][COLOR=#800000]"Paymt Ref"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn2.Name = [/SIZE][SIZE=2][COLOR=#800000]"PAYMENT_REF2"[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]Me[/COLOR][/SIZE][SIZE=2].[COLOR=#800000]PAYMENT_REF[/COLOR]DataGridViewTextBoxColumn2.Width = 81[/SIZE]
 
[/SIZE][/SIZE][/SIZE][/SIZE]

The problem would be the extra logic required to assume a .Name of "PAYMENT_REF2"