Disclaimer - I am by no means a VBA expert; I am a hack.
However, I've got some class modules that are static (using Attribute VB_PredeclaredId = True
)
I'd like to define some custom events with them, too (Public Event Foo(ByVal Bar As Boolean); however, since I am not instantiating the class, I'm not finding any info on any "Attributes" that will include "WithEvents" when "PreDeclaredID" is true.
Yes, I can use the class without its being static; however, I'd prefer to find a way for it to be declared automatically WithEvents, if it's possible.
The class has static semantics, but it's not static in the static sense you're referring to.
The VB_PredeclaredId attribute set to True means the compiler generates a global (or project-scoped, if the class is private) instance that is named after the class module itself.
In other words, there is literally an object/instance named Class1 (assuming the class module is named Class1), exposing the default interface defined by the Class1 module (i.e. it's an object whose compile-time type is Class1 regardless of what other interfaces that class might be implementing).
So you are not instantiating it, but the VBA compiler does.
And that object behaves every single bit the same as any other object you might have - there is no reason a Public Event could not be declared in it, and you can Set a WithEvents object variable to that "free" global instance, which you can refer to by name from anywhere in the project:
Private WithEvents Thing As Class1 '<~ requires Public Event declaration in Class1.
Private Sub Class_Initialize()
Set Thing = Class1 '<~ will not compile unless Class1 has VB_PredeclaredId=True.
End Sub
Related
Is using the Named Constructor Idiom possible in VB.NET? I've found many examples in C#/C++ but can't quite wrap my head around how to use it in vb.net. Seems like a better method of keeping my code readable when involving a lot of constructors with similar argument types.
I've never heard this term before, but after a quick search it sounds vaguely like the Static Factory Pattern. The idea is you make the constructor private and use a shared (static in c#) public function to create the new object.
Public Class Foo
Private Sub New()
End Sub
Public Shared Function CreateNew(param as Object) as Foo
Dim obj as New Foo()
obj.Prop = param
return obj
End Function
End Class
You sure can make Named Constructors in VB. The pattern uses a static (Shared in VB) factory method on the class itself, so that the method can be named. (Other Factory patterns involve using a separate Factory class to provide the static method.)
System.Drawing.Color is a simple example. The pattern is implemented underneath as a static (Shared) property. Since no arguments are necessary, the Get method of a Property works just fine:
Public Shared ReadOnly Property Chartreuse As Color
Usage:
Dim favoriteColor as Color = Color.Chartreuse
Or you can make static factory methods to do the same thing.
Public Class TheClass
Public Sub New()
End Sub
Public Sub New(input As String)
'do something with input
End Sub
Public Shared Function MyNamedConstructor() As TheClass
Return New TheClass
End Function
Public Shared Function AnotherNamedConstructor() As TheClass
Return New TheClass("Another Name")
End Function
End Class
As for whether this pattern is "better" than overloading constructors, that's really an opinion. Personally, I would just overload the constructors. As you can see in the example above, the constructors need to be there anyway.
I suggest using the Named Constructor pattern when you have only a few possible ways to construct your class/struct, but consumers of your class/struct will be using those few constructors often, and with different input values to those constructors (as in the System.Drawing.Color example).
The Name in 'Named Constructor' doesn't represent a name for the constructor itself, but for the object resulting from the constructor. If your named constructor can be used to create two objects that don't feel right to give the same name to, then don't give the constructor that name.
In my VB.Net code, I know that when I declare a property in a class I can do so using the shorthand of, for example, Public Property Prop1 As String and .Net automatically creates a private variable _Prop1 that I can refer to within my class.
I also know that I can refer to that variable within my code using either _Prop1 or by Prop1.
Now since I've always assumed that the preferred method is to use the private variable, I've always tried to make modifications / write code within my class referring to _Prop1. This is where my problem now comes in...
I have the following situation:
Public Class MyClass_Base
Public Overridable Property Prop1 As String = "val1"
Public Sub Test()
If _Prop1 = ....
End Sub
End Class
Public Class MyClass
Inherits MyClass_Base
Public Overrides Property Prop1 As String = "val2"
End Class
Basically, I define the property as Overridable in my base class, now when I get to the Test() subroutine, _Prop1 has the value of Nothing. However Prop1 has the correct value of val2.
Programming gurus out there, what is the correct way to deal with this situation?
Do I ignore the auto-created prive variable _Prop1 and work with the public Prop1 or is there something else I should add in / not even use the shorthand notation for this and write my own getter / setter logic to ensure things change as I would like?
Thanks!!!
I think you've answered your own question. You should absolutely not rely on hidden compiler mechanics in your own code. You're referencing a variable that you did not declare and there is no guarantee in the framework that this variable will be there (or work as you might expect, as you've discovered) - it's a hack to use it, so don't.
Unless you have a very good reason not to, code in the class should reference the public property just the same as code using the class would. If you're using automatic properties then there is no difference between doing that and using the private variable. It also has the benefit that if you do, at a later time, decide to implement explicit getters and setters that your code does not break and that your new getters and setters get called.
To explore the reason you get the unexpected result, in declaring
Public Overrides Property Prop1 As String = "val2"
You end up with two different _Prop1 variables - MyClass_Base._Prop1 and MyClass._Prop1. When you then call Test(), you are calling the base class method and that will refer to the base class's _Prop1 variable which has not been set to anything since you have overriden the implicit variable, getter, and setter in the subclass.
To illustrate the point, this is similar to :
Public Class MyClass_Base
Private _Prop1 As String = "val1"
Public Sub Test()
Console.WriteLine(_Prop1)
End Sub
End Class
Public Class MySubClass
Inherits MyClass_Base
Private _Prop1 As String = "val2"
End Class
Sub Main()
Dim class1 As New MyClass_Base
Dim class2 As New MySubClass
class1.Test()
class2.Test()
End Sub
Where your output will be :
val1
val1
In the above case MyClass_Base._Prop1 is always initialized, however, while in your case, it is not. In either case, the Test() method belongs to the base class so it will always refer to its own _Prop1 and not any variables of the same name declared in subclasses.
If you do need to refer to the private field, for whatever reason, you have to be very careful about how you do it (and the implications that follow). Any method that does so would need to itself be Overridable if subclasses are intended to work with their own private variables in the same way. Not to suggest that you should continue to use implicit variables, but to demonstrate :
Public Class MyClass_Base
Public Overridable Property Prop1 As String = "val1"
Public Overridable Sub Test()
Console.WriteLine(_Prop1)
End Sub
End Class
Public Class MySubClass
Inherits MyClass_Base
Public Overrides Property Prop1 As String = "val2"
Public Overrides Sub Test()
Console.WriteLine(_Prop1)
End Sub
End Class
Here we get the "expected" result because MySubClass overrides test to reference its own private field. Better to just stick to using the property names.
From the documentation on Auto Implemented Properties:
"Attributes specified for the property do not apply to the backing field."
This is one of those areas where C# and VB.NET need to be aligned.
C# (correctly) does not allow you to access the auto implemented property backing field (without some convoluted work). I honestly don't know what you can access this in VB.
So the rule here is even though you can access the backing field of an auto implemented property you really shouldn't modify this directly (nor should you need to)
If you need to then you should use a defined backing field (with initialisation) and explicit Get and Set
I have a class Class1 with several properties (Property1, Property2, ...)
For some design reasons, I have access only to, let's say, Property1.
Is there a way to get a reference to Class1 ?
I tried Property1.Parent, Property1.Base but both failed.
I'm using a heavy workaround which is creating a separate class for each property with a reference to the main class:
Public Class DerivedProperty1
Inherits Property1
Public ParentClass as Class1
Public Sub New(ParentClass as Class1)
me.ParentClass = ParentClass
End Sub
End Class
and then Class1 will become
Public Class Class1
Public DerivedProperty1 as DerivedProperty1
...
End Class
Is there another way different from this workaround ?
Thank you.
There is nothing build for that.
That's because the Class1.Property property really just hides a reference to a Property1Class class instance stored somewhere else. And because of that, the same Property1Class instance can be referenced by more then one Class1 instances.
And your naming in misleading. Property1Class class does not derive from Class1 class. It's just used by that class as a type of one of properties.
So if you need that kind of functionalty, you have to code it by yourself.
Is there a way to have one variable per class in vbscript?
If not what is the best way to emulate it? Prefixing a global variable declared next to the class?
Also is there a way to declare static/class methods(for a static constructor) or am I force to prefix a function?
In languages that support class-level/static data or methods you can
associate/bind data or methods explicitly to the set of objects defined by the class. So you can have Customer.Count and Product.Count and a plain Count (or ##Count) in Customer code will access the right number.
use such data or method without having an instance of the class (yet).
VBScript does not support static data or methods. You have to use global data or functions/subs and do the associating in your mind (perhaps with a little help from a naming convention). Accessing these 'static'=global elements without an object is trivial, but - obviously - should be done with care.
You can embed one or more singleton objects or code references (GetRef()) in your objects to bind them closer to the class, but that will increase the size of the instances.
You can do something like this to sort of emulate a static class:
Class Defines_
Public Sub DoSomethingUseful
End Sub
End Class
Dim Defines : Set Defines = New Defines_
...
Defines.DoSomethingUseful
This can be used to give you something analogous to constructors (really, factory methods):
Class Something
Private mValue
Public Property Get Value : Value = mValue : End Property
Public Property Let Value(x) : mValue = x : End Property
End Class
Class SomethingFactory_
Public Function Create(value)
Set Create = New Something
Create.Value = value
End Function
End Class
Dim SomethingFactory : Set SomethingFactory = New SomethingFactory_
...
Dim something : Set something = SomethingFactory.Create(5)
I am developing a VBA project in Word and have encountered a problem with handling events when using a class that implements another.
I define an empty class, IMyInterface:
Public Sub Xyz()
End Sub
Public Event SomeEvent()
And a class, MyClass that implements the above:
Implements IMyInterface
Public Event SomeEvent()
Public Sub Xyz()
' ... code ...
RaiseEvent SomeEvent
End Sub
Private Sub IMyInterface_Xyz()
Xyz
End Sub
If I create a third class, OtherClass, that declares a member variable with the type of the interface class:
Private WithEvents mMy As IMyInterface
and try to initialize this variable with an instance of the implementing class:
Set mMy = New MyClass
I get a run-time error '459': This component doesn't support this set of events.
The MSDN page for this error message states:
"You tried to use a WithEvents
variable with a component that can't
work as an event source for the
specified set of events. For example,
you may be sinking events of an
object, then create another object
that Implements the first object.
Although you might think you could
sink the events from the implemented
object, that isn't automatically the
case. Implements only implements an
interface for methods and properties."
The above pretty much sums up what I'm trying to do. The wording, "that isn't automatically the case", rather than "this is flat-out impossible", seems to suggest that there is some bit of manual work I need to do to get it to work, but it doesn't tell me what! Does anybody know if this is possible in VBA?
Apparently Events are not allowed to be passed through an interface class into the concrete class like you want to using "Implements". In this article it states: "Event declarations of the abstract interface are not included in the interface that is inherited by concrete classes. I haven't found anywhere that this has been acknowledged as a bug; however, it does seem to be one."
Here is the link to the source: http://www.devx.com/getHelpOn/10MinuteSolution/20416
:-(