How to create a constructor(OnLoad-Event) for a user-defined class?

[Billiska]

Well, I ask this question because I'm rather familiar with C++ than VB.

I've just tried to create a class in VBA and found that I have to write some certain lines every time I want to create a new instance of the class.

So, isn't there a way to create a autorun subroutine for initializing a user-defined class?, like "constructo r" in C++.

Thanks

[janders468]

Yes, for every class if you include this sub it will run on instantiation of the object:

Private Sub Class_Initialize()
   'Do whatever here
End Sub

Unfortunately vba doesn't offer method overloading so you can't easily pass arguments to the constructor, but it has a limited ability to do what you are after.

[missinglinq]

While you can create user-defined classes in Access VBA, it's not an important feature of Access, like it is in C/C++. Few developers use them, and thus VBA gives little support to them. The fact of the matter is, Access addresses most of tasks C/C++ developers use them for with native Access/VBA functions.

Welcome to Bytes!

Linq ;0)>

[Billiska]

Thanks for the good advices.

I am self-taught and would never find this out by searching in the built-in help.
Are there any better references for MS Access, which I try to find what I want before posting in this community?

[missinglinq]

First line of defense would be search here or on other Access sites. Then use a search engine. I usually lead with +"ms access" then an appropriate, short description, like "Cascading comboboxes."

In a more general vein, spending some time here and elsewhere "browsing" thru posts is a great way to pick up pointers! You can be assured that anything you come up against has been encountered by others, and the answers may already be here.

Here's a list of tutorials, listed from the easiest to understand to the more difficult.

Chrystal has an excellent “basics” tutorial:

http://www.accessmvp.com/strive4peace

This is a little more advanced, but still a great starting point, having 23 well written, well defined, clearly named chapters.

http://www.functionx.com/vbaccess/index.htm

Jeff Conrad's resources page:

http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:

http://www.mvps.org/access/resources/index.html

Allen Browne's extensive listing of tutorials:

http://allenbrowne.com/links.html#Tutorials

Linq ;0)>

[Billiska]

Got it, thanks a lot.

[FishVal]

Fathers,

I would agree with the following:

VBA has almost no pointers arithmetics.
VBA does not support class inheritance, polymorphysm and many other features of OOP.
VBA does not support function/operator overload.
VBA is macrolaunguage and could not be recognized as true programming launguage.

But I would not agree with a statement:

VBA OOP features are too poor to even try and many Access developers do not use them because they are too good in OOP. ;)

Every Access developer no matter whether he/she is aware of it is doing OOP programming. ;)

Each time you create a new form or report, you create a new class - Access automatically names it as Form_<formname> or Report_<reportn ame>.
Form/Report module is actually (to some extent) a class module.

Every public function/sub declared in a form/report module is method of the class. It is not used by many Access developers but properties and events could be declared in form/report module just like as in "regular" VBA class module.

The class may be instantiated in regular way, after which all its properties/methods/events will be available via correspondent object variable.

And, actually, I would stay that VBA OOP could greatly enhance database design and make things easier and more reliable. To say nothing about numerous little tricks very hard or even impossible to implement without dealing with VBA explicitely. ;)

Example: Starting MS Access from vba

Kind regards,
Fish