Class Modules

[richlocus]

Greetings Eileen's Lounge!

I have been an Excel developer for over 30 years, and have written hundreds of applications, almost all which were related to business and accounting applications.

Not once have I ever used a Class module, but I noticed on You Tube there were a quite a few videos related to Class modules. Apparently they are not needed for business applications?

Where would these Class modules be used?

Thanks,
Rich Locus

[HansV]

You have probably used class modules: the ThisWorkbook module, worksheet modules and userform modules are all special forms of class modules.

Here are some threads in Eileen's Lounge about class modules:
Create class module for option buttons
Userform - TextBox Apply Currency on Change (multiple)
Formula Tracing Add-In

[richlocus]

Thanks Hans!

[DocAElstein]

been an Excel developer for over 30 years, and have written hundreds of applications, almost all which were related to business and accounting applications.....Not once have I ever used a Class module, .... Apparently they are not needed for business applications?
.....Where would these Class modules be used?

Hello,
A bit too complicated a subject to go into a lot of detail here perhaps. So just some general comments
It does not surprise me that you have never used a Class module, if for the time being we say a class module is that thing you can physically add in the VB Editor left explorer window, in a similar way to how you can add a normal code module.

It’s a bit of a complicated subject and not really possible to go into it in detail In a short post, but very simplified, we can say maybe two main areas they might be used.
_ 1 Where you don’t really need them, but they might help you organise things. Along the same vein of using functions. Maybe this is where your work fits in so you never needed them.
_ 2 The area where I have mostly seen them doing something that might be difficult without them. This usually involves tackling the area of WithEvents - You can see that straight away in the first two links from Hans


It’s not easy to go much further without getting into a lot more detail.
Just a few things that really threw me off getting to understand this Class stuff, was, starting the subject with talking about Class modules and hearing things like, ThisWorkbook module, and worksheet modules are class modules.

I usually now start somewhere else , saying like, In VBA you can create your own custom objects by defining classes. Classes act as templates for new objects. (Maybe a bit later further down, after saying other things, I might say something, like you can use a class module to create your own objects)

The VB Editor misleads a bit, IMO
There are somewhere in the Vaults of Microsoft, ( or hidden somewhere), something that might be seen to be a class module for the workbook and each worksheet. They use them to make us the workbook and worksheet objects. Those corresponding things in the VB editor are part of the final made objects. We are given access to them for, surprise surprise, mainly getting at their events. The routines are actually there, listening in, - we don’t really add them or else we would be messing with their class modules, which Microsoft don’t want us to do. We can put coding in them to go with those events
What helps confuse is that the thing you can insert and is called a Class module could reasonably be considered to be a class module. But the objects you can make from them are not displayed in the VB Editor.

It might have helped perhaps if your inserted Class module was somehow shown a bit to the left, and or up a bit, maybe in the North West direction slightly.


Alan

( Edit P.S. Sometimes to help stop people wanting to kill me, I call the ThisWorkbook module, and worksheet module class object modules, and I get a reduced sentence of just a bit of hate, Lol. )

Edit 2a Some other posts touching on the subject, ( I will perhaps add to the list later )
https://eileenslounge.com/viewtopic.php ... 50#p288150 - only torches on the subject in passing

Edit 2a some Blogs
https://excelmacromastery.com/vba-class-modules/ - not too bad, and concise, but nevertheless very long, as it has to be if you make any serious attempt at the subject

[snb]

Although Class Modules are seldom necessary, they can be very practical in reducing the amount of code you have to write.
See e.g https://www.snb-vba.eu/VBA_Userform_inv ... le_en.html

At least 1 instance where you can't do without a class module: to retreive when a Querytable is updated (afterupdate-event) or when it starts to update (beforeupdate_event).

[richlocus]

DocAeIstein and snb:
Thank you for your explanations. This helps my understanding without having to attend a formal VBA "class".
Regards,
Rich Locus

[SamPi]

Hi,
See an example below of Class Module for check the name of workbook when is open.

[DocAElstein]

Hello SamPi, (Welcome to Eileen’s Lounge)
I am not so experienced with Class things, so I thought I would try to figure out what your offering is about, as it might be useful to help me and perhaps others understand Class things..

First 3 things threw me off:
The choice of your variable names;
the use of a .xlam file; and
the Class module is only part of the story of what you have offered**.
( Here is your original stuff and the coding for others to see )

I think I can understand why finally a .xlam might be a good choice for such a thing, but in trying to understand a topic it adds an extra complication, JIMVHO , so I went over to using a standard file.
I changed the variable names and a few other minor changes as it helped me to see things a bit clearer, so I thought it might help others unfamiliar with class stuff as well


This is my initial take on what is going on . Maybe you or someone more familiar with these things can confirm what I am saying or correct me. It would not surprise me if I have not quite got it right, again.

**You have actually given an example of using class stuff in VBA, rather than an example of just a Class Module, - the class module is just part of it, and without the rest, it's pretty meaningless.
So it is a bit more complicated, and so I am a bit pushed for space here, and size limits etc. even for an attempt at a short explanation, so I did it
here
, to make it a bit clearer :

Unfortunately I think, there is no easy way around getting even a brief introduction to the Class stuff. The subject is just that little bit more complicated such that you must think a few things carefully through to get even a first bit of an understand.
A simple short explanation often does more harm than good, JIMHO

Alan

[SpeakEasy]

Fromn you various musings:

>telling you as people often do, that the worksheets code module is a class module , is wrong…. At least I think

You think wrong. Userform<x>, Sheet<x>, and ThisWorkbook are all (special forms* of) classes. You can happily add your own events and properties to them, for example.

And then

Public example as ThisWorkbook

(or, if you are working in another class module

Public WithEvents example as ThisWorkbook **)

both work exactly as you'd expect if they were your own classes created from scratch


* Not going into detail here, but if you really want to go down the rabbit hole, try a Google for VB_PredeclaredId

** If you are unsure, then trying to declare WithEvents in a module is a quick and dirty way to determine whether that module is actually a class module or not

[SpeakEasy]

Fromn you various musings:

>telling you as people often do, that the worksheets code module is a class module , is wrong…. At least I think

You think wrong. Userform<x>, Sheet<x>, and ThisWorkbook are all (special forms* of) classes. You can happily add your own events and properties to them, for example.

And then

Public example as ThisWorkbook

(or, if you are working in another class module

Public WithEvents example as ThisWorkbook **)

both work exactly as you'd expect if they were your own classes created from scratch


* Not going into detail here, but if you really want to go down the rabbit hole, try a Google for VB_PredeclaredId

** If you are unsure, then trying to declare WithEvents in a module is a quick and dirty way to determine whether that module is actually a class module or not

[DocAElstein]

Hi,
Thanks for taking a look at my ramblings, appreciate it. (I know it’s not always a pleasant experience, I don't always enjoy it myself Lol. (But as the saying goes, what’s pain if you want to be beautiful and understand, Lol) )

Part 1….
> Userform<x>, Sheet<x>, and ThisWorkbook are all (special forms* of) classes....
….* …VB_PredeclaredId ….
I am certainly not saying that you are wrong, but I am not convinced yet.
Or – more likely , its like this
Maybe its down to in what context you are talking and probably also a bit down to me not explaining exactly what I mean. I am talking most of the time about the modules we see in the VB Editor

I see it like this, (at the moment…)
There is, for example, a worksheet class, ( one possibly for each worksheet maybe, sort of, I am not too sure just yet on that one). In any case, it can be considered that there is a Class module for any worksheet. We don’t have direct access to it.
We can add a worksheet, through the .Add method , and that behind the scenes does some version of
Dim Worksheets(Sheetx) As WorksheetClass
Set Worksheets("Sheetx") = New WorksheetClass
We cant do that, - it’s done behind the scenes when we do what we can – the .Add thing
What we end up with is an object from the class worksheet. We can Dimension a variable as class worksheet, and then Set it to that object from the class worksheet, ( the one which the .Add made, or one of the few that were made ready for us) – like this, as many of us will be familiar
Dim Wsx As WorksheetClass
Set Wsx = Worksheets("Sheetx")

But you try using the New in that last line though, and you will be in trouble, as I would expect
What we see as a worksheet code module is, I think, part of the made object. The coding in it is "real" in the sense that we can step though it. So I call it a object module. If you like , as a compromise, a class object module – it’s an object module made from a class, as apposed to a normal module, that is… well, not quite sure yet … but something else

When we add a Class module , it is a class module, not an object. It is a blue print text from which to copy the code from to put in an object made from that class. No ones had been instantiating with its innards.

In my example , I made what I would suggest is an object, or class object if you prefer, from a custom class module (that custom class module I had added and gave the name, FileOpenWatcher), I made this object with the two lines
Dim MeWatcher As FileOpenWatcher
Set MeWatcher = New FileOpenWatcher '
Effectively then I had something, an object, MeWatcher , and part of it , the coding so to speak, looks identical to the class module, but we can’t see it**, not in the way we can se the worksheet class object module. That is just the way Microsoft have organised it. The class module is designed to be a template to be used over and over again. So maybe they don’t want us messing inside it as we can in a worksheets or ThisWorkbook object code modules. If we want something different, then we start again with another custom class module. (Or modify the existing blue print text in the custom class module)
It is very easy to get mixed up. I can fully understand why people would be happy to accept that the custom code module you add and Worksheets or ThisWorkbook code module are similar. As I see it they are not: The Worksheets or ThisWorkbook code module are part of something substantial. Your custom class module isn’t much more than a bit of paper with some text on it
( Those two code lines went in the ThisWorkbook code module. Didn’t have to be. Has no relevance to our discussions )

One thing in support of my stand, (and in my defence, your honour),

By default you cannot step through the coding in an class object module made from your custom class. That makes (unusually for Microsoft) sense. - Since you cannot see** the coding as you can in a worksheet class object module.
(But since the coding in your object is identical to that text from which it is made in your custom Class module blueprint, then you might as well be allowed to step through that as if it was the actual object, and that option is made available. That is useful, but slightly misleading, … amongst other things, you might think that the class module you made is a similar thing to the worksheets and ThisWorkbook code module, which I am arguing it isn’t

(Also you can’t run any coding in a custom class module. Makes sense by the same reasoning. - It isn’t "real" coding, - it’s just the text of coding. It is what gets copied and used as “real” coding inside the “invisible” code module that those two code lines make)

_.________________________________-

As for Public example as ThisWorkbook etc. That could be seen as the usual variable As object type declaration isn’t it? I am arguing that ThisWorkbook is an object. So I have no problem with that.

_._____________________________-

trying to declare WithEvents in a module is a quick and dirty way to determine whether that module is actually a class module or not…..

….. how about ….. trying to declare WithEvents in a module is a quick and dirty way to determine whether that module is actually an [object module or a class module] or not …..,
Or if you prefer, … trying to declare WithEvents in a module is a quick and dirty way to determine whether that module is actually [an class object module or an class module] or not…...
Maybe that makes some sense. An object can go with events, or it might be a reasonable thing for the object to want to do. A normal code module is, well is… well, not quite sure yet … but something else
(It’s allowed to have WithEvents in your custom class module text blueprint, since that is the coding that goes in the object code module that you make from it)

_______________________

[DocAElstein]

Part 2…


_.,_____________________

As for VB_PredeclaredId stuff – that is obviously a bit ( or rather a lot) too advanced for me. Definitely a deep rabbit hole, as you said. I will have to leave that for another day. But it is a very useful tip to have, thanks. A quick look suggests , if and when I have the time, it could be what might help clear up some of my thoughts
It does mention something about a default instance variable that might be a way of saying , the class module isn’t a class module anymore, it’s a class object module, sort of. (Maybe Microsoft overlooked that when they made their modules of ThisWorkbook and Worksheets into class object modules and not class modules with that. But like the guy that forgot to order the material for the king’s new suit, he came up with a better story

Here’s a good one I just thought about. The class module we can add is a reusable template so no need to make a global instance of it. Do that with the ThisWorkbook and Worksheets class modules and you got a variable that is an instantiated object from the class. Let the masses have access to some of that object variable with a code module, and call it a class module – they’ll never notice the difference. If they get suspicious, call it a special form of class module
_._____

I am less familiar with the UserForm module, so I will reserve judgement on that for now. I think I recall that there is some quirk that you can use the class name as if it was an object. Some relation there I expect to the VB_PredeclaredId stuff . I don’t remember the details and I would be stretching my brain too far just now on that, but it might mean that it is a class module. Maybe not. I will have to reserve judgement on that for now, due to brain stretching limitations. Maybe the difference is to do with the VB_PredeclaredId


_.____________________-



Here is specific quote bit from my recent ramblings…
……What effectively then happens could be regarded as a class object code module being made and appearing looking somewhat similar to the worksheets object code modules or ThisWorkbook as seen in the VB Editor left explorer windows, like this , and that has a copy of the Class module coding in it…..

Take a look at my screenshot again:


Look at those square symbols and their apparent "levels". I may need to rethink my sketch a bit, I see now that
_ the worksheets icon could look like a sheet of boxes – an object – a spreadsheet ,
_ the ThisWorkbook icon looks like a blank page, could perhaps be thought of the cover of a book , so an object like a workbook

The main class thing icon is shown arguable at a level around that of the Microsoft Excel object, (maybe the application is a similar word for Microsoft Excel object). So it is a bit higher up. Quite a bit away from the ThisWorkbook and Worksheets icons. I still don’t like to see custom class modules icons at the same level of those ThisWorkbook and Worksheets icons

I realise my ramblings are a bit vague on this. But I read often that the hierarchical OOP like thing that Excel VBA is, deliberately is , a bit vague.
But I am still thinking that the class module we can add is a bit up and / or to the left or conversely those ThisWorkbook and Worksheets icons should be a bit to the right to make them look "a bit further down the OOP hierarchical chain" compared to an added custom class module

class module icon should be IMHO a bit up and or to the left.JPG

_.____________

Thanks again for the reply. I will probably re read and think about it a lot more

I am going off now to modify some of the ramblings. I am not yet going to call the ThisWorkbook and worksheets class modules though. But I am big enough to admit , that I might later. (I might not though, ever ... You haven’t convinced me yet that the King isn’t standing there bollock naked)

Alan

[SpeakEasy]

Let's start at some basics

1) A class describes the variables, properties, procedures, and events of an object (but a class is not an object itself; an object comes into existence when a class is instantiated)
2) A class module is part of a development environment that allows a programmer to define those variables, properties, procedures, and events
3) An object itself does not have a module; it is your IDE that has modules.
4) An instantiated object is a black box. The internal working are never directly accessible to the consumer of the object.

So your stream of consciousness mutterings about not being able to see the Worksheet module is inaccurate. There is no module for you to see.

Think of it in relation to the oft used cookie cutter anology: to understand the relationship between an object and its class, think of cookie cutters and cookies. The cookie cutter is the class. It allows us to cut out cookies of a particvu;ar size and shape. The class is used to create objects. The objects are the cookies. But we need a tool to creates the cookie cutter. A class module is that tool

(to continue the analogy, we can give the cookie cutter to other people to cut out their own cookies - but they have no need to see or access the tool that made the cutter.)

Given this view, you might want to revisit yopu musings on classes (which are some ... inaccuracy) and see if you can revierw them.

[DocAElstein]

Part 1

Given this view, you might want to revisit yopu musings on classes (which are some .. inaccuracy) and see if you can revierw

Without a doubt I will be revisit my musings on classes. I tend to even force myself sometimes to go with what smarter people say, assuming they are right, even if I still think they aren’t.
(By the way , those musings relevant are just the single post, (actually 2 now as I just split it to make it a bit clearer, and add a few things I got out of our discussions ), only from Page #3, posts #21+ . Hopefully I have not mistakenly sent anyone anywhere else in that Thread of my ramblings on class stuff, – the earlier pages are notes I wrote a very long time ago on classes and still need tidying up )



Having said that, here again just my thinkings below, even accepting they may be wrong, again on your last reply.
I can’t actually see that you have said much different to me this time around …

_ 1) A class describes the variables, properties, procedures, and events of an object (but a class is not an object itself; an object comes into existence when a class is instantiated)
Totally agree. Ties up as far as I can tell with all I said or wrote anywhere ever… well at least since I first woke up from my technology coma and met OOP (which VBA isn’t, but tries to act like –(according to other smarter people here and elsewhere, I add quickly, Lol ) )

_2) An object module is part of a development environment that allows a programmer to define those variables, properties, procedures, and events
Totally agree. I might word it a bit differently. The object module is put in the development environment as that is the obvious place to put it. Doesn’t have to be though. It could have been designed to be a floating window like the Immediate window is. I can imagine a few occasions when it would have been convenient to drag it around a bit like I do with the Immediate window. Personally I would find that useful. I suppose the thing would then still technically be part of the development window. But that is all minor technicality stuff.
I am interested that you are using the term object module. Curious why and to what you are referring to. Maybe a typo?
Although we use the worksheets and ThisWorkbook modules for many things, (often its down to personal preference), as I understand it they were made available to us mainly to get at the events, but allows a programmer to define those variables, properties, procedures, and events .. is a statement I am perfectly happy and in agreement with.
I have to ask what are you calling a object module here?

3) An object itself does not have a module; it is your IDE that has modules.
That is a technicality again open to perception I think. The worksheets object module as I call it is related to the worksheet. Doesn’t matter if the window they give you that allows you, for example, to add coding to events, is ordered in a neat way in the IDE. That is point _2 which I agree with.
If I use Me. In coding a worksheets code its referring to some way to the worksheet. The object definition is vague, by design. It sounds reasonable to me to regard the worksheet code module as part of the worksheet object, or at least it sounds reasonable to me to regard the worksheet code module as part of greater total worksheet "thing".
Obviously no one living has access or a grip anymore to any of the real innards of Office. It’s open to a reasonable logical interpretation that matches what you see and get. A worksheet code module can easily be seen to be related to a worksheet. They are, to the user, part of the end thing, a worksheet, that we "have", and/or experience or can reasonably perceive.

4) An instantiated object is a black box. The internal working are never directly accessible to the consumer of the object. Agree mostly. – same comments more or less as in _3 no one living has access or a grip anymore to any of the real innards of Office. It’s open to a reasonable logical interpretation that matches what you see and get.
I am thinking that a worksheet is an instantiated object, or something very similar. Hence,
Set Wsx = New Worksheets("Sheetx")
,wont work. You must dump the New
Obviously no one on this planet has access anymore to the innards. Or if they do, they don’t dare try, for fear of breaking it.
I would suggest that we do have a very minor minuscule access to some of it, maybe via an interface to protect the real innards, and that is , for example, for the case of a worksheet, what we can do with the worksheet code module, (or even manually adding things to the spreadsheet I suppose. ( We can also do that with coding in the worksheet code module, - personal preference – I like to, but I think the main reason we are given it is for a convenient way to add to event codings. Others prefer to do other coding things to the worksheet from normal modules. I would fight to the death for their right to be like that, even if I don’t want to. ) )



So your stream of consciousness mutterings about not being able to see the Worksheet module is inaccurate. There is no module for you to see Possibly you have some typos there, or I missed something. That makes no sense as written. Maybe you meant something else and the shortened version slipped out, missing something along the way?
I think I can see what I perceive as a worksheet module,
(just as I think I can see what I perceive as a spreadsheet, even though technically no one ever has or can ever see a spreadsheet as they don’t really exist, but I suggest it’s a reasonable perception to have, that there "are" spreadsheets)
, we are currently disagreeing as to whether the thing we may perceive as a worksheet module, (what we see referred to as a Sheet in the IDE), should be perceived as a class module or a object module.
In my perceptions, a class module can be likened to a bit of paper with text on it. When some "thing" is instanciated from that class, and perhaps has a few properties assigned, etc, then I perceive it as something a bit more substantial with pseudo "real" coding in it, and I am inclined to call it/ perceive it, as an object





Think of it in relation to the oft used cookie cutter analogy…
I totally agree with all that, well almost, I note you are using the term object module again. But strange this time. .. we need a tool to creates the cookie cutter. An object module is that tool
Once again it is down to what perceptions one has in one’s mind at the time, but I would say, as you do, that the cookie cutter is the class, but we need instruments / tools / things / innards all sort of things to create the cookie cutter, most of these we will rarely get anywhere near, and the real innards never, but one of the tools, the class module , I may or may not have access to.


_.___________

[DocAElstein]

Part 2


I am stuck on the point that
_ I think I can make / instantiate objects that are black boxes that I can’t see, which are made from my Custom class, who’s innards I do have some very limited access to, albeit via the interface I see as a class module that I added.
_ Microsoft have something that can reasonably be considered to be a class of a worksheet, and they pass something on to me that has a few of them made, like cookies in different flavours , SheetFlavour1, SheetFlavor2, SheetFlavour3
They are not much different from eachother.
I don’t have a direct access to that cutter , but the .Add uses it, to give me some more Cookies. I do have a very limited access to some of the final cookie innards with some ways to effect them in some way. That is via the spreadsheet manually, or the window called the worksheet code module, and those two things I think can be reasonably considered to be the same thing, in a broad sense, which I can refer to as that worksheet, or that worksheet object, if I am feeling brave.


I am not saying that the worksheet code module is not a class module, but so far I have heard no convincing argument that it is.

I have put forward arguments that a worksheet code module can be considered to be an object module, but not seen any direct argument against it. But as ever, it could be me being slow to get the point, or the usual problem that knowing something does not always mean that it’s so easy to get it across to someone that doesn’t.
I will definitely re read a lot of times all that you have written. The penny my drop

Thanks again. I know it can be annoying when an idiot doesn’t get it. Outside of computing which I got a bit late into, I usually experience it the other way around. Most of the neighbours see me as the local professor, thankfully they don’t ask too often about advanced computing things – mostly because a Smart Phone rules their lives nowadays, sadly.

Alan

[SpeakEasy]

>An object module is that tool

Oops,that should have read 'A class module is that tool'. I've corrected that in the post.

[DocAElstein]

Thanks, that's helpful, - when I am strugling to understand something it does not take many typos to throw me terminally off course, Lol!

[snb]

@Doc

Some reading stuff.

https://www.snb-vba.eu/bestanden/Getz_class_VBA.pdf

[SpeakEasy]

Not got the time (or energy!) to adresss all your comments. But here's a few thoughts in no particular order

>3) An object itself does not have a module; it is your IDE that has modules.
>That is a technicality again open to perception I think

Ok, so let's talk about traditional compiled software. It has source code which is compiled to object code . And it is the object code that gets distributed. The object code does not include the source code, and the end user thus does not have access to that source code. They only have access to functionality defined by that source code. And back in VBA OOP, the source code for a class is the class module. part of the problem, I suspect, is that you are conflating two concepts, and using the word 'module' to mean two things (VBA modules, which contain source code, and the compiled code that provides the functionality of the program - whether in an object or not. But that compiled code is NOT a module;' hence my comment, by the way, that "There is no module for you to see")

>I am thinking that a worksheet is an instantiated object

Well ... it depends ... but yes, sheetx is an object, not a class. It is an instance of the worksheet class, a worksheet object

Worksheet itself, however, is a class - but it is not publicly creatable (we are again getting into some of the slightly more esoteric areas of classes here), which means you, the user, cannot directly create an new instance of the class; i.e New does not work. The Worksheets object, however, CAN create an instance of the class, and return it (worksheets is what we call a 'factory object' https://en.wikipedia.org/wiki/Factory_( ... ogramming))

>met OOP (which VBA isn’t, but tries to act like – according to other smarter people here and elsewhere , I add quickly, Lol

It doesn't meet the purist definition of OOP, since it does not support inheritance or polymorphism (although you can do some polymorphism thanks to Implements)

[DocAElstein]

Part 1 (reply to Mike, (Speakeasy) )


>3) An object itself does not have a module; it is your IDE that has modules.
>That is a technicality again open to perception I think

Ok, so let's talk about traditional compiled software. It has source code which is compiled to object code . And it is the object code that gets distributed. The object code does not include the source code, and the end user thus does not have access to that source code. They only have access to functionality defined by that source code. And back in VBA OOP, the source code for a class is the class module. part of the problem, I suspect, is that you are conflating two concepts, and using the word 'module' to mean two things (VBA modules, which contain source code, and the compiled code that provides the functionality of the program - whether in an object or not. But that compiled code is NOT a module;' hence my comment, by the way, that "There is no module for you to see")


I am not sure if I was conflating, maybe I was doing it, and didn’t notice – I got a ton of great tasting Veggie meat balls for free recently, and I could literally get a van full more if I wanted, so I am trying to eat through them before they go bad, maybe that caused me to conflate, apologies if I did. I got plenty of windows open as usual, so that should limit the damage.
But I jest, :) , - more seriously now…
I didn’t meant to give the impression I was conflating two different things. I think I was not intending to be talking about compiled coding as that scares me. I am thinking just that
_ a copy of the text in the class module inside some thing not too dissimilar (in terms of a square window and icons) in the VB Editor might be a nice thing to appear , or for you to imagine it to appear, after you instantiate an object from the class
,_ and that the name of the thing appearing might be the name of the variable used in the insanitation

I think that I was meaning the VBA modules, and meaning that in a similar vain of allowing myself to perceive that a spreadsheet exists, I was being so bold as to take the liberty to perceive that an object module looking not too dissimilar to the VBA worksheet modules existed after an instantiation of my custom class object.
I am very grateful that you qualified your "There is no module for you to see" , it makes sense what you are saying, I think I take your point.

I am at the level of high up end user that can reasonably suggest/ perceive that a spreadsheet, for example , exists, even if you might correctly convince me that it doesn’t. ( To be honest I long since had my suspicions myself, Lol – I figured Excel is more like a single cell, and what I perceive as a spreadsheet is some set of offsets synchronised to the voltage levels on the scan coils of my screen tube that goes across, then down then across, building up this picture to deceive me into thinking I have a spreadsheet,….. but that’s another Alan Theory for another day , perhaps )

I guess as a laymen I am saying that the source code that is the class can be thought of, in layman terms, as, just text on paper, whereas the code for example in a VBA worksheets code module that we physically see in the VB Editor and can run in step mode, is, as I perceive , a bit more substantial in some way, which way exactly I don't care to try to define just yet, but as it is more substantial, as such, it is perhaps, or has in it, slightly more "real" coding in a layman sense. But I am taking your point, - if I understand it correctly, that it is still source code.
I want a term that allows something to be a bit more substantial, in a perception sense, as a piece of paper with text on it, and an instantiated object’s (source) code was kind of making me think I could tie it into, and regard it as, part of, the thing we refer to as the worksheet (object)

_.___

To explain again a bit better, If I may, referring to my ramblings from here , which I am busy revisiting and reviewing in light or our discussions…. (Please note to only look from/ beginning at that link which should take you to page #3 , starting at post #21)

So, This I can see with my eyes already , - it’s the custom code module, that I added, and named FileOpenWatcher

my custom class module that I have got.JPG

I got this next coding somewhere else, (less important where), and that coding, amongst other things, instantiates from that class, using a variable, MeWatcher. ( That variable, is then referring to my new instance of the class).

Do an instanciate and fill a property.JPG

I think it would be nice to have had this sort of thing pop up after that Instanciation, and that popped up thing would had the name MeWatcher , and I would like if it’s icon was in the VB Editor left hand explorer window at some similar looking level as the worksheet code module icons. (So this next screen shot is not something I can see – it is what i would like to see, and what I currently like to perceive when trying to understand these things

What I would like to apppear after my instantiating.JPG

I would not want to be able to edit it that last thing, and perhaps after it popped up I should either be banned from editing my class module, or, if I do edit that coding, then those changes should be immediately reflected in identical changes in my MeWatcher module, and or visa versa. – One is what I describe as text on a piece of paper, and the other is "made" from it, so they need to look the same,and so changes in one would somehow automatically be reflected in the other. Or, alternatively, after the first instantiated object is made , then editing is banned, and if I wanted to change something I would have to delete the two things and start again.

If I had that thing that I would like to have, it would then be nice that a step debug mode run of coding , if appropriate, went through that MeWatcher module, rather than me having the option to "break into class module", FileOpenWatcher, - since I can’t run coding in my added class module, (which I think is good and correct), so I should not be allowed ever to step through it either. I admit that the option is a useful tool to have, but I would prefer it to be possible to do it through this alternative way I have suggested.