Class Modules - PredeclaredId ?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi All,

I have set the PredeclaredId of one of my class modules to "True" and
stepped through the code only to see the class initialize and terminate
events are never touched. However, the recordset variables and the
dao.database variable which were intantiated in the class initialize event
have returned the expected results.

Could somebody please throw light on how VBA handles the PredeclaredId and
what happens behind the scenes ?

Thank you.
 
Could somebody please throw light on how VBA handles the PredeclaredId and
what happens behind the scenes ?
Click to expand...

gee, never heard of this. Is this an actual feature of VBA????? (it's
certainly possible it's a feature, or something that I don't know about in
access, but I not herd of this).

PredeclaredId does not show up in the help files at all, and I never seen it
mentioend here..
You might want to expand on where this comes from, or what context you're
using this variable, but I don't believe it's part of MS access...
 
Sorry that I couldn't be more elaborate. What I did was to export the class
module from Access as a file. Then I opened it with notepad, and using Access
2003, I got the following info in the first lines of the class.

------------------------------------------------------
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 'True
END
Attribute VB_Name = "clsCustomer"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False ----->> changed to 'True'
Attribute VB_Exposed = False

-------------------------------------------------------

Now, what I can do is, use the class without ever explicitly declaring it
and all the methods and properties are available.

But I'm afraid unless I understand how it works, I can't write 'informed'
code.
 
ah, ok....

I would suggest that you avoid using that internal flag. as you can see, it
is not normally exposed to the developer at all.

The reason for the existence of the flag is actually quite simple

in access 97 you were able to declare and create class modules, but you did
not have to declare an instance of a module in code to use the methods and
properties of that module (exactly the situation you describe into me now).

In access 2000 later, we essentially got the same coding environment as VB6.
What this means is that to use a class object, in access 2000 and later you
MUST declare an instance of that object in code, and then use that instance.
(and, I highly recommend you stick to this approach).

However what that flag does is allow access 2000 and later to "convert" an
access 97 application and it will continue to function. In other words in
access 97, there's still a a bunch of code lying around that people wrote
with the idea that you can use the properties and methods of an basic class
object, but not have to declare an instance of that object.

I see little, if any reason to continue, or to attempt to use this setting
that is really designed for backwards compatibility.

I suppose one could argue that a tiny amount of additional memory is used up
in the fact that you now MUST declare a separate instance of the class
object to use its methods and properties. However I suspect it this also
means that when your application loads, those class objects do not have to
be created until you actually use them in code. with a97, it would have to
always loaded. (perhaps the instances only created when you actually
reference it in code, but once again I don't see an advantage to this fact).

In a nutshell, that's setting is provided for backwards compatibility when
access converts an older (pre 2000) application.

I can't think of any real advantage of being able to use class modules
without declaring an instance of them in code.
 
Back
Top