class modules: why? (1 Viewer)

[Darth Vodka]

is it me, or is there rarely a need for class modules in VBA?

or arrays for that matter...

if i need an array or an object, i represent it in a table and work with that

perhaps i'm sticking to what i know, but can anyone tell me where they used a class module because it was by far the best method to use?

especially for a generic task

 

[Banana]

I use it.

But first thing you need to know is that for 90% of the problems Access developers face, class module are either overkill or too much work for little gain. The problem is that Access/VBA are object-based, but not fully object-oriented, so that limits the potential of class modules, which is why they tend to get neglected.

Anyway, what you can do with a class module are basically for two things: 1) when you need events, 2) when you need multiple instances of same thing.

Custom events can be declared in a class module, but you are responsible for raising it yourself, and it's hard to think up of event where you really need to be raised that isn't already done by a given form or control's event. In my case, it was an exception because I am able to manually control transaction and thus needed a event to do validation before I commit the transaction (useful for multi-form validation for example).

As for multiple instances, suppose you needed to maintain copies of recordset that has to be presented in a certain way. Using class module allow you to create a "cookie cutter" defining all the parameters you want it to be, then you don't have to worry about it when you declare an object from the class because it take care of all tedious work. Of course, this is only useful for stuff within code such as recordsets, arrays, collections, or a certain type. Class modules doesn't interface so well with controls (e.g. I can't really create a Cascading Combobox class where I can just drag'n'drop into a new form and BOOM! two comboboxes with all the code to cascade properly! [Well, technically, it can be done, but that's beyond the scope]).

It can be also used as an alternative to Type; VBA is kind of pesky with user-defined Types but can handle the objects created from a class much better, so using a class to define a type is a good use as well. I created, out of fun, a class module that defined a signed byte data (which was just an integer but with range truncated to -128 to 127 and raising an overflow error for values outside that range).

I hope that helps a bit.


Tangent: I personally find Collection to be more useful & flexible than array, but that's just me.

 

[chergh]

Never found the need for class modules but arrays are damned handy. Maybe their isn't so much need for arrays in Access VBA but I use them a lot in excel and on occasions that I use word, and split is handy little function that makes use of arrays.

 

[DJkarl]

I generally agree with the previous posts, but I'll add my two cents on Class Modules.

I use them sparingly, but I've found them useful to encapsulate common or frequently used code relating to automation.

IE
I am required to do a lot of Excel reporting and manipulation in my day job, now while I could go and write code like

Dim exAPP as Excel.Application
Dim exWB as Excel.Workbook
Dim exSHT as Excel.Worksheet

I find it much easier to write

Dim exObject as ExcelClass

I can then use class module object in lieu of creating individual objects each time. This is beneficial for me due to the high volume of Access to Excel developement I do, the Class module was a bit of work to setup but for me it was well worth the effort.

 

[Banana]

Djkarl, this is quite an excellent example, even better than my fairly estoric applications. Hopefully, others will see the benefits more clearly, as this is more relevant, and I would so love to just not worry about individual objects. Just tell my code to "put it there and here." and be done with it.

 

[Darth Vodka]

I generally agree with the previous posts, but I'll add my two cents on Class Modules.

I use them sparingly, but I've found them useful to encapsulate common or frequently used code relating to automation.

IE
I am required to do a lot of Excel reporting and manipulation in my day job, now while I could go and write code like

Dim exAPP as Excel.Application
Dim exWB as Excel.Workbook
Dim exSHT as Excel.Worksheet

I find it much easier to write

Dim exObject as ExcelClass

I can then use class module object in lieu of creating individual objects each time. This is beneficial for me due to the high volume of Access to Excel developement I do, the Class module was a bit of work to setup but for me it was well worth the effort.

funnily enough the only time i've ever used a class module was when i was translating data into Excel workbooks, complete with graphs. I created an Workbook object that had sheets and graph collections and properties of graphs before creating Excel stuff in Excel itself

 

[georgedwilkinson]

I use modules to enforce object oriented principles (encapsulation) and to reduce my code base. I'm just way too lazy to type everything into a form module.