I am creating a project in VBA to automate handling of asynchronous quasi-multithreading (mouthful, sorry). This revolves around creating and running multiple copies of a class which Implements a certain interface, and raises some known events when the async task is complete. The interfacing is similar to this example
My program calls the class to execute its code, and listens to the events raised, that's all working fine. Now my final task is to take any given class which Implements the appropriate interface, and make multiple copies to set running in parallel.
How do I make copies of a class which is passed to a routine?
How can I take a class reference and make several New versions?
Or in code, each one of my thread classes (the classes which handle the async class which is passed) will have a Worker property to save their task.
Private workerObject As IWorker
Public Property Set Worker(workObj As IWorker) 'pass unknown class with IWorker interface
'What goes here?
Set workerObject = workObj
'This won't work as then every thread points to the same worker
'I want something to create a New one, like
Set workerObject = New ClassOf(workObj)
'But of course that doesn't work
End Property
You would need to inspect the possible types and act accordingly:
Dim workerObject As IWorker
If TypeOf workObj Is ImplementingClass1 Then
Set workerObject = New ImplementingClass1
ElseIf TypeOf workObj Is ImplementingClass2 Then
Set workerObject = New ImplementingClass2
End If
Alternatively you could add a factory method to the interface:
Public Function CreateNew() As IWorker: End Function
Implement it in the classes:
Public Function IWorker_CreateNew() As IWorker
Set IWorker_CreateNew = New ImplementingClass1
End Function
And then:
Set workerObject = workObj.IWorker_CreateNew()
Related
I am coding an application that performs various measurements on 3D objects, using expensive API calls to extract geometric info from another application. These measurements and how they are defined by the user are stored in a Study class. This class must be serializable, so that the user can save a particular study with all of it's data to a hard drive, and then load it on another session.
Properties of the 3D object might be Length, Width, Height, BoundingBoxDimensions, Weight, etc. However, they are not just plain numbers - each property must also store flags if they are requested to be calculated by the user, if they have been evaluated, an error flag, etc.
Some of these properties depend on other properties to be evaluated first (for example, if user requests the value of BoundingBoxDimensions, then Length, Width and Height must be calculated first. Therefore, each object property also stores a list of properties it depends on. If it is requested, and it sees that it's dependents are not yet evaluated, then it calls these dependents to be evaluated first.
The goal of this strategy is to minimize the number of API calls and save computation time. For example, if user requests Length and Width to be evaluated, only 2 API calls would be made (there is no reason to evaluate Height). If user calls for BoundingBoxDimensions, then 3 API calls have to be made, but no more.
However, this approach also means that I have to use delegate methods to allow different evaluation methods to be assigned to each object property.
This is my code so far.
'Main class for a specific 3D object measurement study. It must be serializable.
Public Class Study
'3D Object properties. They are bound to in WPF, but that part is omitted in this example.
Public Property Length As New ObjectProperty() With {.Name = "Length", .DependencyProperties = Nothing, .EvaluatingMethod = AddressOf GetLength}
Public Property Width As New ObjectProperty() With {.Name = "Width", .DependencyProperties = Nothing, .EvaluatingMethod = AddressOf GetWidth}
Public Property Height As New ObjectProperty() With {.Name = "Height", .DependencyProperties = Nothing, .EvaluatingMethod = AddressOf GetHeight}
Public Property BoundingBoxDimensions As New ObjectProperty() With {.Name = "BoundingBoxDimensions", .DependencyProperties = New List(Of ObjectProperty) From {Length, Width, Height}, .EvaluatingMethod = AddressOf GetBoundingBoxDimensions}
'Container for all properties to enable looping.
Public Property ObjectProperties As New List(Of ObjectProperty) From {Length, Width, Height, BoundingBoxDimensions}
'Called by the UI to set Requested flags on the object properties that the user requires to be evaluated.
Public Sub SetObjectPropertyRequests(requestedObjectPropertyNames As List(Of String))
For Each requestedObjectPropertyName In requestedObjectPropertyNames
For Each ObjectProperty In ObjectProperties
If requestedObjectPropertyName = ObjectProperty.Name Then ObjectProperty.Requested = True
Next
Next
End Sub
'Check Requested flags and evaluate.
Public Sub CalculateRequestedProperties()
For Each ObjectProperty In ObjectProperties
If ObjectProperty.Requested Then Dim tempValue As Object = ObjectProperty.Value
Next
End Sub
'Actual evaluating functions attached to the object properties, making complicated and expensive API calls. This part is simplified in this example.
Private Function GetLength() As Double
Return APIConnector.MeasureLength()
End Function
Private Function GetWidth() As Double
Return APIConnector.MeasureWidth()
End Function
Private Function GetHeight() As Double
Return APIConnector.MeasureHeight()
End Function
Private Function GetBoundingBoxDimensions() As Double()
Return {Length.Value, Width.Value, Height.Value}
End Function
End Class
'Template class for the object properties. Also must be serializable.
Public Class ObjectProperty
Public ReadOnly Property Value As Object
Get
'Check if dependency properties are not evaluated yet; if not, evaluate them first.
If DependencyProperties IsNot Nothing Then
For Each DependencyProperty In DependencyProperties
If DependencyProperty.State = ObjectPropertyStates.NotEvaluated Then Dim tempValue As Object = DependencyProperty.Value
Next
End If
'Once dependencies are evaluated, evaluate the value of this object property.
Dim evaluatedValue = EvaluatingMethod()
State = ObjectPropertyStates.Evaluated
Return evaluatedValue
End Get
End Property
Public Property Name As String
Public Property Requested As Boolean = False
Public Property State As ObjectPropertyStates = ObjectPropertyStates.NotEvaluated
Public Property DependencyProperties As List(Of ObjectProperty)
Public Property EvaluatingMethod As EvaluatingMethodDelegate
Public Delegate Function EvaluatingMethodDelegate() As Object
Public Enum ObjectPropertyStates
Evaluated
NotEvaluated
End Enum
End Class
A lot of actual measurement/evaluating code was simplified in this example to make the code more readable, but this should be a reproducible code.
Now, the issue with this strategy is that I cannot serialize Study class, as it contains ObjectProperty, which contains EvaluatingMethodDelegate, and to my knowledge delegates cannot be serialized.
If I set up the serializer to ignore EvaluatingMethodDelegate, then serialization succeeds, but upon deserialization, EvaluatingMethod pointers to the respective methods (GetLength, GetWidth, etc.) on each object are lost.
My question is, how do I solve this issue? Is my whole strategy wrong if I need to use serialization and deserialization? If so, is there a better way of implementing something like this? Or is there some way to simply avoid delegate methods with the current approach? I feel like I'm re-inventing the wheel here.
Say I have an object of my custom class, called AppSettings, which has various properties that hold both value types (integers, doubles, strings, etc.) and reference types (arrays, other custom objects, etc.). Some of these custom objects have their own custom objects, so the path down to some of the value type properties can go very deep.
For example:
<Serializable()>
Public Class AppSettings
Public Property windowHeight As Integer = 600
Public Property windowWidth As Integer = 800
Public Property defaultLengthUnit As Unit = Units.meters
Public Property defaultAngleUnit As Unit = Units.degrees
End Class
Where Unit class is defined as:
<Serializable()>
Public Class Unit
Public Property Name As String
Public Property Abbreviation As String
Public Property Scale As Double
End Class
And Units module is defined as:
Public Module Units
Public meters As New Unit With {
.Name = "Meters",
.Abbreviation = "m.",
.Scale = 1
}
Public degrees As New Unit With {
.Name = "Degrees",
.Abbreviation = "°",
.Scale = 1
}
End Module
Some other code might refer or bind to some of the reference type properties, or their internal properties. Now, let's say I provide a way for the user to save current state of AppSettings by serializing it into XML:
Public Sub SerializeAppSettings(ByVal filename As String)
Using sw As StreamWriter = New StreamWriter(filename)
Dim xmls As XmlSerializer = New XmlSerializer(GetType(AppSettings))
xmls.Serialize(sw, appSettings)
End Using
End Sub
and then load them back (by deserializing) at any time while running the application:
Public Function DeserializeAppSettings(ByVal filename As String) As AppSettings
If Not File.Exists(filename) Then Return Nothing
Using sr As StreamReader = New StreamReader(filename)
Dim xmls As XmlSerializer = New XmlSerializer(GetType(AppSettings))
Return TryCast(xmls.Deserialize(sr), AppSettings)
End Using
End Function
It is called like so:
AppSettings = DeserializeAppSettings(settingsFilePath)
The problem here is that all the references to AppSettings that other objects and bindings have, are now broken, because deserialization replaces the old instance of AppSettings with a completely new instance, and the references are not transferred to it.
It appears that this doesn't break references to value-type properties (like windowHeight, which is Integer), but it definitely breaks references to reference-type properties, like defaultLengthUnit. So for example, if some other object or WPF control is referring/binding to, say, AppSettings.defaultLengthUnit.scaleToBaseUnit, it doesn't work anymore.
I wonder, how can I fix this, so that deserialization would replace the old instance of AppSettings and transfer all the references from it to the new instance that it generated?
As I understand it, there are three ways to go about it:
Replace the old instance with an new one in the exact same memory allocation, with the same internal ID, which would probably be too hacky, and I'm not sure if at all possible.
Another way would be for the DeserializeAppSettings function to overwrite each property value of the current AppSettings instance, one by one, by the deserialized values. However, since some properties of AppSettings are objects, which have their own objects, which have their own objects (and so on), I would basically need to type out all the hierarchy tree in that DeserializeAppSettings function to get down to the value type properties. And every time I would need to add or remove any property in the AppSettings class (or in any class that is used in it's properties), I would also need to manually update the parsing code in DeserializeAppSettings function. This is seriously unmaintainable.
Lastly, it would probably be possible to automate this value replacement through reflection, but reflection is very slow, and generally discouraged if there is any other option.
I hope I am missing something obvious here. Any suggestions on how to transfer all the references to AppSettings when the old instance of it is replaced with a new one through deserialization?
EDIT: Updated the code to include all the relevant classes.
I'm suffering the same issue explained here but iterating a EnvDTE.Processes.
In the question that I linked the user #Plutonix affirms it is a false warning, and I think him reffers to the obj.Getenumerator() mention so I assume my problem will be considered a false warning too, however, if this is a false warning I would like to know more than an affirmation, the arguments to say it is a false warning.
This is the warning:
CA2202 Do not dispose objects multiple times Object
'procs.GetEnumerator()' can be disposed more than once in method
'DebugUtil.GetCurrentVisualStudioInstance()'. To avoid generating a
System.ObjectDisposedException you should not call Dispose more than
one time on an object.: Lines:
214 Elektro.Application.Debugging DebugUtil.vb 214
This is the code, procs object is the involved one on the warning, but I don't see any disposable object:
Public Shared Function GetCurrentVisualStudioInstance() As DTE2
Dim currentInstance As DTE2 = Nothing
Dim processName As String = Process.GetCurrentProcess.MainModule.FileName
Dim instances As IEnumerable(Of DTE2) = DebugUtil.GetVisualStudioInstances
Dim procs As EnvDTE.Processes
For Each instance As DTE2 In instances
procs = instance.Debugger.DebuggedProcesses
For Each p As EnvDTE.Process In procs
If (p.Name = processName) Then
currentInstance = instance
Exit For
End If
Next p
Next instance
Return currentInstance
End Function
PS: Note that the code-block depends on other members but they are unrelevant for this question.
Short version: this looks like a bug in the Code Analysis component to me.
Long version (hey, you suckered me into spending the better part of my afternoon and evening deciphering this, so you might as well spend a little time reading about it :) )…
The first thing I did was look at the IL. Contrary to my guess, it did not contain multiple calls to Dispose() on the same object. So much for that theory.
The method did, however, contain two separate calls to Dispose(), just on different objects. By this time, I was already convinced this was a bug. I've seen mention of CA2202 being triggered when dealing with related classes where one class instance "owns" an instance of the other class, and both instances are disposed. While inconvenient and worth suppressing, the warning seems valid in those cases; one of the objects really is getting disposed of twice.
But in this case, I had two separate IEnumerator objects; one did not own, nor was even related to, the other. Disposing one would not dispose the other. Thus, Code Analysis was wrong to warn about it. But what specifically was confusing it?
After much experimentation, I came up with this near-minimal code example:
Public Class A
Public ReadOnly Property B As B
Get
Return New B
End Get
End Property
End Class
Public Interface IB
Function GetEnumerator() As IEnumerator
End Interface
Public Class B : Implements IB
Public Iterator Function GetEnumerator() As IEnumerator Implements IB.GetEnumerator
Yield New C
End Function
End Class
Public Class C
Dim _value As String
Public Property Value As String
Get
Return _value
End Get
Set(value As String)
_value = value
End Set
End Property
End Class
Public Shared Function GetCurrentVisualStudioInstance2() As A
For Each a As A In GetAs()
For Each c As C In a.B
If (c.Value = Nothing) Then
Return a
End If
Next c
Next a
Return Nothing
End Function
Public Shared Iterator Function GetAs() As IEnumerable(Of A)
Yield New A()
End Function
This produces the same spurious CA2202 you are seeing in the other code example. Interestingly though, a minor change to the declaration and implementation of interface IB causes the warning to go away:
Public Interface IB : Inherits IEnumerable
End Interface
Public Class B : Implements IB
Public Iterator Function GetEnumerator() As IEnumerator Implements IEnumerable.GetEnumerator
Yield New C
End Function
End Class
Somehow, Code Analysis is getting confused by the non-IEnumerable implementation of GetEnumerator(). (Even more weirdly is that the actual type you're using, the Processes interface in the DTE API, both inherits IEnumerable and declares its own GetEnumerator() method…but it's the latter that is the root of the confusion for Code Analysis, not the combination).
With that in hand, I tried to reproduce the issue in C# and found that I could not. I wrote a C# version that was structured exactly as the types and methods in the VB.NET version, but it passed Code Analysis without warnings. So I looked at the IL again.
I found that the C# compiler generates code very similar to, but not exactly the same as, the VB.NET compiler. In particular, for the try/finally blocks that protect the IEnumerator returned for each loop, all of the initialization for those loops is performed outside the try block, while in the VB.NET version the initialization is performed inside.
And apparently, that is also enough to prevent Code Analysis from getting confused about the usage of the disposable objects.
Given that it seems to be the combination of VB.NET's implementation of For Each and the nested loops, one work-around would be to just implement the method differently. I prefer LINQ syntax anyway, and here is a LINQified version of your method that compiles without the Code Analysis warning:
Public Shared Function GetCurrentVisualStudioInstance() As DTE2
Dim processName As String = Process.GetCurrentProcess.MainModule.FileName
Return GetVisualStudioInstances.FirstOrDefault(
Function(instance)
Return instance.Debugger.DebuggedProcesses.Cast(Of EnvDTE.Process).Any(
Function(p)
Return p.Name = processName
End Function)
End Function)
End Function
And for completeness, the C# version (since all of this code started when a C# implementation was converted to VB.NET and then extended to handle the "current instance" case):
public static DTE2 GetCurrentVisualStudioInstance()
{
string processName = Process.GetCurrentProcess().MainModule.FileName;
return GetVisualStudioInstances()
.FirstOrDefault(i => i.Debugger.DebuggedProcesses
.Cast<EnvDTE.Process>().Any(p => p.Name == processName));
}
So, I'm having troubles implementing a separate thread. This is because I have a simple class, and in it I start a new thread. So, as it is not any form, I haven't found any way to make it call the function in the UI Thread.
So, I cannot use the Invoke method. Is there any way to call a function from another thread?
I am going to assume that you have events exposed from your class and that you want the event handlers to execute on a UI thread. I suppose you could have a callback that the caller specifies as well. Either way the pattern I will describe below will work in both cases
One way to make this happen is to have your class accept an ISynchronizeInvoke instance. Form and Control instances implement this interface so a reference to one of them could be used. You could make it a convention that if the an instance is not specified then event handlers executed by raising events on your class would execute in the worker thread instead of the thread hosting the ISynchronizeInvoke instance (usually a form or control).
Public Class YourClass
Private m_SynchronizingObject As ISynchronizeInvoke = Nothing
Public Sub New(ByVal synchronizingObject As ISynchronizeInvoke)
m_SynchronizingObject = synchronizingObject
End Sub
Public Property SynchronizingObject As ISynchronizeInvoke
Get
Return m_SynchronizingObject
End Get
Set(ByVal value As ISynchronizeInvoke)
m_SynchronizingObject = value
End Set
End Property
Private Sub SomeMethodExecutingOnWorkerThread()
RaiseSomeEvent()
End
Private Sub RaiseSomeEvent()
If Not SychronizingObject Is Nothing AndAlso SynchronizingObject.InvokeRequired Then
SynchronizingObject.Invoke(New MethodInvoker(AddressOf RaiseSomeEvent)
End If
RaiseEvent SomeEvent
End Sub
End Class
The first thing to notice is that you do not have to specify a synchronizing object. That means you do not have to have a Form or Control reference. If one is not specified then SomeEvent will be raised on the worker thread. This is the same pattern that is used in the System.Timers.Timer class.
Try to expose some events in your class, fire them when you need to notify your UI and finally make your UI Component register to these events,
when the event is fired, the listener methods will be executed. there you can use Control.Invoke or Control.BeginInvoke to execute your code on the UI thread.
Long term lurker, first time poster here.
I have written a class to model an object in vb.net, using vs2008 and framework 2.0. I am serializing the class to an XML file for persistent storage. I do this with a method in the class like this:
Public Sub SaveAs(ByVal filename As String)
Dim writer As New Xml.Serialization.XmlSerializer(GetType(MyNamespace.MyClass))
Dim file As New System.IO.StreamWriter(filename)
writer.Serialize(file, Me)
file.Close()
End Sub
I now want to do a similar thing but reading the class from file to the current instance, like this:
Public Sub New(ByVal filename As String)
Dim reader = New Xml.Serialization.XmlSerializer(GetType(MyNamespace.MyClass))
Dim file = New System.IO.StreamReader(FullPath)
Me = CType(reader.Deserialize(file), MyNamespace.MyClass)
End Sub
However, I cannot assign anything to “Me”. I’ve tried creating a temporary object to hold the file contents then copying each property and field over to the current instance. I iterated over the properties (using Reflection), but this soon gets messy, dealing with ReadOnly collection properties, for example. If I just copy each property manually I will have to remember to modify the procedure whenever I add a property in the future, so that sounds like a recipe for disaster.
I know that I could just use a separate function outside the class but many built-in .NET classes can instantiate themselves from file e.g. Dim bmp As New Bitmap(filename As String) and this seems very intuitive to me.
So can anyone suggest how to load a class into the current instance in the Sub New procedure? Many thanks in advance for any advice.
I'd put a shared load function on the class, that returned the newly de-serialised object.
e.g.
Public Class MyClass
...
Public shared Function Load(ByVal filename As String) as MyClass
Dim reader = New Xml.Serialization.XmlSerializer(GetType(MyNamespace.MyClass))
Dim file = New System.IO.StreamReader(FullPath)
Return CType(reader.Deserialize(file), MyNamespace.MyClass)
End Sub
End Class
...
Dim mine as MyClass = MyClass.Load("MyObject.Xml");
Hope this helps
Alternatively,
Encapsulate the data of your class in an inner, private class.
The properties on your outer visible class delegate to the inner class.
Then Serialising and De-serialising happens on the inner class, you can then have a ctor that takes the file name, de-serialises the inner hidden object, and assigns it to the classes data store.
The "New" method in VB.Net is a constructor for the class. You can't call it for an existing instance, as the whole purpose of the method is to create new instances; it's just not how the language works. Try naming the method something like "ReadFrom" or "LoadFrom" instead.
Additionally, given those methods, I would try to implement them using a Factory Pattern. The ReadFrom method would be marked Shared and return the new instance. I would also make the method more generic. My main ReadFrom() method would accept an open textreader or xmlreader or even just a stream, rather than a file name. I would then have overloads that converts a file name into a stream for reading and calls the main method.
Of course, that assumes I use that pattern in the first place. .Net already has great support for xml serialization built into the platform. Look into the System.Xml.Serialization.XmlSerializer class and associated features.