I was trying to convert some C# to VB.Net code using several online
converters. They all gave me the same VB.Net code result and I pasted it into the VB.Net and immediately got an error:
Quote:
|
'IsNot' requires operands that have reference types
|
The code:
Code:
Protected Overridable Sub Dispose(disposing As Boolean)
' Check to see if Dispose has already been called.
If Not Me.disposed Then
' If disposing equals true, dispose all managed
' and unmanaged resources.
If disposing Then
' Dispose managed resources.
If Me.bmpTargaImage IsNot Nothing Then
Me.bmpTargaImage.Dispose()
End If
If Me.bmpImageThumbnail IsNot Nothing Then
Me.bmpImageThumbnail.Dispose()
End If
If Me.ImageByteHandle IsNot Nothing Then
If Me.ImageByteHandle.IsAllocated Then
Me.ImageByteHandle.Free()
End If
End If
If Me.ThumbnailByteHandle IsNot Nothing Then
If Me.ThumbnailByteHandle.IsAllocated Then
Me.ThumbnailByteHandle.Free()
End If
End If
End If
End If
disposed = True
End Sub
Of course with a little research I found this
old MSDN VS.Net 2008 page.
(there should be a VB.Net 2010 page also -- because the issue is still occurring
in the VB.Net 2010 IDE, but I didn't find one..)
The longer explanation (yes more internet research,
(and this info should have been included the MSDN IsNot article):
In C#, the == and != operators are used for both value types,
(structures and enums) and reference types (classes and delegates).
In VB, the = and <> operators are used only for value types
while the Is and IsNot operators are used only for reference types.
There are some exceptions to this rule in VB,
where the = and <> operators have been explicitly defined for a reference type.
The most visible case of this is the String class.
You can use the = and <> operators on String objects to test value equality
where the Is and IsNot operators test reference equality.
That means that this:
Code:
If str1 = str2 Then
will be True if the two Strings contain the same text,
even if they are two different objects.
As an example of how the two conditions differ,
try creating a form with two TextBox controls,
then type the same text into both and then execute this code:
Code:
MessageBox.Show((TextBox1.Text = TextBox2.Text).ToString())
MessageBox.Show((TextBox1.Text Is TextBox2.Text).ToString())
The first one is True because both Strings contain the same text
while the second one is False because they are two different String objects.
The thing that is annoying is that the VB.Net IDE offers no auto-correction options..
(like "Would you like to change the IsNot to <> in order to fix the error?")
Here's another gotcha:
You paste your converted from C#.Net to VB.net code into a Class Library project
(intending to have a nice VB.Net dll), and you get this error:
Quote:
Namespace or type specified in the Imports 'System.Drawing' doesn't contain
any public member or cannot be found. Make sure the namespace or the
type is defined and contains at least one public member.
Make sure the imported element name doesn't use any aliases.
|
The error points to this line:
I've added that line to my VB.Net Winforms projects
hundreds of times and never got an error!
So you backspace over the ".Drawing" part, leaving
..and the error goes away (the VB.Net IDE likes you again..hmmm..)
However, them you type in the period after "Imports System" and the VB.Net IDE intellisense gives you a whole bunch of options starting with AttributeUsageAttribute
and ending with XML but "Drawing" is nowhere to be found!!!!
Of course the VB.Net IDE auto-correction and help offers no clue as to why this strange behavior is occurring.
More internet research turns up
this StackOverflow thread.
I had fun reading the long explanation in that thread
that explains the really awkward way that Microsoft differentiates
between assemblies and namespaces,
but the short answer is:
Quote:
The System.Drawing namespace "lives" in another dll
that is not referenced initially in the template project for a class library.
You will have to add a reference to System.Drawing (right click on the project -> add reference; System.Drawing is in the GAC).
|
What's really aggravating is that the developers of the VB.Net IDE
knew this and didn't provide something helpful that might actually say:
Quote:
|
Adding this namespace to a class library project requires an assembly reference would like to add this reference now?
|
Here's yet another error (gotcha):
Quote:
|
Variable '<variablename>' hides a variable in an enclosing block
|
The VisualStudio.Net IDE provides absolutely no auto-correction options.
Her's the thing I've seen.
A lot of C#.Net programs like to a line like:
into something like
Quote:
|
Dim data As Byte() = Nothing
|
..nothing wrong with that is there..but wait..
Beneath this seeming innocent line is another C#.Net line like
Quote:
|
using (msData = new MemoryStream())
|
..which translates to the VB.Net code of:
Quote:
|
Using msData = New MemoryStream()
|
See the problem?
The solution is to delete the initial Dim,
or rename the "Using msByte" to something like "Using msData2",
however the .Net IDE offers neither of these options.
It doesn't really give you any idea that which two lines are causing the conflict (and I think it definitely would be helpful if it did..).
Here's another Dim/Using combo causing problems:
Quote:
filebytes = System.IO.File.ReadAllBytes(Me.strFileName)
Using binReader = New BinaryReader(FileStream)
|
had to change to:
Quote:
Dim mystream As New System.IO.FileStream(Me.strFileName, IO.FileMode.Open)
Using binReader = New BinaryReader(mystream)
|
..and it clears the error and works but I have no idea
what was wrong or why this corrects it?
AAAAAAAAAAAAAARRRRRRRRGGGGGGGGGHHHHHHH!!!!!!!!!!!!
Maybe I'm just having a bad day climbing the learning curve,
but thanks for letting me get that off my chest.
The C#.Net dll in question is for using Targa (.tga) files from
this CodeProject.
But anyway..I'm ready to give up.
Because of the forum's post length limitations Ill attach the code
(with all errors cleared) as a text file,
but who knows if I garbled the translation too badly for it to ever work
Quote:
Edit: Maybe I'll try working with a little later when I'm less upset/discouraged..
(still haven't figured out the type of dll & exe merging-into-one-solution IDE patching described here,
but did find this shorter application.settings explanation was more helpful).
|