Can someone please fill in the blanks for me, including a brief description of use and perhaps a code snippet? I'm well aware of the top two in particular, but a little hazy on the last one especially:
() - Used for calling a function, object instantiation, passing parameters, etc.
{} - Used for defining and adding elements to arrays or sets.
[] - Used for forcing an object to be treated as a type rather than keyword.
<> - Used for... ?
For Example, I see stuff like this all the time, but still not quite sure what the brackets means...
<TemplateContainer(GetType(TemplateItem))> _
Public Property MessageTemplate As ITemplate
VB.net uses parentheses for, among other things, arithmetic groupings and function parameters (both of which use parentheses in C#), as well as array subscripts and default-property parameters (both of which use brackets in C#), (indexers), etc. It also uses (Of ... ) to enclose a list of types (which would be enclosed in < ... > in C#, with no "Of" keyword.
Braces are used for array or set initialization expressions, and are also used when defining a generic type with multiple constraints (e.g. (Of Foo As {IEnumerable, IDisposable, Class})). Note that the latter usage is only permitted in constraints; it is alas not possible to e.g. Dim MyThing As {IEnumerable, IDisposable, Class}).
Braces are now also used for the New With {} construct:
Dim p = New Person With {.Name = "John Smith", .Age = 27}
Dim anon = New With {.Name = "Jack Smythe", .Age = 23}
Square brackets are used to enclose identifiers whose spelling would match that of a reserved word. For example, if a class defined a method called Not (perhaps the class was written in a language without a keyword Not), one could use such a method within VB by enclosing its name in square brackets (e.g. someVariable = [Not](5)). In the absence of the square brackets, the above expression would set someVariable to -6 (the result of applying the vb.net Not operator to the value 5).
Angle brackets, as noted elsewhere, are used for attributes. Note that in many cases, attributes are placed on the line above the thing they affect (so as to avoid pushing the affected variable past the right edge of the screen). In older versions of vb, such usage requires the use of a line-continuation mark (trailing underscore).
Angle brackets are also used for XML Literals and XML Axis Properties:
Dim xml = <simpleTag><anotherTag>text</anotherTag></simpleTag>
Console.WriteLine(xml.<anotherTag>.First.Value)
In this case it's used for the Attribute declaration. It can also be used in XML Literals as follows:
<TestMethod>
Public Sub ThisIsATest()
If 1 <> 0 Then
Dim foo = <root>
<child>this is some XML</child>
</root>
End If
End Sub
In VB.Net, <> is used to enclose Attributes.
VB.NET uses <> for attributes as well as to indicate "does not equal" (!=)
In your example it is just enclosing attributes. That same code in C# would be
[TemplateContainer(GetType(TemplateItem))]
public ITemplate MessageTemplate { get; set; }
This attribute is used in developing templated controls, which separate data from presentation. In other words, a templated control can retain the same functionality while changing it's appearance.
Related
I am debugging an application that runs on a server and users will access the application on another server. The application uses encryption and as part of the key, I am using the String.Reverse property.
Dim Mystring As String = "123abc"
Dim reverse = String.Format("{0},{1}", Mystring.Reverse)
The string reverse is different when I run it from one machine (RDP/Citrix Environment ASP.NET 4.6.1). The value is:
System.Linq.Enumerable+<ReverseIterator>d__a2`1[System.Char]
The same string, but ran from another machine (RPD non-Citrix Environment ASP.NET 4.5.2). The value of reverse is:
System.Linq.Enumerable+<ReverseIterator>d__73`1[System.Char]
Why are the values different in the different environments?
Look at this line first:
Dim reverse = String.Format("{0},{1}", Mystring.Reverse)
Specifically, this expression:
Mystring.Reverse
Reverse is a function, not a property, but it's missing the parentheses (). The trick here is the String.Format() method accepts the base Object type as an argument, and compiler is able to treat the MyString.Reverse expression as a delegate type that is convertible to object. The values you see in your output are the result of calling .ToString() on that function delegate. It's the type name for the function, rather than anything to do with the value of your MyString object. Since that type is dynamically and randomly generated at runtime, you'll see different values not only on different platforms, but different runs on the same computer.
In the VB6 era, it was normal to call methods without the parentheses. In the .Net world, always use parentheses when you call a method.
What you want is this:
Dim reverse As String = String.Format("{0},{1}", Mystring.Reverse())
Even here, you're missing the second argument to match the format string. I doubt you'll get the result you expect.
Finally, reversing a string as the key seems very wrong when it comes to encryption. You are using a real cyrptogrpahic algorithm from the System.Security.Cryptography library, right? Right!?
You are not outputting the value of the reversed String but the name of the type used to perform the reversal. That type is dynamically created and randomly named. The "d" in those two names means "dynamic" and the "a2" and "73" parts are random.
Basically, what you perceive to be an issue is not an issue. The problem is that you're not actually creating a String from the reversed output. You say "String.Reverse property but that is NOT a property. It is a method and it is not a member of the String class but rather an extension method on the IEnumerable(Of T) interface. You are treating your String as an enumerable list of Char values and reversing that. If you want a String from that then you need to create one, i.e.
MyReversedString = New String(Mystring.Reverse().ToArray())
That will push the contents of your iterator into an array and then create a new String object from that array.
I'm not successful in using the Bang (!) operator without it's argument being hardcoded, i.e., Me.VBProject.References!Excel. In this example, the Excel reference is hardcoded.
Out of frustration I've tried all permutations I can think of in an attempt to utilize it:
[Me.VBProject.References!(str)]
[Me.VBProject.References! & (str)]
["Me.VBProject.References!" & str]
["Me.VBProject.References!" & (str)]
and many more with parens added to ensure proper pre-evaluation including the longhand Application.evaluate method. Nada!
No, you can't do that.
The bang operator is just a shortcut for calling the default member of the object, and passing the text after the bang as a string to the first parameter of the default member:
The bang notation:
Me.VBProject.References!Excel
is exactly equivalent to:
Me.VBProject.References.Item("Excel")
and, because it is the default member, you can omit the Item function call:
Me.VBProject.References("Excel")
So, to use your (really badly named) variable str:
str = "Excel"
Debug.Print Me.VBProject.References.Item(str).Name
This is an X-Y problem.
Bang notation is a means to an end.
It's one of the tools made available to you, to retrieve an item from a collection.
Nothing more, nothing less.
What you want isn't to use the bang operator with a variable.
What you want is to retrieve an item from a collection using a variable.
Collection types have a default member, typically named Item. Default members can be specified explicitly, or implicitly accessed:
Dim foo As New Collection
foo.Add Item:=42, Key:="test"
Debug.Print foo.Item("test") 'explicit reference to the default member
Debug.Print foo("test") 'implicit reference to the same default member
The bang operator is just another way to make an implicit call to the collection's default member:
Debug.Print foo!test
All 3 Debug.Print statements above will call the foo.Item default member to output the 42 associated with the key "test".
Square brackets
As you can see, what comes immediately after the ! operator is really a string literal. Because a string literal can contain whitespace, the VB6/VBA parser needed a way to support them.
That's what the [square brackets] are for:
foo.Add 72, "spaces in the key"
Debug.Print foo![spaces in the key]
When they're not delimiting a string literal for bang notation, square brackets are usually1 interpreted as a run-time expression for the host application to evaluate. For example this is legal (though questionably advisable) in Excel VBA:
Debug.Print [A1]
The VBA parser identifies a bracketed expression and defers its evaluation to the host application - here Excel; at run-time, the instruction ultimately equates to:
Debug.Print ActiveSheet.Range("A1").Value
If you don't believe the evaluation of a bracketed expression is deferred to the host application, consider what needs to happen for this instruction to print 4:
Debug.Print [Sum(2,2)]
Therefore, every single one of the attempts/permutations in your post missed the mark and made Excel try to evaluate an expression that only VBA would be able to resolve, because Me.VBProject.References means absolutely nothing to Excel.
Square-bracket expressions should usually be avoided, because you lose compile-time checks and any error can only be caught at run-time.
1Usually, because they can also be used in some identifiers,
for example in Enum types, to make a [_hidden] enum member.
Bottom Line
Bang notation is a way to retrieve an item from a collection by leveraging default members and making string literals look like an identifier. You can't make it work without "hard-coding" the string literal, because it requires a string literal.
If you want to parameterize the collection retrieval, you can't use the bang operator.
It's useful for typing the code faster. If you don't know exactly how it works and what it does for you though, it's a double-edged blade that hides what's really going on and ultimately makes the code harder to read and understand. Code shouldn't be written just to be run. Code should be written to be read and understood.
Note: Bang notation isn't actually only for collections. It actually passes its argument as a string literal to the first parameter of anything that has a default member. I would strongly advise avoiding it for anything other than a collection class though (e.g. Collection.Item, Workbooks.Item, Worksheets.Item, Recordset.Fields, etc.), for the sake of future maintainers' sanity.
What is the meaning of the square brackets around the name of a property in the definition ?
Example :
Public Property [Date] As String
To use reserved keywords as identifiers, the brackets must be used to
distinguish between the identifier and the keyword:
dim [String] As String
public sub [Stop]
end sub
On msdn it says:
Any program element — such as a variable, class, or member — can have
the same name as a restricted keyword. For example, you can create a
variable named Loop. However, to refer to your version of it — which
has the same name as the restricted Loop keyword — you must either
qualify it by preceding it with its full namespace, or enclose it in
square brackets ([ ]), as in the following examples:
Reference here
This syntax allows you to use a reserved word as the name of a member or variable. Not recommended though IMHO from a code maintainability point of view (though see comments below for an alternative point of view on this particular point)!
Particularly not recommended if you're going to declare a property called "Date" as a string, but that's a separate issue...
Date is a reserved keyword in VB.NET, but can be used as a property or variable name if enclosed in square brackets:
http://msdn.microsoft.com/en-us/library/ksh7h19t(v=vs.90).aspx
In the example below, what would you name the parameter given that it is used to initialize the property FromDate?
For class constructor methods, I like to have the name of the constructor parameter variable match the name of the property which is being initialized. For example, the parameter "fromDate" is used to initialize the module level variable "_FromDate" with the statement _FromDate = fromDate. Likewise, I could have alternatively written Me.FromDate = fromDate.
Proponents of C#'s case sensitivity would probably say that using a leading lower cased letter for the param variable name, which I believe is MS convention, is an acceptable approach to distinguish it from the Property of the same name but different casing.
However, VB is not case sensitive, which I generally appreciate. In the following example, I am using a param name that matches the property name, 'fromDate," and VB refers to the local instance when there is ambiguity. However, many would probably argue that this "ambiguity" introduces the opportunity for the developer to get confused and not realize which variable is being used. For example, my intent below was to have TWO params passed in, "fromDate" and "toDate" but I accidentily ommited one and as a result, the VB.NET did not warn me of the mistake because it assumed that the statement _ToDate = ToDate was equivalent to _ToDate = Me.ToDate instead of informing me that the variable on the right side of the assignment statement was undeclared.
Public Class Period
Property FromDate As Date
Property ToDate As Date
Public Sub New(ByVal fromDate As Date)
If fromDate > ToDate Then
Throw New ArgumentException("fromDate must be less than or equal to toDate")
End If
_FromDate = fromDate
_ToDate = ToDate
End Sub
End Class
So what is the best solution for VB.NET?
In my judgement, we should have a convention for prefixing all parameter variable with a prefix, but hasn't the use of prefixes been discouraged by Microsoft? For example:
Public Sub New(ByVal paramFromDate As Date, paramToDate As Date)
..or maybe it could be shortened to pFromDate, pToDate...
Whatever approach is taken, I feel that it should be a consistant approach that is used throughout the application.
What do you do?
Use the clearest code possible, which I would suggest is not a prefix. I think using the same name (first letter lowercased) is the clearest code. To avoid the problem encountered I'd rely on a tool, like compiler warnings, FxCop, or ReSharper to alert me that I'm assigning something to itself, since that is almost certainly a mistake in all scenarios.
I know this is against all Microsoft convention, but we use v_ for ByVal parameters, r_ for ByRef parameters and m_ for Module level variables. This allows you to have
m_FromDate = v_FromDate
And you can see straight away what is going on without needing to check the definitions of the variables. I think the biggest argument for non-Hungarian was that modern IDE's allow you to see type on hover over, and changing the type will leave incorrect variables. This scope prefix doesn't clash with that theory and also with CodeRush and ReSharper you can update every instance of a variable if it is required.
Personally, I prefer the _ prefix convention, but there are others I like too. In PL/SQL, my parameters are prefixed with in_, out_, or io_ for in, out, or in/out parameters.
I dislike using only upper and lower cases to distinguish in any language.
Some code to illustrate my question:
With Test.AnObject
.Something = 1337
.AnotherThing = "Hello"
''// why can't I do this to pass the object itself:
Test2.Subroutine(.)
''// ... and is there an equivalent, other than repeating the object in With?
End With
There is no way to refer to the object referenced in the With statement, other than repeating the name of the object itself.
EDIT
If you really want to, you could modify your an object to return a reference to itself
Public Function Self() as TypeOfAnObject
Return Me
End Get
Then you could use the following code
With Test.AnObject
Test2.Subroutine(.Self())
End With
Finally, if you cannot modify the code for an object, you could (but not necessarily should) accomplish the same thing via an extension method. One generic solution is:
' Define in a Module
<Extension()>
Public Function Self(Of T)(target As T) As T
Return target
End Function
called like so:
Test2.Subroutine(.Self())
or
With 1
a = .Self() + 2 ' a now equals 3
End With
I suspect you'll have to repeat yourself. If the expression (to get the object) is expensive, then perhaps drop it into a variable first, and either use that variable in the With, or drop the With completely:
tmp = Test.AnObject;
tmp.Something = 1337;
...
Test2.Subroutine(tmp);
As others have said, you're going to have to write
Test2.Subroutine(Test.AnObject)
This is a good example of why it's worth being a little careful with the With construct in VB.Net. My view is that to make it worth using at all, you really need to be setting more than one or two properties, and/or calling more than one or two methods on the object in the With statement.
When there are lots, and you're not interspersing the .SomeProperty = , or .DoSomething, with other things, it's a terrific aid to readability.
Conversely, a few dots sprinkled amongst a load of other stuff is actually a lot harder to read than not using With at all.
In this case, . characters on their own could easily get lost visually, although of course, it would be syntactically consistent.
I guess they just chose not to implement it. VB isn't really the sort of language where they want to encourage single character language elements, and as a heavy user of VB.Net, I broadly agree with that.
Bottom line: if you're using a With clause with many contained elements, having to refer to the object itself isn't that big a deal. If you're using it with just one or two, maybe better not to use a With clause in the first place.
I'm not sure this is an "answer", per se, but it does illustrate another reason to want a short-hand reference to the parent in a With.
Here's a code sample using a "bare With" (that's what I call it, anyway):
With New frmMySubForm
.lblLinkLabel.Links.Add(New LinkLabel.Link With {.Name = "link", .LinkData = "someUrl", .Start = .lblLinkLabel.Text.IndexOf("link"), .Length = "link".Length})
...
End With
But you actually can't code that because in the term .Start = .lblLinkLabel.Text.IndexOf("link") the compiler expects anything starting with . to be a member of LinkLabel.Link, which .lblLinkLabel isn't.
What would be good, I think, is to be able to write something like:
With New frmMySubForm
.lblLinkLabel.Links.Add(New LinkLabel.Link With {.Name = "link", .LinkData = "someUrl", .Start = Me.lblLinkLabel.Text.IndexOf("link"), .Length = "link".Length})
...
End With
where Me in this scope is taken to be New frmMySubForm.
Yes, I realize that I'm being picky and I could easily assign a variable, etc. But the example form is something I use a lot simply out of preference.