What is an intrinsic value type, and what is the difference to non-intrinsic value types?
I couldn't find documentation about the effect of the option "Function returning intrinsic value type without return value." in Visual Studio's VB.Net project properties' Compile page.
You're right, there doesn't seem to be any documentation here.
Consider this code:
Module Module1
Sub Main()
Console.WriteLine("Foo() is {0}", Foo())
Console.ReadKey()
End Sub
Function Foo() As Integer
End Function
End Module
With the default project properties, which have "Function returning intrinsic value type without return value" set to Warning, this compiles with this warning:
warning BC42353: Function 'Foo' doesn't return a value on all code paths. Are you missing a 'Return' statement?
and outputs
Foo is 0
By setting That project property to Error, we can make this warning halt compilation with an error.
The 'intrinsic' part comes into play if we change the code to this:
Module Module1
Sub Main()
Console.WriteLine("Foo() is {0}", Foo())
Console.ReadKey()
End Sub
Function Foo() As Bar
End Function
End Module
Structure Bar
Public a As Integer
End Structure
Now, even though Bar is a value type, the code compiles with no warning whatever that project property is set to. We can therefore conclude that Integer is an 'intrinsic' value type, but our Bar is not.
What none of this tells us is what counts as an 'intrinsic' value type. Googling around, I found this page which tells me that if I fire up the Object Browser, right click in the left-hand pane and tell it to Group By Object Type, I see this:
which I think is the best we're going to get.
"intrinsic" can be taken as "built-in" in this case.
And it seems not all that relevant, you are simply missing a return.
Related
I want to assign certain time weightage values to the variables of a data set. So I am trying to use Enumerations/Constants so to improve my code quality and make it easy to maintain. But on compiling my project, it throws in a Circular Dependencies Between Modules error.
What I have understood is, one is allowed to use only constants [Eg: 2,3.14,56....], in the truest sense of the word. Bottom line, if I can't use Either Enumerations or Constants. Then how can I achieve my objective of keeping my weightages code-block, in a way that any changes in them is reflected everywhere in my project than me having to do a find and update manually every instance.
What I am getting at, is to have a global variable that can be accessed throughout the project and is dynamic.
Private Const Wtage As Double = ConvTohr(34) 'Error happens here
Enum Weightage
Var1_Weightage = ConvTohr(3) 'Error happens here
Var2_Weightage = ConvTohr(11)
Var3_Weightage = ConvTohr(2)
var4_Weightage = ConvTohr(9)
var5_Weightage = ConvTohr(0)
End Enum
Private Function ConvTohr(val As Integer) As Double
If val = 0 Then
ConvTohr = 0
Exit Function
End If
ConvTohr = Round((val / 60), 2)
End Function
The error message is incorrect: your code does not have any circular references.
This is more of a bug in the VBA interpreter: your code is still incorrect and invalid, but VBA is showing the wrong error message.
Given that VBA remains effectively frozen-in-time since 2002 (excepting 64-bit support in 2007), so don't expect any fixes, let alone any enhancements, ever (Though MS Office's COM automation tooling is slowly shifting to JavaScript (maybe Python? please?).
The actual problem with your code is threefold:
You cannot use a Function to initialize a Const value in VBA.
You cannot use a Function to define values for a VBA Enum either.
You cannot have Enum members typed as Double: VBA only supports Integer and Long values for Enum members.
Curiously, VBA does allow Const values to be typed as Double - but most other languages don't because Double is an IEEE-754 floating point type that does not have a machine-portable representation, but as VBA is only for Win32 on x86/x64 I guess that means Microsoft made it work given the very narrow gamut of hardware that VBA programs will run on.
Anyway, if you want "named values" typed as Double that you can use anywhere, then try this:
Create a new Module (not a Class Module).
Rename the Module from Module1 to Weightage.
Put this code in Weightage:
Private Function ConvTohr(val As Integer) As Double
ConvTohr = Round((val / 60), 2)
End Function
Public Property Get Var1_Weightage() As Double
Var1_Weightage = ConvTohr(3)
End Property
Public Property Get Var2_Weightage() As Double
Var2_Weightage = ConvTohr(11)
End Property
Public Property Get Var3_Weightage() As Double
Var3_Weightage = ConvTohr(2)
End Property
Public Property Get Var4_Weightage() As Double
Var4_Weightage = ConvTohr(9)
End Property
Public Property Get Var5_Weightage() As Double
Var5_Weightage = ConvTohr(0)
End Property
Screenshot proof:
(See output in the Immediate pane):
I want my program to take a variable, and find letters A-Z. I have made this section of my program in a module to be shared between 2 different forms.
variables are passed from form1 and are processed by the module and then sent back again to form1. the problem is I think some sort of bug in the code but I cant identify it.
Public Function UPCASES(ByRef password1, points) As Boolean
Dim intersection As IEnumerable(Of Char)
intersection = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".Intersect(password1)
'System.StackOverflowException error ^^^^^^^^^^^^^^^^^^^^^^^^^
If intersection.Count() = 1 Then
points = 5
Else
points = 0
End If
Return UPCASES(password1, points)
End Function
You are calling the method itself at the method end, that causes the StackOverflowException:
Return UPCASES(password1, points)
I guess this method should check if the password contains uppercase letters, then use:
Dim containsUpperCase = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".Intersect(password1).Any()
So no need to create a method just for this one-liner, if you need a method:
Public Function ContainsUpperCaseLetter(password1 As String) As Boolean
Return "ABCDEFGHIJKLMNOPQRSTUVWXYZ".Intersect(password1).Any()
End Function
Side-note: you should change your default project settings to use Option Strict ON(Off is default unfortunately). Then you will be able to write much more safe, robust and performant code after you have learned a lot about .NET types because you have to fix the compiler errors.
We have a VB.NET project which I am doing some refactoring in. A lot of current functions require a userId to be passed in as a parameter. For example:
Private Function Foo(userId As Integer) As String
Return "Foo"
End Function
But now, I have made this userId paramater no longer needed in much of our code.
I was thinking I would just remove all the userId parameters from all of the functions that don't need them anymore, and try re-building the project to see what calling code needs to change. To my surprise though, the code built successfully.
I learned that you can call a function which returns a string and doesn't take any parameters, but still pass in an Integer value. VB.NET builds/executes this code as if you were trying to invoke the function and then get the character from the String at the specified index. For example:
Imports System
Public Module MyModule
Private Function Foo() As String
Return "Foo"
End Function
Public Sub Main()
Console.WriteLine(Foo(0)) ' prints 'F'
Console.WriteLine(Foo(1)) ' prints 'o'
End Sub
End Module
(.NET Fiddle)
I want my build to fail in this case. I have tried using Option Strict On and Option Explicit On but neither seem to change this behaviour.
Is there anyway to make this kind of function invocation invalid in my VB.NET project?
Create an overload with no parameters which is a copy of the original function in every other respect.
Public Function Foo() As String
Return "Foo"
End Function
Now change the type of userId to something else (not Object or anything numeric etc.)
Public Function Foo(userId As DateTime) As String
Return "Foo"
End Function
Since there is an overload with a parameter, the compiler thinks you mean to call that, instead of indexing the chararray. So you have compile errors. Fix the errors
Then delete the original function.
I am trying to check if an output column of my script component is NULL.
I tried to use the Row.Column_IsNull, but when I try to do the following:
If Row.Column_IsNull = True Then
// do something
End If
I get an error " Property Row.Column_IsNull is WriteOnly".
What the problem is
The key error in the above was is WriteOnly. When you are referencing columns in Script Components as Transformation, you can specify whether they are ReadOnly, ReadWrite.
When acting as Source, you don't have that option. It's WriteOnly (logically) and they don't even give you the option of the above dialog. So, when you're in your Source and attempt to access write only properties like the following code demonstrates, it breaks.
Public Overrides Sub CreateNewOutputRows()
Output0Buffer.AddRow()
' this is logically wrong
If Output0Buffer.Column_IsNull Then
End If
End Sub
The resolution is that you need to inspect whatever you are assigning into OutputBuffer0.Column prior to making the assignment (or create a separate boolean flag) to keep track of whether the current value was populated.
What the problem isn't
Keeping this here since I already ran down this rabbit hole
Since _IsNull is boolean, you can skip the explicit test and simply use
If Row.Column_IsNull Then
Originally, I had thought this was the classic C-like language issue of assignment (=) vs equality (==) but as #John Saunders was kind enough to point out, this was VB.
That said, the supplied code should work (it does for me).
Public Overrides Sub Input0_ProcessInputRow(ByVal Row As Input0Buffer)
Dim x As String
If Row.Src_IsNull = True Then
x = "" ' do nothing
End If
End Sub
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