I have searched high and low for documentation on how to use this feature. While the loop I could write would be simple and take no time, I really would like to learn how to use this.
Basically I have a class, say, Widget, with a Save() sub that returns nothing. So:
Dim w as New Widget()
w.Save()
basically saves the widget. Now let's say I have a generic collection List(Of Widget) name widgetList(Of Widget) and I want to run a Save() on each item in that list. It says I can do a
widgetList.ForEach([enter Action(Of T) here])
....but how in the F does this work??? There is no documentation anywhere on the intrablags. Help would be much much appreciated.
well, I'm really outdated now... :-) but in VB it's:
widgetList.ForEach(Sub(w) w.Save())
or, more complicated:
widgetList.ForEach(New Action(Of Widged)(Sub(w As Widged) w.Save()))
If you're using VB9 (VS2008) I don't think you'll be able to use an anonymous function easily - as far as I'm aware, anonymous functions in VB9 have to be real functions (i.e. they have to return a value) whereas Action<T> doesn't return anything. C# 2's anonymous methods and C# 3's lambda expressions are more general, which is why you'll see loads of examples using List<T>.ForEach from C# and very few using VB :(
You could potentially write a MakeAction wrapper which takes a Function<T,TResult> and returns an Action<T>, but I suspect other restrictions on VB9 anonymous functions would make this impractical.
The good news is that VB10 has much more anonymous function support. (C#4 and VB10 are gaining each other's features - I believe MS is trying to go for language parity from now on, to a larger extent than before.)
Until then, to use List<T>.ForEach you'll need to write an appropriate Sub and use AddressOf to create a delegate from it. Here's a small example:
Imports System
Imports System.Collections.Generic
Public Class Test
Shared Sub Main()
Dim names as New List(Of String)
names.Add("Jon")
names.Add("Holly")
names.ForEach(AddressOf PrintMe)
End Sub
Shared Sub PrintMe(ByVal text as String)
Console.WriteLine(text)
End Sub
End Class
new Action(Of T)(AddressOf Widget.Save)
is OK if Widget got a public function called Save.
All others comment are false when I try it.
Assuming that VB does not support lambda expressions, you can create an instance of the Action(of T) delegate in VB using this syntax:
new Action(Of T)(AddressOf Widget.Save)
The below should work although I'm not up to speed on VB.Net so you may need to adjust accordingly.
widgetList.ForEach(w => w.Save())
Related
Specifically aimed at winforms development.
I suspect that the answer to this is probably No but S.O. has a nice way of introducing me to things I didn't know so I thought that I would ask anyway.
I have a class library with a number of defined methods therein. I know from personal experimentation that it is possible to get information about the application within which the class library is referenced. What I would like to know is whether it would be possible to get information about the value of a property of a control on a form when a routine on that form calls a method in my class library without passing a specific reference to that form as a parameter of the method in the class library?
So purely as an example (because it's the only thing I can think of off the top of my head). Is there a way that a message box (if it had been so designed to do so in the first place) could 'know' from which form a call to it had been made without that form being specifically referenced as a parameter of the message box in the first place?
Thanks for any insights you might have.
To address the example of the MessageBox, in many of the cases you can use the active form. You can retrieve it by using Form.ActiveForm. Of course, as regards the properties that you can request, you are limited to the properties provided by the Form or an interface that the Form implements and that the method in the other assembly also knows. To access other properties you can use Reflection, but this approach would neither be straightforward nor would it be clean.
In a more general scenario, you could provide the property value to the method as a parameter. If it is to complex to retrieve the value of the property and the value is not needed every time, you can provide a Func(Of TRESULT) to the method that retrieves the value like this (sample for an integer property):
Public Sub DoSomethingWithAPropertyValue(propValFunc As Func(Of Integer))
' Do something before
If propertyValueIsNeeded Then
Dim propVal = propValFunc()
End If
' Do something afterwards
End Sub
You call the method like this:
Public Sub SubInForm()
Dim x As New ClassInOtherAssembly()
x.DoSomethingWithAPropertyValue(Function() Me.IntegerProperty)
End Sub
I kind of question your intentions. There's no problem sending the information to a function or the constructor.
Instead of giving the information to the class, the class would ask for the information instead using an event.
Module Module1
Sub Main()
Dim t As New Test
AddHandler t.GetValue, AddressOf GetValue
t.ShowValue()
Console.ReadLine()
End Sub
Public Sub GetValue(ByRef retVal As Integer)
retVal = 123
End Sub
End Module
Class Test
Public Delegate Sub DelegateGetValue(ByRef retVal As Integer)
Public Event GetValue As DelegateGetValue
Public Sub ShowValue()
Dim val As Integer
RaiseEvent GetValue(val)
Console.WriteLine(val)
End Sub
End Class
this is my first post here.
I like to have some advice on designing a new module for our software.
It's written in vb6 and i want to rewrite it in vb.net. So I want to refactor it.
It does the following:
We got many templates for OpenOffice Documents. (about 300)
Each one has an unique identifier which is in a database and comes as the input.
Dending on this number i want to create the document. e.g. calc or writer or later something else.
Then call a method named doc[template_num] or sth.
I read about invoking methods. I think this as a good way to dynamically call methods by number. Tried to do this. I think I understood now how it works.
But I dont know how to handle the document type.
I want to reuse big parts of code due to all calc documents are created equal at the beginning. But filling the cells is just bit diffrent.
I dont know how to inherit and do method calls with invoke.
Maybe someone has a little code snip for me which can explain this to.
Or maybe some other good idea how to handle this problem.
I am thankful for any new thought on this.
You could, of course, just have a giant Select Case block, like this:
Public Sub CreateDoc(templateNum As Integer)
Select Case templateNum
Case 1
CreateDoc1()
Case 2
CreateDoc2()
Case 3
CreateDoc3()
End Select
End Sub
If you had a fairly small number of case statements that would probably be the better, simpler method. If however, as you described, you have many different possible ID's to look for, then that becomes impractical and I can appreciate your desire to invoke the correct method without a big Select Case block.
However, before I get into that, I feel like I should give you another option. Perhaps you don't really need to have that many different methods. Is it possible, for instance, that half of the template ID's actually all need to be handled in the same way, and the only difference is the template file name that needs to be different. If so, it is conceivable that the Select Case block wouldn't need to be that big. For instance:
Public Sub CreateDoc(templateNum As Integer)
Select Case templateNum
Case 1 To 100
CreateWriterDoc(GetTemplateFilePath(templateNum))
Case 101 To 200
CreateCalcDoc(GetTemplateFilePath(templateNum))
End Select
End Sub
Private Sub CreateWriterDoc(templateFilePath As String)
' Launch Writer with given template file
End Sub
Private Sub CreateCalcDoc(templateFilePath As String)
' Launch Calc with given template file
End Sub
Private Function GetTemplateFilePath(templateNum As Integer) As String
' Retrieve template file path for given ID
' (from DB, Array, List, Dictionary, etc.) and return it
End Sub
To me, that seems like a much simpler solution, if such a thing is possible. If not--if you really have entirely different logic which needs to be executed for each template ID, then there are several ways to do it. The first option would be to create a list of delegates which point to the appropriate method to call for each ID. For instance, you could store them in an array, like this:
Dim createDocDelegates() As Action =
{
AddressOf CreateDoc1,
AddressOf CreateDoc2,
AddressOf CreateDoc3
}
So now, those three delegates are indexed by number (0 through 2) in an array. You can invoke them by number, like this:
createDocDelegates(1).Invoke() ' Calls CreateDoc2
Or, if your ID's aren't sequential, you may want to use a Dictionary(Of Integer, Action), instead, like this:
Dim createDocDelegates As New Dictionary(Of Integer, Action)()
createDocDelegates.Add(1, AddressOf CreateDoc1)
createDocDelegates.Add(7, AddressOf CreateDoc7)
createDocDelegates.Add(20, AddressOf CreateDoc20)
Then you can call one by ID, like this:
createDocDelegates(7).Invoke() ' Calls CreateDoc7
Another option would be to create an Interface for an object that creates a document, like this:
Public Interface IDocCreator
Sub CreateDoc()
End Interface
Then you could implement a separate class for each type of template (each implementing that same interface). For instance:
Public Class Doc1Creator
Implements IDocCreator
Public Sub CreateDoc() Implements IDocCreator
' Do work
End Sub
End Class
Public Class Doc2Creator
Implements IDocCreator
Public Sub CreateDoc() Implements IDocCreator
' Do different work
End Sub
End Class
Then, you can create a list of those objects, like this:
Dim docCreators() As IDocCreator =
{
New DocCreator1(),
New DocCreator2()
}
Or:
Dim docCreators As New Dictionary(Of Integer, IDocCreator)()
docCreators.Add(1, New DocCreator1())
docCreators.Add(7, New DocCreator7())
docCreators.Add(20, New DocCreator7())
Then you can call one like this:
docCreators(1).CreateDoc()
The IDocCreator approach is very similar to the Delegate approach. Neither is the right or wrong way to do it. It depends on your style, what you are comfortable with, and your requirements. The main advantage of the IDocCreator approach is that you could easily add more properties and methods to it in the future. For instance, lets say that you also want to somewhere store a user-friendly, descriptive name for each template. It would be very easy to add a ReadOnly Property Name As String property to the IDocCreator interface, but if you go the list-of-delegates route, that would be more difficult and sloppy.
In any of the above examples, however, you still have to add the complete list of methods or delegates somewhere. So, while it's slightly less ugly than a giant Select Case block, it may still not be enough. If so, the technology you need to use is called Reflection. The System.Reflection namespace contains much of the reflection-related functionality. Reflection allows you to dynamically access and invoke portions of your code. For instance, you can use reflection to get a list of all of the properties or methods that are defined by a given class. Or you can use reflection to get a list of types that are defined by your assembly. Using reflection, it would be possible to get a method, by string name, and then invoke it. So, for instance, if you want to call the "CreateDoc1" method on the current object, you could do it like this:
Me.GetType().GetMethod("CreateDoc1").Invoke(Me, {})
Since you are calling it by its string name, you could build the method name via concatenation:
Dim methodName As String = "CreateDoc" & templateNum.ToString()
Me.GetType().GetMethod(methodName).Invoke(Me, {})
However, if you are going to use the reflection approach, instead of using the name of the method, like that, it would be cleaner, in my opinion, to use a custom attribute to tag each method. For instance, you could create an attribute class which allows you to decorate your methods like this:
<CreateDocMethod(1)>
Public Sub CreateDoc1()
' ...
End Sub
Then, at run-time, you can use reflection to find all of the methods that have that particular attribute and then invoke the right one.
The reason that I saved the discussion on reflection for last is because it is not as efficient and it can lead to brittle code. As such, it's best to only use reflection as a last-resort. There's nothing wrong with reflection, if you really need it, but, as a general rule, if there is another reasonable way to do something, which doesn't require reflection, then you probably ought to be doing it that other way.
VB.NET 2010, .NET 4
I have a basic question: I have a subroutine that I found somewhere online declared thusly:
Public Sub MyFunction(Of T As Control)(ByVal Control As T, ByVal Action As Action(Of T)) ...
I'm wondering about the (Of T As Control) part of the declaration after the sub's name. I see that T is used later in specifying the type of Control and in Action(Of T), but why is it done this way instead of just doing:
Public Sub MyFunction(ByVal Control As Control, ByVal Action As Action(Of Control)) ...
What does that part after the sub's name mean? What is its purpose? Thanks a lot and sorry for my ignorance.
That is VB.NET's generic method declaration syntax:
A generic type is a single programming
element that adapts to perform the
same functionality for a variety of
data types. When you define a generic
class or procedure, you do not have to
define a separate version for each
data type for which you might want to
perform that functionality.
An analogy is a screwdriver set with
removable heads. You inspect the screw
you need to turn and select the
correct head for that screw (slotted,
crossed, starred). Once you insert the
correct head in the screwdriver
handle, you perform the exact same
function with the screwdriver, namely
turning the screw.
(Of T) is a generic type parameter, adding As Control constrains the type of T to inherit from Control. You could write the method the second way, but you'd probably end up having to cast the Control to whatever inherited type, within the lambda expression in the Action, or in the body of MyFunction. Generics allow you to avoid that.
For example:
Sub Main()
Dim form As New Form()
Dim textBox As New TextBox
Dim listBox As New ListBox
MyFunction(textBox, Sub(c) c.Text = "Hello")
MyFunction(listBox, Sub(c) c.Items.Add("Hello"))
MyFunction2(textBox, Sub(c) c.Text = "Hello")
MyFunction2(listBox, Sub(c) CType(c, ListBox).Items.Add("Hello"))
End Sub
Public Sub MyFunction(Of T As Control)(ByVal Control As T, ByVal Action As Action(Of T))
Action(Control)
End Sub
Public Sub MyFunction2(ByVal Control As Control, ByVal Action As Action(Of Control))
Action(Control)
End Sub
It doesn't look too valuable in trivial cases, but it's invaluable for more complex cases.
As others have said, it's a constrained generic parameter. But no one has yet addressed this part of your question:
why is it done this way
The answer is in the action. If it were just declared as a Control, you wouldn't be able to do something like this, because not all controls have a .Text property*:
MyFunction(MyTextBox, Function(t) t.Text = "new value" )
The body of the function just needs to know that it's working on a control of some kind, but the Action(Of T) you pass to the function might want to know the actual type of the control.
Yes, all controls do have a .Text property. Let's pretend for a moment that some didn't
I'm not entirely sure what to call what C# does, so I haven't had any luck searching for the VB.Net equivalent syntax (if it exists, which I suspect it probably doesn't).
In c#, you can do this:
public void DoSomething() {
new MyHelper().DoIt(); // works just fine
}
But as far as I can tell, in VB.Net, you must assign the helper object to a local variable or you just get a syntax error:
Public Sub DoSomething()
New MyHelper().DoIt() ' won't compile
End Sub
Just one of those curiosity things I run into from day to day working on mixed language projects - often there is a VB.Net equivalent which uses less than obvious syntax. Anyone?
The magic word here is Call.
Public Sub DoSomething()
Call (New MyHelper()).DoIt()
Call New MyHelper().DoIt()
End Sub
Gideon Engelberth is right about using Call. It is the best option.
Another option is to use a With statement:
With New MyHelper()
.DoIt()
End With
I am using VB.Net and would like to use a LinkedList. Only problem is that it is a multithreaded application. I saw from MSDN that Syncroot is an explicit implementation of the ICollection Interface. I found people wanting to do similar things with List(Of T). It seems that the solution there is to cast the list to the interface.
I have tried to do what I would imagine to be a similar thing in VB.Net, basically:
Dim TestLinkedList = New LinkedList(Of Long)
SyncLock (Ctype(TestLinkedList, ICollection)).SyncRoot
.
.
.
End SyncLock
Is the above correct?
It will work, that's about all that can be said for it. SyncRoot was a mistake from .NET 1.1, there's no reason to continue the practice.
Dim list = New LinkedList(Of Long)
Dim listLock = New Object
...
SyncLock(listLock)
...
End SyncLock
ICollection.SyncRoot is generally considered a bad idea. You should either lock the collection itself, or lock on a separate lock object you create