I want to make that variable can be assigned with null. But giving'?' seems doesn't work. Please help me find the way out. I'm new to this. Thanks
Public Class T3DObject
Public V(7) As Point
Public E(5) As Surface
End Class
Public Structure ListElmt3DObject
Public first As Elmt3DObject
End Structure
Public Class Elmt3DObject
Public child As ListElmt3DObject?
Public nxt As Elmt3DObject? 'this line is error
Public obj As T3DObject? 'this also error
End Class
Is there any other way? Please share. Thank you!!
This is the code that make error: NullReferenceException
Sub Process(ByRef E As Elmt3DObject)
While E.child IsNot Nothing Or E.nxt IsNot Nothing
'code
End While
End Sub
I know this is a VB.Net question, but to understand this it's helpful to understand some of how C# works, too. In C#, there is a concept of null. You can assign a null value to reference types (ie: VB.Net Class), but you cannot assign null to value types (ie: VB.Net Structure). Value type (Structure) variables always have a value of some kind.
Coming back to VB.Net, we have the Nothing keyword. However, Nothing is not a direct analog to C#'s null. It's closer to match to the C# default(T) expression. VB.Net allows you to assign Nothing to value types. It's just that when you do, you get the default value for the type.
The Nullable(Of T) type and associated language syntax features were designed to allow newer null semantics for value types. This doesn't apply to reference types, because reference types already have a concept of null.
While I'm here, I also see this:
Sub Process(ByRef E As Elmt3DObject)
Elmt3DObject is a reference type (Class). It's almost always a mistake to pass a reference type ByRef. You still want ByVal, because passing ByVal for Classes still passes the reference. It makes a copy of the reference, but it's still just a reference.
Related
This code will throw a System.InvalidOperationException when the click event happens because the nullable (of decimal) has not been given a value.
Public Class Form1
Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
Dim myob As New MyObject
Dim price As Decimal = CDec(myob.Price)
End Sub
End Class
Class MyObject
Public Property Price As Decimal?
End Class
However, even with Option Strict on, I do not get any warnings. Can I get Visual Studio 2019 Professional to warn me about this? The value is coming from a database, and therefore null/nothing is a valid value and obviously means something different than 0. I am not asking how to check if Price has a value, I am wondering if I can get Visual Studio to give me a warning if I miss checking for a value.
I believe the answer to your question is that you should always use the same type when creating a new private variable.
Example:
Nullable(of Decimal) = Nullable(of Decimal) or Decimal = Decimal
Unless you check your var for value of Nothing before using or setting it.
like this
Dim var1 as Nullable(of Decimal) = Nothing
Dim var2 as Decimal
If var1 IsNot Nothing Then
var2 = var1
End If
UnFortunately
Visual Studio doesn't seem have any feature that allows
checking of this problem(Maybe you should build a free extension that does this)
Installing VS 2019 doesn't resolve an issue that doesn't exists
Primitive types (decimal, integer, boolean etc) cannot be null on declaration, those have a default value.
But if a Dev need a variable of primitive type to be NULL/Nothing just add on end of type an question mark “?”.
At this point the variable become a Nullable Type, so in your case a Nothing value of “Thing” cannot be 0.
Remove your question mark “?” to have default value. :)
C# 8.0 introduces nullable reference types and non-nullable reference types that enable you to make important statements about the properties for reference type variables.
A reference can be null. No warning is issued when a reference type
is initialized to null, or null is later assigned to it.
A reference is assumed to be not null. The compiler doesn't issue any
warnings when reference types are dereferenced. (With nullable
references, the compiler issues warnings whenever you dereference a
variable that may be null).
With the addition of nullable reference types, you can declare your intent more clearly. The null value is the correct way to represent that a variable doesn't refer to a value. Don't use this feature to remove all null values from your code. Rather, you should declare your intent to the compiler and other developers that read your code. By declaring your intent, the compiler informs you when you write code that is inconsistent with that intent. Please see the document fore more details.
Why is this different?!
Public Class Form1
Public Function MyFunction() As Integer?
Return Nothing
End Function
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Dim o As Object = Me
MsgBox(TypeName(Me)) ' Form1
MsgBox(TypeName(o)) ' Form1
MsgBox(TypeName(Me.MyFunction())) ' Nothing
MsgBox(TypeName(o.MyFunction())) ' Nothing
' but
MsgBox(TypeName(Me.MyFunction() + 0)) ' Nothing
MsgBox(TypeName(o.MyFunction() + 0)) ' Integer
End Sub
End Class
Using Option Strict On is a pretty good way to avoid surprises like this. You'll get a "what the heck are you trying to do?" error message from the compiler.
But with it Off, these are valid statements, executed by the DLR, the Dynamic Language Runtime. Which is capable of evaluating late-bound expressions like this. It however has a problem with a nullable type like Integer?. It needs to deal with the boxed version of the value. Which is just plain Nothing. And Nothing doesn't have any type information associated with it. There's nothing the DLR can do to see that this started life as a nullable integer, for all it knows it could be a string that is Nothing.
The compiler cannot help either, it cannot emit any code to make the expression follow normal evaluation rules. All it knows is that there is some function, it doesn't know which, whose name is "MyFunction" with no idea what kind of value it returns. It passes the buck to the DLR to sort it out.
So the DLR just punts at it. And it comes up with "No idea" + 0 = 0. Given that it does have type information for 0. It is an Integer so it tries to interpret the left operator as an integer as well. Which is valid, Nothing is a correct default value for Integer.
Feature, not a bug.
Visual Basic .NET had Nothing long before it had nullable value types - it inherited it from pre-.NET Visual Basic. And in some cases, it behaves more like C#'s default(T) then t does null.
Your final call is invoking the AddObject method in the Visual Basic compiler services. This method has existed for a long time, and again pre-dates nullable value types, and unfortunately isn't well documented.
Unfortunately, they couldn't make nullable types behave absolutely consistently, especially in the face of late-bound calls, whilst still maintaining backwards compatibility. For instance, this also prints 0:
Console.WriteLine(CType(CType(Nothing, Object), Int32))
I'm trying to create a a simple function in VB.net which will take a few parameters for use with TryCast.
My goal is to have a function I can use in place of TryCast which instead of returning Nothing when it fails it should return DbNull.
I just can't seem to get anything to work despite much searching.
Thanks.
The problem is that you have to have some specific return type for your function. So you can write a function with a signature like this:
Public Function TryCast(Of T)(ByVal item As Object) As T
But you will never be able to make it do what you want, because the type of T is never going to be DBNull (okay, maybe it could happen, but hopefully you get the idea).
Put another way, the type system blocks this. On the one hand, you want to be perfectly explicit about the return type (hence, the cast). On the other hand, you want to be able to return a completely different type. .Net does not allow this, even with dynamic typing. Either a method returns a single fixed type, or it is not declared to return a type at all.
With Option Explicit turned off, you might be able to go for something like this:
Public Function TryCast(Of T)(ByVal item As Object)
However, I don't think this will do what you want, either, because now the returned value is effectively the same as object, and you lose the benefit of any casting.
It works with the normal TryCast() for Nothing, because Nothing can be assigned to any type. DBNull is itself a fixed type, and so is not as flexible.
Simple answer - not possible, and here is why. Suppose you have the following code:
Class A
End Class
Class B : Inherits A
End Class
Class C
End Class
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
Dim aaa As A = MyTryCast(Of A)(New B)
Dim ccc As C = MyTryCast(Of B)(New C)
End Sub
Private Function MyTryCast(Of T As Class)(obj As Object) As Object
Dim result As Object = TryCast(obj, T)
If result Is Nothing Then Return Convert.DBNull
Return result
End Function
MyTryCast does exactly what you are asking for, so aaa assignment works. Problem appears when you assign DBNull to ccc variable of type C. You would expect it to assign DBNull to C, because C cannot be converted to B (regular TryCast would return Nothing). Instead, you get System.InvalidCastException, because you cannot assign a DBNull to an instance of your custom class. Important thing to remember here - Nothing can be assigned to anything, DBNull can only be assigned to an Object. See here for DBNull inheritance hierarchy.
In C++, it is possible to do:
int x;
int& foo = x;
// foo is now a reference to x so this sets x to 56
foo = 56;
But is an equivalent possible in Visual Basic .net (VB.net)?
I am aware of the ByRef term in VB.net but I have only seen (and by extensive research) this in passing parameters by reference to functions/subroutines, so that the function modifies the same variable declared by the calling code.
But I haven't seen ByRef used to declare variables (as class members or local variables). I have tried to use ByRef to do such a declaration but I get compiler errors for each ordering of the declaration I try.
The reason why I want to do this is because I want a class instance to be able to refer to a variable declared in another class instance.
Specifically, I am working on some existing VB.net code where program logic is mixed up with UI logic in VB.net form classes. I want to separate the program logic out of the form code so that it can be more easily reused. To do this I need the program logic code to be able to 'talk' to the form code so I need access to its variables.
I am using Visual Studio 2010 Express with VB.net and would prefer to remain within this environment even though I am aware that full Visual Studio has extended capabilities.
Pointers exist but they're called object references
(Now other posters, please don't quibble with me about the actual differences here. I am talking about the high level task the OP wants to accomplish)
Obviously you can't do literally what you've said - that is, surgically manipulate one member. But if you have control of the code, you can do almost as well. And from what you describe is your problem, this method will be much better, as you can pass references to an object that has many members you wish to update, instead of having to pass many individual pointers.
First define a class:
Class MyScreenValues
' Properties will work... using public fields for brevity
Public TextBox1Value as String
Public SpinControl1Value as Integer
public CheckBox1Value as Boolean
End Class
Now the equivalent of the code you posted:
Dim x as new MyScreenValues 'int x;
dim foo as MyScreenValues = x 'int& foo = x;
'// c++: foo is now a reference to x so this sets x to 56
'// .net: foo is now a reference to x so this sets x.SpinControl1Value to 56
foo.SpinControl1Value = 56;
If what you're doing is trying to pass pointers to, say, every control on your form's value to a sub, like so:
Button1_Click(...
Dim MyObject as new BusinessObject
MyObject.DoSubmit(TextBox1.Text, SpinButton1.Value, CheckBox1.Checked)
You can use the method provided by superbDeveloper, and use the ByRef keyword on the definition of the DoSubmit Sub:
Public Sub DoSubmit(ByRef Name as String, ByRef Age as Integer, ByRef Employed as boolean)
... business logic...
However this just gives you a 2-layer separation. Look into MVP, MVC, etc - however consider submitting the entire view worth of data. It's a lot of research you you may settle with what you have now. For example your business logic will be firing events on the form as it changes the form values (well, actually, they won't fire until the sub exits, due to the way VB deals with byref properties [=temp variable], but it needs to be considered).
You can also map an object's properties to a Form's properties with other libraries. Check out VALUE INJECTOR on the web. It can take a webform/winform and maybe even a WPF form and map the control values to and from an object you have predefined. Excellent for complete separation.
Hi well not sure about VB.NET but I know how do it in C#, therefore I did the solution in C# and then i used a C# to VB.NET convertor to get the VB.NET code. maybe it might help you:
http://www.developerfusion.com/tools/convert/csharp-to-vb/
C# Code
protected void TestFoo()
{
string strFooA = string.Empty;
GetFoo(ref strFooA);
Response.Write(strFooA);
}
private void GetFoo(ref string strFooA)
{
strFooA = "FooA";
}
VB.NET converted
Protected Sub TestFoo()
Dim strFooA As String = String.Empty
GetFoo(strFooA)
Response.Write(strFooA)
End Sub
Private Sub GetFoo(ByRef strFooA As String)
strFooA = "FooA"
End Sub
Pointers don't exist in the .NET framework like they do in C/C++, so you won't be able to directly achieve what you want.
There are some possible solutions on this SO page
See #NathanW answer on there:
If you are using VB the only thing that is really close to a pointer is a IntPtr. If you have access to C# you can use unsafe C# code to do pointer work.
In Addition
If you want to be able to use references then you can achieve this by using a class:
Private Class RefClass
Public x As Integer
End Class
Then you can reference one from the other:
Dim bar As New RefClass
Dim foo As RefClass = bar
bar.x = 45
Debug.WriteLine(bar.x) 'outputs 45
Debug.WriteLine(foo.x) 'outputs 45
You may already know enough to get the job done from the info at http://www.dreamincode.net/forums/topic/135354-reference-types-value-types-byval-byref/ ; however, your remark "ByRef is not required in declaration of local variables (and possibly class variables)" left me wondering if there's some confusion here.
For starters, the C++ example above, int x; int& foo = x; confuses what is meant by a "reference". My C++ isn't very strong, but, semantically speaking, I believe this C++ reference operates more like an aliasing mechanism. In VB (and C#) a reference operates like an identification code that locates an instance of a class in memory. Neither VB or C# has anything like the C++ reference type.
By now, you probably already know you can pass in your Form as a ByVal parameter, and change its properties and fields without problem. (ByVal is the default in VB.NET, so you don't even need to use it - in VB6 ByRef was the default.) If you're happy enough, you can skip the rest. But, yeah, in the case of .NET Reference variables, assuming:
Dim objA as New MyClass()
Dim objB as MyClass = objA
Then objA and objB both reference the very same instance of MyClass. You can modify via objA and objB, and you can read back from either objA or objB, because they each affect the very same instance. You can pass either objA or objB into some subroutine Foo with parameter objC As Object passed ByVal (i.e. Sub Foo(ByVal objC As Object) ) and Foo can then modify that same instance too.
The ByRef of VB and the ref of C# indicate a modifiable parameter, which means some "identification code" reference is passed instead of a value. Yet this ByVal vs. ByRef thing is clear as mud because in .NET there is a distinction made between "Value" types and "Reference" types that confuses many on whether a ByRef or ref is needed or not.
Visual Basic and C# dichotomizes variables (and data types) into two species: the "Value" (or "Structure"), and the "Reference" (or "Class").
The "Value" type means an actual collection of bits that represents an Integer, or a Boolean, or even a bitmap, or some other kind of object. In old school parlance, this is the "image" of the instantiation of an object. It is the state space of the object. It is what makes an object essentially itself, independent of where in memory it may be.
The "Reference" type means a code (which might look like an integer or a pointer) that somehow indicates the data type of the object and where in memory it resides. The computer will interpret a "Reference" to obtain the actual image of the object (i.e. its "Value").
When a "Value" parameter is passed ByVal, that means a new object is created that is in the identical image of the original expression being passed, and it is upon this copy that the function or method operates. The original image of the "Value" cannot be affected.
When a "Value" parameter is passed ByRef, that means a new "Reference" variable is created, and that "Reference" variable will contain the information that will interpret back to the image of the original "Value". Now the original image of the "Value" can be changed.
When a "Reference" parameter is passed ByVal, its "identification code", which gets interpreted back to the actual image of the object, gets copied. It is upon this copy of the code that the function or subroutine or method operates. This copy still points to the actual image of the object. Which means that an object of a Reference variable that is passed by ByVal can still have its image (i.e. its "Value") changed. However, the code of the original "Reference" itself cannot be changed.
(Note that the String type is an odd duck: It will behave as if it were a "Value" parameter even though it is in fact a "Reference" type. Hence a String passed ByVal will not be affected in the same way any other class would. Actually, String is an example of an immutable type - which means that steps are taken to prevent changes to its "Value".)
When a "Reference" parameter is passed ByRef, one now has created a new "Reference" object that points to the original "Reference" object (that, in turn, points to the "Value" of some other object via its "identification code"). The use of ByRef on a "Reference" allows one to modify (or create anew) the "identification code" of the original "Reference" object being passed as a parameter. A function or subroutine or method that performs a swap operation will use ByRef on "Reference" parameters.
I was shocked just a moment ago to discover that the following is legal (the C# equivalent is definitely not):
Class Assigner
''// Ignore this for now.
Public Field As Integer
''// This part is not so weird... take another instance ByRef,
''// assign it to a different instance -- stupid but whatever. '
Sub Assign(ByRef x As Assigner, ByVal y As Assigner)
x = y
End Sub
''// But... what's this?!?
Sub AssignNew()
''// Passing "Me" ByRef???
Assign(Me, New Assigner)
End Sub
''// This is just for testing.
Function GetField() As Integer
Return Me.Field
End Function
End Class
But what's even stranger just as strange to me is that it doesn't seem to do what I expect:
Dim a As New Assigner With {.Field = 10}
a.AssignNew()
Console.WriteLine(a.GetField())
The above outputs "10," not "0" like I thought it would (though naturally, this expectation was itself infused with a certain kind of horror). So it seems that you can pass Me ByRef, but the behavior is somehow overridden (?) by the compiler to be as if you had passed Me ByVal.
Why is it legal to pass Me ByRef? (Is there some backwards-compatibility explanation?)
Am I correct in saying that the behavior of doing this is overridden by the compiler? If not, what am I missing?
This behavior actually follows pretty directly from the Visual Basic specification.
11.4.3 Instance Expressions
An instance expression is the keyword Me, MyClass, or MyBase. An instance expression, which may only be used within the body of a non-shared method, constructor, or property accessor, is classified as a value.
9.2.5.2 Reference Parameters
If the type of the variable being passed to a reference parameter is not compatible with the reference parameter's type, or if a non-variable is passed as an argument to a reference parameter, a temporary variable may be allocated and passed to the reference parameter. The value being passed in will be copied into this temporary variable before the method is invoked and will be copied back to the original variable (if there is one) when the method returns.
(All emphasis mine)
So, the compiler will create a temporary variable assigned to the value of Me to be passed as the ByRef parameter. Upon return, no copy of the resulting value will take place since Me is not a variable.
It appears the compiler transforms "Me" into a variable which is then passed ByRef. If you compile your code, then open it with Reflector, you can see what's happening:
Class Assigner
''// Methods
Public Sub Assign(ByRef x As Assigner, ByVal y As Assigner)
x = y
End Sub
Public Sub AssignNew()
Dim VB$t_ref$S0 As Assigner = Me
Me.Assign((VB$t_ref$S0), New Assigner)
End Sub
Public Function GetField() As Integer
Return Me.Field
End Function
''// Fields
Public Field As Integer
End Class
So it looks like when you call AssignNew(), you are assigning the new instance to the internally generated variable. The "a" variable doesn't get touched because it's not even a part of the function.
This is just one of the thousands of possible 'almost errors' a programmer can make. MS caught most of them, in fact, sometimes I'm suprised at how many warnings do come up.
they missed this one.
As far as why it doesn't change 'me', it's a darn good thing! When you use 'me', it just passes a copy of the real class you are working with, for safety purposes. If this worked they way you were hoping, we would be talking GIANT side-effect. You're innocently working away with in your class' methods, and them BAM all of a sudden you are in an ENTIRELY different object! That would be awful! If you're going to do that, you might as well just write a piece of spagetti MS-Basic line-numbered code with all globals that get randomly set, and no subs/functions.
The way this works is the same way if you pass arguments in parenthesis. For example this works as expected:
Assign(Reference_I_Want_To_Set, New Assigner)
But this doesn't change anything:
Assign((Reference_I_Want_To_Set), New Assigner)
If you reflect the above type of code as adam101 suggests you will see similar results. While that is huge frustration with the parenthesis, it is a very good thing with Me !!!
what you need to do to make this code work is this:
Class Assigner
''// Ignore this for now.
Private newPropertyValue As Integer
Public Property NewProperty() As Integer
Get
Return newPropertyValue
End Get
Set(ByVal value As Integer)
newPropertyValue = value
End Set
End Property
''// This part is not so weird... take another instance ByRef,
''// assign it to a different instance -- stupid but whatever. '
Shared Sub Assign(ByRef x As Assigner, ByVal y As Assigner)
x = y
End Sub
''// But... what's this?!?
Shared Sub AssignNew(ByRef x As Assigner)
''// Passing "Me" ByRef???
Assign(x, New Assigner)
End Sub
End Class
then use it like
Dim a As New Assigner With {.NewProperty = 10}
Assigner.AssignNew(a)
my understanding is you cannot change the reference of the object while using it, so you need to change it in a shared sub
since Me cannot be the target of an assignment, the code seem to create a copy of it and from that point on, your not using the real object, but a copy of it