Passing controls to routines and class methods

[mssngr]

Hi,
I've got my L'plates on and am having a bit of trouble passing objects to subroutines.
I'm sure I am missing some basic concept, but all the wading through help files and doco hasn't shed any light for me.

I have a form with a checkbox on it, I am trying to pass a checkbox to a subroutine. For instance,
sub dosomething(cb as checkbox)
'eg
if cb.value = true then
'do stuff
end if
end sub

I call using
dosomething(myCheckBox)

and on debug I find that the the mouseover gives me myCheckBox = false (or true) and an error saying an object is required is given.

I can get it working by passing the value instead, but my problem is understanding passing of objects generally, I think. Sorry of this is a no brainer for you all, but I don't get why if I'm telling a routine it should receive a CheckBox, and then sending what I believe is a CheckBox, doesn't work!? I have tried a few things and the problem seems to lie in VBA seeing the myCheckBox string as a value, not an object reference.

Please help the confused.

thanks,
Angelena

 

[michaelbr55]

Hi Angelena,
I'm not exactly sure what you are trying to do, why dosomething(cb as checkbox) at all, just dosomething()
and call dosomething.

Mike

 

[mssngr]

Sorry, I guess my example is too broad.
Your suggestion doesn't really help. I am looking for someone to show me the light regarding passing objects and using classes, I think. I can make it work as easily as you have suggested, but I can't make it work the way I want it to work.

To be more specific here is what I'm doing:

I have a form on which I have groups of information. (Log information eg name, search strings, etc).
This group is repeated and I want to send a list of the data for this repeated group to my workhorse - the application module.
It seems the best way is to encaspulate the data for each group as an object (user defined class) and pass on the collection of similar objects, so I can do (psuedocode):

For each object in myLogCollection
process the log using the info in this object


A few things:
The app. interacts with several worksheets. The code for worksheet interactions are in their own module - keeps 'em neat and makes 'em easy to find.

The code for the form is in the form module.

The code for the guts of the app are in their own module.

Now,
When a user clicks the checkbox mentioned last time, I want to set/unset values in the class object I will be sending to the application.
(I realise I could just reference anything from just about anywhere, but I like to set contracts and structure my code. Bad habits I've picked up over the years. )

So in the Form Module I define:
dim myClass as new cMyLogClass

checkbox_click()
myclass.selectlog(checkbox)

Class Module:
Dim bLogIsSelected

sub selectlog(cb as checkbox)
bLogIsSelected = cb.value
end sub

Undoubtedly I've got things wrong here...
I don't think I have understood the definitive rules around classes and creating/passing of objects in VBA, but I have two books, and neither these nor help files are very clear on the steps to take or things to remember.
Should I be defiing as sub selectlog(cb as object) and if so WHY???!!!!

Angelena

 

[Zathras]

...The code for the form is in the form module....The code for the guts of the app are in their own module...

For what it's worth: Everyone develops their own style, but I think you have a contradiction here. I would submit that the app module should not have any knowledge of the user interface (or the objects therin). The fact that the boolean value was obtained from a check box is not important. Only the code in the form needs to "know" that. The app code only needs to know the boolean value. This insulates the app code from the UI so that when the UI is modified, the app code need not be affected.

In this case, you are currently using check boxes. It may be that as the number of check boxes increases, you will want to replace them with a list box (with ListStyle and MultiSelect properties set to display a list of check boxes.) IMHO, the best structure is that which restricts the scope of changes to as few modules as possible. If your app module has to cope with the form objects, this sort of change becomes more difficult.

 

[mssngr]

Zathras,
YES! I know, and you are right.
I think my L'Plates fell over my eyes!

Mike - I apologise for misunderstanding your post - I think you were getting at the same thing as Zathras - just more briefly.

I did some mucking about last night, found the "Implements" example and worked through it carefully. I think I have my head round the class thing now.

Without re-reading my twatish ramble above, separation of the UI from the app module is really what I meant to achieve.
I have since defined a class, an instance of which gets created in the Form code, and populated with the data found on the form, and the object (containing only the data including the boolean checkbox value) is passed to the app module.
The app module does not know anything of the form only the data object sent to it.

The error was not actually the passing of the Checkbox object - which as you point out, was the wrong thing to do anyway, but my misunderstanding and misuse and mis-definition of the class (properties, and declaration of object variables). I gleaned a few rules out that example, and would be willing to share them with anyone who finds the help files too terse and disjointed to come to grips with the class implementation quickly.

Thanks for your posts.
Angelena