in VB.NET it is possible to omit parentheses when you call a parameterless function. However this can be very confusing because developers could think that a statement is accessing a property instead of a method. this could result in a performance drop if you are calling the method again and again instead of storing the result in a temp variable.
is there an option in VS2008 or a compiler option to force parentheses on statements that are calling a method?
and if so, would it be also possible that VS will insert missing parentheses automatically if you "format document" (Menu: Edit - Advanced)?
thanks, toebens
No there is no such option in the VB.Net compiler. Parens are optional and there is no warning or error that exist for using a lack of them.
The other reason is that VB.Net is a language which tries to be flexible and get the syntax out of the way of the user. This type of restriction goes against this general philosophy.
Another issue to consider is that it's not a universally enforceable restriction. VB.Net allows for late binding scenarios whenever option strict is set to off. In these scenarios it is impossible for the VB.Net compiler to determine ahead of time if a particular call is a property, statement or not a valid call at all.
Related
Where in the VB6/VBA project references do Array(), LBound(), and UBound() come from..? When I'm typing in code, they don't appear in the Autocomplete list (ctrl+space), they don't get autocompleted, and they must be typed out completely before the text editor recognizes them. And only when a left-parenthesis is typed will ToolTipText pop up with the command syntax. Also, they do not appear anywhere in Object Explorer.
There's probably a basic concept in play here that I'm not aware of. And it makes me wonder, what other commands/statements/keywords are hidden in the same way..? Is there a list somewhere..? I googled for info but didn't find anything, probably because I don't know what I'm looking for and using the wrong search terms.
I ask these questions because I have the habit of prefixing many VB6 built-in functions like this: VBA.Left(), VBA.Len, VBA.Instr(), and so on. But I can't figure out what reference prefeix to use with Array(), LBound(), and UBound(), or perhaps they're so basic to VB6 that they don't have one.
I do this prefixing because years ago I was working on a large project, and there were functions I was trying to use with the same name in different reference libraries. I was a newbie and it took me a while to figure out, and it was causing tremendous problems since the functions were just NOT working the way I thought they were supposed to. It was then that I developed the prefixing habit after I figured it out. It's just easier that way, and always ensures the expected functions are being used.
The reason that they don't appear as IntelliSense options (and also why they don't appear in the Object Browser) is that they aren't declared in the VBE7.dll typelib for some reason that's beyond me. The Array function is implemented in the .dll as rtcArray. The utility of knowing that is dubious, in that its sole argument is a ParamArray, which means that if you called it directly from VBE7.dll you would need to create an array to have it feed you back the same array... This partially explains why it isn't on the typelib - a COM call would need to do the same thing, and the marshaling would basically be doing the same thing as what you'd expect the function to return.
LBound and UBound don't even appear as functions in the export table, so my guess is that they are handled more like "keywords" than first class functions internally. This makes some sense, in that it's fairly trivial to check the bounds of a SAFEARRAY if you have a pointer to the automation struct (you just index into the rgsabound array at the end of it and read the cElements and lLbound from it. Again a guess, but I'd assume that this allows for flexibility in letting LBound and UBound function with both fixed length and variable length arrays. In the fixed case, the array is basically managed as a block of memory with an indexer (more like a VT_CARRAY than a VT_SAFEARRAY). I'd imagine that handling this internally was easier or more convenient than providing first-class functions.
You won't find Debug in the Object Browser either, nor its methods Assert and Print.
You won't find Statements that are used like methods, like Open, Close, Get and Put, which is why you don't get any Intellisense when you use those statements, and the syntax must be memorized.
You will find Load and Unload as members of VBA.Global, but it's not clear what they belong to otherwise, and their arguments are late-bound Objects. The VBA documentation states that Load and Unload are Statements, even though the Object Browser shows them as Methods.
Keep in mind that you can move the order of references and it will make a difference. Try moving VBA to the top or near the top of your list of references. I believe that if something else also defines a BASIC keyword, it steals it, in a sense. I once had Right disappear and because I was not aware of the order of references, had to change all references of Right to VBA.Right. It's possibly the same with the ubound, lbound, or array.
I have de-compiled some old code from a legacy VB.NET app using ILSply and this line has appeared:
Operators.ConditionalCompareObjectEqual(safeDataReader["isLoader"], -1, false)
I'm aware this is compiler generated, but its not advised that this code is used in application source code. My question is why is this the case and what should it be in 'normal' code?
The documentation for the method says it right there:
Represents the overloaded Visual Basic equals (=) operator.
Why? I don't "know", but it's easy to make an educated guess.
The semantics of the "=" operator in VB.NET are just a bit different from those of C# and the standard Object.Equals(). The semantics are inherited from VB6 and cannot be changed for backward compatibility reasons. Obviously this method implements the VB6 semantics for the compiler.
It would make an interesting read to come up with a systematic analysis of the differences.
Further thoughts:
The reason it's "not recommended" is because there is no reason to call the method from VB.NET: just use =. In C#, there is no particular reason to invoke the VB6 semantics so the method doesn't make a lot of sense there either.
Obviously, if you are compiling C# code generated from VB.NET, then those are special circumstances: calling the method is the right thing to do, unless you're willing to take the time to analyze the code and prove to yourself that the standard = cn be substituted safely.
I am reviewing some code and I realized I don't remember the correct terminology for something. I believe if I had the following code
pnlOne.Visible = False
Would the "visible" part be considered a method, function, or what? I am learning VB alongside JavaScript, and in JS it would be a method. Is it the same for vb?
In VB.net, that is a "property". Properties in VB.net and C# as essentially glorified methods for getting and setting a value. (They actually compile down to something like get_Visible and set_Visible methods.)
pnlOne is an instance of a class and Visible is its property
Visible could be either ..
a Property; or
a Field (called "Member Variable" in VB)
.. depending on how it is declared. Both Properties and Fields are specializations of "Members"1. See Differences Between Properties and Variables in Visual Basic.
I suspect Visible is a Property in this case, and it will be for all standard Control types .. however, to verify this either way requires knowledge of the Type of the object named by pnlOne.
1
Methods (or "Sub/Function Procedures") are a different kind of Member and it is not appropriate to call either a Property or Field a "Function" or a "Method". (Note: various references inconsistently make a distinction between a Method and a Procedure; in VB.NET they an be thought of as synonyms.)
Nit: the correct term in JavaScript would be property; properties can evaluate to function-objects and can thus also can be considered methods when they do so - usually when this is used meaningfully. In any case, the code would have to be different (e.g. jsObj.set_Visible(true)) if a method was used.
Late binding is not allowed and that's how we want it.
Depending on whether our program is running on a LAN or the Internet, we need to dim an object as one of two types.
We use an if...then statement to ascertain whether or not we are running on a LAN or the Internet.
When we declare our object inside the if...then statement, we have declared in the wrong scope and cannot use the object.
When we declare it as an 'Object' type and use DirectCast inside an if...then statement, we receive a late binding error.
How can we get around this problem without turning off Option Strict?
I haven't used vb.net - so consider the source. But can't you declare each of the types to be a subclass of another type, and have that superclass type as the declared type of your object?
As far as I know that's essentially what I'm doing when I try to use the Object class for variable initialization.
However, when I attempt a DirectCast to narrow it down to the type I need, it still throws the late binding error.
In VB.NET, which is better to use: function overloading or default parameters?
if the parameters are optional (i.e. the overloads are a subset of the parameters that the full procedure signature accepts) then default or optional parameters would make more sense.
If the overload is allowing a different type for the parameter or is a semantically different parameter that will be interpreted differently by the routine then overloads would make more sense.
Is the code going to be used by other languages? If so, that swings the balance towards overloads while still bearing Hamish's answer in mind. In particular, C# doesn't support optional parameters - yet...
Admittedly this wouldn't actually prevent someone using your code from C#, it just might be a pain for them.
If there are a lot of parameters and they logically represent something, you might want to consider encapsulating them together, in the same way that Process works with ProcessStartInfo. That's particularly nice from C# due to object initializers.
If this is for construction, you might also consider the builder pattern as a variant of this. For instance, in Protocol Buffers I can do something like:
Person jon = new Person.Builder { Name="Jon", Age=32,
Spouse="Holly", Kids=3 }.Build();
which ends up being very readable while still creating a person in one go (in one expression, and without having to mutate the person itself - indeed the message type is immutable; it's only the builder which isn't).
FYI
If you want to add a parameter to a function or method that is called from other assemblies, then:
You can overload by making an additional function with the extra parameter.
Or you can add an optional parameter, BUT: You have to recompile all of the assemblies that call this function, even if they don't need to use the new optional parameter! This is not usually what people expect (expecially those used to how VB6 works). Basically, you can't slip in a new optional parameter to a function and expect it to be totally backwards compatible. Also, as I understand it, if you change what the default value is, you need to rebuild all calling assemblies for the change to work.