Passing a control name to a function

[vicissitude]

Hi,

I want to pass the name of a form control to a function so the function can check the value of that control (Check box)

i.e. If Forms![FormName].[CheckBox] = False then .....

Would you send it as a string or a control or ??? and if so how would you go about using that as a control reference?

Many thanks.

 

[boblarson]

In a function you could use:

Function Something(frm As Form, ctl As Control)

   If Forms(frm.Name).Controls(ctl.Name) = False Then ...

And to call it would be

Call Something(Me, Me.YourControlName)

 

[vicissitude]

Ta very much, worked like a treat!

One more thing.......

When calling the function must you declare a variable and then make the function equal to that variable to make it work? Even though you are not getting a value returned from the function?


i.e.

Dim intDone As Integer

intDone = Holidays(Me, Me![Mon(AM)], "Holidays M(am)", "Monday morning")

 

[stopher]

You can just call a function:

Call Holidays(Me, Me![Mon(AM)], "Holidays M(am)", "Monday morning")

Any return value will be ignored.

But if your function never returns a value then consider making it a subroutine instead (and call the subroutine)

hth
Chris

 

[vicissitude]

Ahh I see, thanks, that makes much more sense than the way i was doing it!

All working nicely now.

Thanks Again!

 

[boblarson]

But if your function never returns a value then consider making it a subroutine instead (and call the subroutine)

Perhaps, but it isn't necessary. In fact, I gave a talk on that at a user group meeting once. There are actually good reasons to just use functions and NOT use subs.

And I have not heard a good argument about why you shouldn't just make everything a function.

 

[stopher]

Perhaps, but it isn't necessary. In fact, I gave a talk on that at a user group meeting once. There are actually good reasons to just use functions and NOT use subs.

And I have not heard a good argument about why you shouldn't just make everything a function.

Good point Bob. The same thought could probably be applied to many concepts in VBA.

I think it's about following the style of VBA and being explicit. The segregation of functions and subs has been visible in VBA for as long as I've known it. Moreover, any text book on VBA will state the same. So while the common thought may not be best practice, by virtue of the fact that it is the "common thought" makes it good practice - because it will be clear to others what you are doing. So, if I declare a subroutine then it is explicit in that I don't intend to return any values. If I declare a function, then I'm indicating (through popular belief) some intention to return some value.

Chris

 

[boblarson]

Well, Chris - one reason would be that you might not know if you will need to access something from a query or macro (even though you might not need a value). Now, if you build them as subs, you will then have to go change them to functions to use them in those situations. So, if you always use functions then you never have to go back and rewrite for those reasons. And, as I will attest - in 2003 and prior you might be able to reference a sub in a control source but you cannot in 2007 and above).

 

[boblarson]

Oh, and also if you want to know whether it returns a value or not just look at the function header. Just calling a sub or a function won't tell you, so you have to look at the header anyway. If your function doesn't have the AS SOMETHING after it - no value, if it does then a value.

 

[stopher]

Well, Chris - one reason would be that you might not know if you will need to access something from a query or macro (even though you might not need a value). Now, if you build them as subs, you will then have to go change them to functions to use them in those situations. So, if you always use functions then you never have to go back and rewrite for those reasons. And, as I will attest - in 2003 and prior you might be able to reference a sub in a control source but you cannot in 2007 and above).

Personally I’m usually pretty clear about the purpose of a routine. But if I had to change a sub to a function then this is a trivial exercise. But equally I can see why you might want to err on the side of caution and use a function in this instance.

But this really isn’t a compelling reason to “make everything a function”. Let’s be honest, the pros and cons you and I have given are all pretty weak so I guess it’s down to personal style.

Chris