problem with "Object reference not set to an instance of an object"

  • Thread starter Thread starter Chris
  • Start date Start date
No scott I am not talking about that.

I had the expirience that in ASPNET this was happening

Select MyField from X.

In Windowsform I "had to" (must) use this when using a non strongly typed
datatable

dim myfield as string = thedatatable.rows(0)("MyField")

in ASPX i could use it as
dim myfield as string = thedatatable.rows(0)("mYfIELD")

You understand that I was confused about that. It was in 1.1

Cor
 
Cor, this is exactly what I'm describing. I'm not sure why you say you
aren't talking about that.

In your two examples:
dim myfield as string = thedatatable.rows(0)("MyField")

in ASPX i could use it as
dim myfield as string = thedatatable.rows(0)("mYfIELD")
Click to expand...

You are passing a string into an indexed property. As you yourself point
out, one example is passing it to a DIFFERENT TYPE than the other. It is
the TYPE that is or isn't enforcing the case-sensitivity, not the VB.NET
language.

You see the difference? There's nothing about your example that would make
the statement: " it's not case sensitive (VB.net)" a true one.

-Scott
 
Scott,

What different type, they are both of the type object?
(it are DataRow Items) which have an index in the column object.

It seems that ASPNET was doing an extra job by setting those columnnames to
upper or lower case, probably as they are more bound to SQL, where the
expressions are as well not case sensitive.

Cor
 
It has nothing to do with ASP.NET, since ASP.NET is nothing but a
client/server architecture that is not language dependant.

The two types you talk about are DataSet and Strongly-Typed DataSet, not
just the plain "object" type.

It's clear that Microsoft's standard DataSet requires the column name passed
as an index to the DataRow exactly as the real column name is written. But
a Strongly-Typed DataSet is a different class that inherits from DataSet,
but implements the default property of the DataRow differently. In any
case, we are talking about how the OBJECT expects the parameter, not how
VB.NET (the LANGUAGE) expects it.

Honestly Cor, I know you are smarter than your replies in this particular
topic would lead someone to believe. This is really quite simple.

"If "SCOTT" = "scott" Then" is processed by the CLR, there is no other
object involved here but the String type, so the decision as to whether the
expression is true or not is completely based on the language, which is
VB.NET, which will always return FALSE.

Your entire argument is not based on how the language would treat different
strings, you keep talking about how string data would be accepted by a type
and a type is not the same thing as a language.
 
Scott M. said:
"If "SCOTT" = "scott" Then" is processed by the CLR, there is no other
object involved here but the String type, so the decision as to whether
the expression is true or not is completely based on the language, which
is VB.NET, which will always return FALSE.
Click to expand...

This depends on 'Option Compare {Text, Binary}'.
 
Scott,

My message has nothing to do with the behaviour of the string.

What I am writting about is use of the string as indexer in a not strongly
typed dataset.

I was once supprised that it seems that it seems that they have made in
ASPNET somewhere an unexpected inbuild string.ToUppercase (or string to
Lowercase) around AdoNet.

That is all, with that not denying what you wrote, only that there can
sometimes be suprisses.

:-)

Cor

Scott M. said:
True, but that takes us in a different direction from the particulars at
hand.
Click to expand...
 
I hear what you are saying Cor, but you are saying this in a very
mis-leading (and IMHO) incorrect way:

I have been talking all along about the VB.NET language, not how a string
can be passed to a property or method. I have been doing this because of
Chris's first comment about VB.NET not being case-sensitive.




Cor Ligthert said:
Scott,

My message has nothing to do with the behaviour of the string.

What I am writting about is use of the string as indexer in a not strongly
typed dataset.

I was once supprised that it seems that it seems that they have made in
ASPNET somewhere an unexpected inbuild string.ToUppercase (or string to
Lowercase) around AdoNet.

That is all, with that not denying what you wrote, only that there can
sometimes be suprisses.

:-)

Cor
Click to expand...
 
I think the way as you are telling it can be more misleading.

Telling that something has always the same behaviour, while there are
exceptions, can lead that somebody can search for a problem weeks. To
prevent that was the only meaning of my message.

You can answer this message but I don't answer that anymore. Not to be rude,
however because there is enough written and we both will not add new things
anymore

Cor
 
But, there aren't exceptions and that is my point. The language never
changes the way it handles strings, objects may, but the language doesn't.
To not separate the two things is right up there with those who believe the
Framework is the language and vice versa.
 
Scott,

I told not to write anymore, however maybe does this helps in this
communication.

Maybe we are talking about different things, have a look at this tested code
and than to the word Dataset inside the session.

That it has different cases is my point, this is the same for Net.Data names
here while it is AFAIK impossible for WindowsForms to use then different
cases.

\\\\
'To test does this need a DataGrid on the page
Partial Class _Default
Inherits System.Web.UI.Page
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim ds As System.Data.DataSet
DataGrid1.AllowPaging = True
DataGrid1.PagerStyle.Mode = PagerMode.NumericPages
DataGrid1.PageSize = 5
DataGrid1.PagerStyle.PageButtonCount = 5
If IsPostBack Then
ds = DirectCast(Session("Dataset"), System.Data.DataSet)
DataGrid1.DataSource = ds
Else
ds = New System.Data.DataSet
Dim dt As New System.Data.DataTable
dt.Columns.Add("Mycolumn")
For i As Integer = 0 To 100
dt.LoadDataRow(New Object() {i.ToString}, True)
Next
ds.Tables.Add(dt)
Session("dataSet") = ds
DataGrid1.DataSource = ds
DataBind()
End If
End Sub

Private Sub DataGrid1_PageIndexChanged(ByVal source As Object, ByVal e _
As System.Web.UI.WebControls.DataGridPageChangedEventArgs) _
Handles DataGrid1.PageIndexChanged
DataGrid1.CurrentPageIndex = e.NewPageIndex
DataGrid1.DataBind()
End Sub

End Class
///
 
Yes Cor, we are talking about different things, that has been my point here
all along with you. You are talking about how strings can be passed to an
object and how that object requires (or doesn't require) the string to be
passed case-sensitively. I get that, we get that. But that has not been
what I have been talking about and I've repeated that fact over and over
again.

Every one of your posts in this thread are true and correct, except the
first one, which you've been debating incorrectly ever since you made it.

I have been and still am, simply pointing out that the ADO.NET classes (or
any class) may require (or not) a string to be passed in a certain way, but
that has nothing to do with how VB.NET works with strings and since this
whole branch of the thread started with "it's not case sensitive (VB.NET)",
it makes no sense to me why you keep coming back with the same example that
has nothing to do with this stattement.

You've also made references to ASP.NET not being case-sensitive, but that
statement make no sense in any conversation since ASP.NET is an
architecture, not an object, nor a language. I think you mean to say that
in ASP.NET, there are certain types that you don't use in a WinForms
application, such as the System.Web.UI.WebControls.DataGrid and the
System.Windows.Forms.DataGrid and since these are two different types, they
handle case sensitivity differently. This again, boils down to the type
differences, not ASP.NET.

It's really very simple VB.NET is not a type, it's a language. VB.NET has
its rules about how strings are handled and any given type can have its own
rules that may differ, but to say that VB.NET strings are not case-sensitve
*sometimes* and then to show an example of a string being used on a type, is
an incorrect statement to make.

You've shown code that uses strings on types, but you haven't addressed
strings used by the language. I originally showed this code in my first
example:

Dim A As String = "Scott"
Bim B As String = "scott"

If A = B Then
MessageBox(A & "= " & B)
Else
MessageBox(A & " <> " & B)
End If

You will find that the code in the Else always runs.

Your response was:

"Your message should be true, however, it is not always,"

but, that is incorrect to say, the else portion will always run. You then
went on to say:

"it is strange enough
that in AspNet the string literals from ADONET can be mixed uper and lower
case. (I thought I had seen this in version 1.1)."

Which has nothing to do with VB.NET, it has to do with types.

You've made your point very clearly, you've just been labelling it
incorrectly and that's all I've been trying to point out to you.

Right comments, wrong conversation.
 
Scott,

Are you sure of that, my replies were based on your reply on Chris who was
denying this in a way.

"Stephany Young"
In the masterpage, the id of the control is Lkred and not lkred.

mpg.FindControl("lkred") returns nothing becuase it should be
mpg.FindControl("Lkred")
Click to expand...

I am not saying that the message from Stephany is wrong there was my answer
not about.

Cor
 
Scott,

Scott M. said:
You've shown code that uses strings on types, but you haven't addressed
strings used by the language. I originally showed this code in my first
example:

Dim A As String = "Scott"
Bim B As String = "scott"

If A = B Then
MessageBox(A & "= " & B)
Else
MessageBox(A & " <> " & B)
End If

You will find that the code in the Else always runs.
Click to expand...

Again, only with 'Option Compare Binary' (the default) set, but not when
'Option Compare Text' is used.
 
Cor,

I was not referring to Chris's mpg.FindControl issue at all. I was (as
pointed out repeatedly) referring to his statement "it's not case sensitive
(VB.NET)".

-Scott
 
Yes, as mentioned earlier, but I am referring to the default way that VB.NET
operates. The fundamental comparison of how a type deals with a string vs.
how the language deals with a string is what is at issue (at least for me)
here.
 
Back
Top