Warning in VB.Net IDE when compiling

  • Thread starter Thread starter NumbLock
  • Start date Start date
N

NumbLock

Hello all. I have a bit of code that to me looks perfectly sane, but the
VB IDE flags a warning. I was wondering if this is just a limitation of
the code parser that the IDE uses or is it a bad practice. Here is the code
(I know the purists will bitch about the goto but I've been coding VB since
version 3 even VB-DOS if anyone remembers it but I am still a tad lazy):

Dim oCmd As New SqlCommand("usp_GetCustomerAddressBlock", oCn)
oCmd.CommandType = CommandType.StoredProcedure

oCmd.Parameters.AddWithValue("@ListID", ComboBoxCompanyName.SelectedValue)
Dim oReader As SqlDataReader

Try
oReader = oCmd.ExecuteReader
Catch ex As Exception
Call oUtil.SetStatusMessage(String.Format("There was an error
retrieving the customer's billing address. {0}", ex.Message), , True)
GoTo cleanup
End Try

If Not oReader.HasRows Then
Call oUtil.SetStatusMessage("There is no address information
available for this customer.", True)
GoTo cleanup
End If

oReader.Read()
Me.TextBoxCustomerBillingAddress.Text = oReader!BillingAddress
Me.TextBoxShippingAddress.Text = oReader!ShippingAddress

cleanup:
If Not IsNothing(oReader) Then
oReader.Close()
oReader.Dispose()
End If

oCmd.Dispose()
oCn.Close()
oCn.Dispose()

it is flagging the null exception warning on the following line:

If Not IsNothing(oReader) Then

Thanks for any advice.
 
Am 13.04.2011 19:56, schrieb NumbLock:
Hello all. I have a bit of code that to me looks perfectly sane, but the
VB IDE flags a warning. I was wondering if this is just a limitation of
the code parser that the IDE uses or is it a bad practice. Here is the code
(I know the purists will bitch about the goto but I've been coding VB since
version 3 even VB-DOS if anyone remembers it but I am still a tad lazy):

Dim oCmd As New SqlCommand("usp_GetCustomerAddressBlock", oCn)
oCmd.CommandType = CommandType.StoredProcedure

oCmd.Parameters.AddWithValue("@ListID", ComboBoxCompanyName.SelectedValue)
Dim oReader As SqlDataReader

Try
oReader = oCmd.ExecuteReader
Catch ex As Exception
Call oUtil.SetStatusMessage(String.Format("There was an error
retrieving the customer's billing address. {0}", ex.Message), , True)
GoTo cleanup
End Try

If Not oReader.HasRows Then
Call oUtil.SetStatusMessage("There is no address information
available for this customer.", True)
GoTo cleanup
End If

oReader.Read()
Me.TextBoxCustomerBillingAddress.Text = oReader!BillingAddress
Me.TextBoxShippingAddress.Text = oReader!ShippingAddress

cleanup:
If Not IsNothing(oReader) Then
oReader.Close()
oReader.Dispose()
End If

oCmd.Dispose()
oCn.Close()
oCn.Dispose()

it is flagging the null exception warning on the following line:

If Not IsNothing(oReader) Then

Thanks for any advice.
Click to expand...

In the case of an exception, oReader has not been assigned at that
warning line, though you use the variable. The compiler does not distinguish
between the different kinds of variable usage and is not able to
consider a higher level logic.

BTW, instead of calling a function, I'd use "If oReader Is Nothing"
resp. "If oReader IsNot Nothing"/"If Not oReader Is Nothing". In the
case of a function, the compiler warning is understandable because
a NullReferenceException might occur inside the function. However,
also comparisons like 'Is' or 'IsNot' produce the warning.

So, the usual action to take is: Verify if a NullReferenceException
could really occur. If yes, fix it. If no (like in your case), add
a dummy assignment:

Dim oReader As SqlDataReader = Nothing
 
Hello Armin,
Gotcha. Declaring it as nothing took care of the warning. I am just sorta
used to using iSnothing.... A bit more of a habit than anything. At any
rate, thanks for your reply.
 
Hello Armin,
Thanks again for your assistance. I am hoping you can help me sort out another
problem. I've posted to several groups and the online MS forumns and noone
has replied. It has to do with a progressbar not getting completely filled.
Sometimes it is 1/2 full, other times it is 3/4 full but never completely
filled. Is there another method to update the progressbar to get around
this problem? Code follows:

Dim OrItemRetlist As IORItemRetList = oRespList.Detail

Dim iOrItemRet As IORItemRet


frmMain.ProgressBar.Maximum = OrItemRetlist.Count - 1
frmMain.ProgressBar.Value = 0
Call oUtil.ShowProgressBar(True)
Application.DoEvents()

frmMain.ProgressBar.Maximum = OrItemRetlist.Count - 1
For i As Integer = 0 To OrItemRetlist.Count - 1
frmMain.ProgressBar.Value = i
Application.DoEvents()
iOrItemRet = OrItemRetlist.GetAt(i)

If IsNothing(iOrItemRet) Then
oUtil.ShowProgressBar(False)
oUtil.SetStatusMessage("No items were returned.", , True)

If Not m_SyncAll Then
m_oCn.Close()
m_oCn.Dispose()
oSM.CloseConnection()
End If

Return True
Exit Function
End If

I am sure the formatting will get screwed up with the code post. But it's
a pretty cool aggregator I'm using and free too. Might be the way the server
is handling the post or something or just the reader. But anyway, you can
see what I am trying to do. This never gets past halfway...

Thanks again.
 
Am 13.04.2011 20:52, schrieb NumbLock:
Hello Armin,
Thanks again for your assistance. I am hoping you can help me sort out another
problem. I've posted to several groups and the online MS forumns and noone
has replied.
Click to expand...

I did reply in the Framework group but you didn't. :-)

I copy...: "Are you updating the progressbar in a busy UI thread?"
No answered, so, maybe the hack posted here applies: (see last message)
http://social.msdn.microsoft.com/Forums/en/winforms/thread/bdcec4df-fc9f-431a-87c1-37531ee2782f

I also had to apply it because of probably the same symptom. Before, I was
thinking my code was wrong.
It has to do with a progressbar not getting completely filled.
Sometimes it is 1/2 full, other times it is 3/4 full but never completely
filled. Is there another method to update the progressbar to get around
this problem? Code follows:

Dim OrItemRetlist As IORItemRetList = oRespList.Detail

Dim iOrItemRet As IORItemRet


frmMain.ProgressBar.Maximum = OrItemRetlist.Count - 1
frmMain.ProgressBar.Value = 0
Call oUtil.ShowProgressBar(True)
Application.DoEvents()
Click to expand...

DoEvents is baaad!
 
Hello Armin,
Thanks for the reply. I will check out the link. It is a single-threaded
app. Do you suggest system.threading.thread.sleep(0) over doevents or something
else to yeild control to the OS?
 
Am 13.04.2011 22:07, schrieb NumbLock:
Hello Armin,
Thanks for the reply. I will check out the link. It is a single-threaded
app. Do you suggest system.threading.thread.sleep(0) over doevents or something
else to yeild control to the OS?
Click to expand...

It does not make sense to process messages within a loop that already processes
messages. I you don't use DoEvents, the UI does not respond. The cause is that
you are preventing the loop from doing it's job. I suggest to eliminate the cause
instead of using a hack (=DoEvents). The solution is to put the work in another
thread.

thread.sleep wouldn't help at all.

Typo: I meant "Now answered,..."
 
Hello Armin,
Thanks again for your comments. Been using doevents since the early days.
Threading is not too difficult to accomplish (especially in .net) but while
this is occurring I don't want the user to be able to interact with the UI
because it can get other MDI child windows out of sync or with only partial
data. It would be a lot of work to synchronize all of the possible forms
that could be opened or are already opened during this process (once again
my lazy streak rears it's ugly head). I was just trying to use doevents
to get the progressbar to keep up (vb6- logic) but the little hack you mentioned
(thanks again!) fixed my problem. So at this point I am not going to work
with threading on this project. But I will indeed remove the doevents from
all the code. Thank you again ever so much for your helpful advice.
 
Am 13.04.2011 23:35, schrieb NumbLock:
Hello Armin,
Thanks again for your comments. Been using doevents since the early days.
Threading is not too difficult to accomplish (especially in .net) but while
this is occurring I don't want the user to be able to interact with the UI
because it can get other MDI child windows out of sync or with only partial
data. It would be a lot of work to synchronize all of the possible forms
that could be opened or are already opened during this process (once again
my lazy streak rears it's ugly head). I was just trying to use doevents
to get the progressbar to keep up (vb6- logic) but the little hack you mentioned
(thanks again!) fixed my problem. So at this point I am not going to work
with threading on this project. But I will indeed remove the doevents from
all the code. Thank you again ever so much for your helpful advice.
Click to expand...

You're welcome!

If you use DoEvents, the user can interact. That's not what you want. How do
you handle this contradiction? If you'd remove DoEvents, the OS considers the
UI thread hung up after a certain period of time. Then the UI wouldn't update
anymore even if you called the (progressbar's) Refresh method.
 
Hello Armin,
You are absolutely right. This is a bit of a quandry as to handle all of
the opened mdi children while the updates take place. I guess I could write
code in each mdi child to refresh the pertinent data and cycle through the
mdi parent's child form calling that method to synchronize the data with
the updated data after all of the updates are complete. I'll be able to
ctype each form in the collection to it's proper type using the name property.
Gonna be a bit of coding (quite a bit) but probably needs to be done. I
can disable the menubar during the update to prevent new windows from opening
during the updates. Oh well, I will get it done one way or another. Thanks
again. Have a good evening.
 
Back
Top