https://www.excelfox.com/forum/showt...ll=1#post24214
https://www.excelfox.com/forum/showthread.php/2966-Class-related-Stuff-New-Instancing?p=24214&viewfull=1#post24214
https://eileenslounge.com/viewtopic....317565#p317565
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, Sheet, 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
I think a Userfom, is a class module, the others not
_.____
* 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
I don’t know why a normal module won’t allow a declare WithEvents. I don’t see how it being allowed in the other modules proves that they are class modules . Something in these other modules allows for, and they primarily are about, event coding. Maybe that has some thing to do with it
https://eileenslounge.com/viewtopic....317579#p317579
https://eileenslounge.com/viewtopic....317582#p317582
_ 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 class 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.
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.
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")
…… see later , next post https://www.excelfox.com/forum/showt...ll=1#post24215
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. ) )
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/Factor...programming%29
I think we are agreeing on things to do with the New for a worksheet declaration not working. But you have made some useful references for me to come back to , at a later date if I am able to , in order to get a better low level understanding. Thanks
Perhaps the .Add is a factory method?
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
Notes original good bits /- new things gleaned
There are many pitfalls for someone learning, at beginner level- here I talking from the side of someone struggling to have learned, not from the side someone who already knows it all , since for those already informed people, anything that is not obviously totally wrong will sound OK
_(i) Classes are sometimes explained in simple terms as templates. I would go away from that, even if it’s not incorrect. It can and has lead to many people thinking of it as some form of partially filled in thing, like a form letter, that you copy and fill in. Thinking in terms of copying is a very bad thing when discussing objects in class discussions.
Class / object discussions and copy = No No No
_(ii) Related to _(i) I think it could be helpful to refer to what is in the class module as text, rather than coding, and perhaps explain that it will be used later from which to create coding, but try to avoid the use of the word copy if possible. Perhaps that text could be thought better conceptually as like that on a Stamp
Using that stamp is part of what goes on by the so called instantiating from a class
_ (iii) At the very least, I would avoid any mention about how the thisworkbook module, and worksheets module fit into it all. Give the innocent chap trying to learn half a chance to decide himself later whether the King has a new magic suit or whether he is standing there bxxxxxk naked in his birthday suit
So far the only stated publicly explanation I have seen for calling these class modules is that we can do the WithEvent declarations and related coding in them. If that is the only justification then its some technical convoluted justification and does not help. IMHO there are many reasons to at least think of them as more in the direction of some thing , ( dare I say an object ) , closely associated with the final worksheet object to which they are unquestionably associated with, ( dare I say perhaps even the part of that object itself ).
/- A worksheet is an instance of the worksheet class, - it is therefore a worksheet object
/-Maybe Worksheets.Add is a factory method: It returns an object of the Class worksheet. Worksheets is an object for returning other objects, in this case the other objects are worksheets form the worksheet Class
/- A Worksheet is a class - but it is not publicly creatable
/- An instantiated object is a black box. – I don’t necessarily disagree that is often the case, but we have in a form that we as humans can see a worksheet, along with, for convenience, primarily to add into event coding, a module associated with each worksheet
Reply With Quote
Bookmarks