PDA

View Full Version : Class Modules in AddIn .xlam



marekba
03-05-2013, 02:37 AM
Dear all,

I am trying to have a couple of class modules inside an addin, that would be accessible for all the workbooks that I open. Is that even possible?

I tried different things, but nothing works... If you have an idea, it would be absolutely great!

Many thanks in advance for your help :D

M.

SamT
03-05-2013, 09:14 AM
Marekba,

Think of Class Modules as blueprints of custom objects. Until you instantiate a custom object, it doesn't even exist, except as a "blueprint on paper."

If you just want common Constants, Functions, and Procedures available, put them in a regular Code Module.

marekba
03-05-2013, 02:49 PM
Hello SamT, and thank you for your quick reply!

After developping a long answer, I have just discovered that Properties could be used in regular modules; they were a main reason for me to use Class modules, so Ißll spare you the long answer.

One more point, though :
if a class module is called "ExtensiveClassModuleName_Version1_2345", it is possible to instantiate it with a very short name, e.g. "Dim cm as new ExtensiveClassModuleName_Version1_2345", and then use this "cm". Does this possibility exist with a regular module? I haven't found it until now.
Purpose would be to have module with subs, functions and properties in a .xla-file that would be accessible for the whole Application. But without having to give the full name. Maybe declare it as an object..? Couldn't find the answer...

Thanks in advance for your help!

M.

Aflatoon
03-06-2013, 08:21 AM
No, you can't use a module as a class. If you need that functionality, use a class - note that you will have to change its Instancing to be able to use it from another project.

SamT
03-06-2013, 09:48 AM
Marekba,

Yes you can instantiate a class with any name you want. "CM" is great.

Aflatooon is correct. Regular modules don't have properties, (Get, Let, and Set procedures.)

You can instantiate a Class in an add-in by using the Workbook_Open procedure in the Workbook Code Page.

Your add-in can have both Classes (Objects) and regular modules.

Aflatoon
03-06-2013, 10:00 AM
That's not what I said - regular modules can have properties (although I don't see much point in doing it).

What I said was that you can't do something like this:
Dim CM as StupidlyLongNormalModuleNameHere
set CM = New StupidlyLongNormalModuleNameHere
cm.yadda

That will only work with a class module, not a normal module.

marekba
03-06-2013, 02:01 PM
Regular modules don't have properties, (Get, Let, and Set procedures.)

That's what I thought, but...

in module "modA":
Property Get MyPropertyA() As String
MyPropertyA = "This is propery A"
End Property

Public Function A_Function() As String
A_Function = "This is a function"
End Function

and in module "modB":
Sub GetPropertyFromOtherSub()
Debug.Print modA.MyPropertyA
Debug.Print modA.A_Function
End Sub

... works. To return a value, I used to use functions, but now I´m quite confused about the difference between function and property in a regular sub. They can execute actions and return a value.

Aflatoon
03-07-2013, 02:05 AM
The difference is no more or less than it is in a class really - you can use either - other than that the concept of a module property doesn't really make a lot of sense to me, whereas object properties do make sense.

Bob Phillips
03-07-2013, 02:39 AM
A Module is just a static class, you don’t need to instantiate the class before you can use it, and there will only be 1 instance of that class. Thus, just like dynamic classes, they can have properties.

Conversely, you can declare a variable within a class as just Public, such as

Public Name As String

which is doing the same as separate Get and Let properties (although you cannot do other things as you can with Get and Let), and more akin to how you see variables/properties declared in a standard module.

As Aflatoon said, you can have properties with all of their richness in a standard module, but why bother? Some people, the professional developer types (who probably wouldn't be using VBA as they are 'better' than that) might like the formality and structure that this imposes.

More usefully perhaps, you can add functionality with the property definitions. Consider this simple example, which is class-like but not a class in sight

Private mName As String
Dim mAge As Long

Public Property Get Name() As String
Name = mName
End Property
Public Property Let Name(Value As String)
mName = Value
End Property

Public Property Let DoB(Value As Date)
mAge = Year(Date) - Year(Value) + (Format(Date, "mmdd") < Format(Value, "mmdd"))
End Property

Public Property Get Age()
Age = mAge
End Property

Public Function Testproperties()
Name = "Jack"
DoB = DateSerial(1975, 6, 13)
MsgBox Name & " is " & Age & " years old"
End Function

marekba
03-07-2013, 05:18 AM
Cool, this clears things up, thanks for all the explanation :D

I wish you a very nice day, folks!

M.

SamT
03-07-2013, 02:57 PM
Aflatoon,

Thank you, I learned something today, making it a very good day.

SamT
03-07-2013, 02:58 PM
Xld,

Thank you too, very much.

SamT
03-07-2013, 03:03 PM
Marekba,

I gave you bad information. I am sorry.

Bob Phillips
03-07-2013, 03:18 PM
One other thing I could have added. The action code in my example could be written like this, where LikeAClass is the name of the module the code is in

Public Function Testproperties()
LikeAClass.Name = "Jack"
LikeAClass.DoB = DateSerial(1975, 6, 13)
MsgBox Name & " is " & LikeAClass.Age & " years old"
End Function


which clearly shows that Name etc is a property of a class type object, but that object does not have to be instantiated (there is no Set obj = class).

marekba
03-08-2013, 12:17 PM
xrp, that´s clear to me now, thank you again :D

No worries, SamT, thank you for taking the time and answer me *

cheers

M.