How to pass listbox or string as a parameter to a function? 1

[may1hem]

Hi, I want to create a general function which accepts either a string or a listbox. I've tried to use a variant but this doesn't work.

Public Sub FnDoStuff(IdStringOrListbox As Variant)
'Do stuff here..
End Sub

How can I get the function to accept either a string or a listbox?

 

[MajP]

only way would be to have optional parameters

public sub FnDoStuff(Optional str as string, optional lst as access.listbox = nothing)

if not string = ""
'do string stuff
else if not isnothing(lst)

end if
end if

This is why other languages like vb.net are nicer. You can have the same function with different parmeters. When you call the function it finds the one that matches the same number, order, type of signature.

 

[MajP]

second endif is a typo.

 

[may1hem]

Ok thanks MajP, I thought about that but thought there must be a way to pass whatever I like to a function using just 1 parameter.

I'm coding using VBA for Outlook 2007. Is there a way to use VB.net with Outlook instead?

 

[MajP]

Unfortunately you have one value type (string) and one reference type (listbox)
If they were both reference types (objects) or both value types it could work. If they were both value types you could accept a variant argument and cast it to determine what it was. If they were both reference types you could accept an object and then use typeof to determine what type of object.
You can not use vb.net in outlook but you could build vb.net application that uses outlook objects. What are you attempting?

 

[may1hem]

I see...

I'm using VBA to reply to emails. I create a button on the toolbar which runs my VBA code, which generates an email reply.

Could I do the same with VB.net? How do I get started with this? I have Visual Studio 2008 but don't use it. Would there be any advantage to using VB.net?

 

[may1hem]

I've been thinking, would it be possible just to pass one value to the function as a string and then inside the function test if it's a valid listbox otherwise assume that it should be a string?

 

[strongm]

>but thought there must be a way to pass whatever I like to a function using just 1 parameter

There is

>I've tried to use a variant but this doesn't work

It does (or at least it should)

[blue]Private Sub fnDoStuff(IdStringOrListbox As Variant)
    Select Case TypeName(IdStringOrListbox)
        Case "String"
            MsgBox "It's a string: " & IdStringOrListbox
        Case "ListBox"
            MsgBox "It's a listbox, currently selected: " & IdStringOrListbox.List(IdStringOrListbox.ListIndex)
        Case Else
            MsgBox "fnDoStuffExpects a string or a listbox. You have passed a " & TypeName(IdStringOrListbox)
    End Select
End Sub[/blue]

 

[thefarg]

Nope. Variants cant be an object. Perhaps for a string you could create your own object and use a property to hold the string. When passes to your function, the fuction can ascertain whether its a listbox or a "MyObject" etc and process accordingly.

 

[PHV]

Variants cant be an object
Really ?
Where did you see that ?

 

[strongm]

>Variants cant be an object

You might perhaps want to check up on that

 

[MajP]

Although you could do that, I do not think I would. I would consider that poor coding. There is a reason for signatures and good reasons to avoid variants. You do not want to catch those errors at runtime you want to catch them in compile. Do yourself a favor and write three functions. One accepts a string, the other a listbox, and they both call a third function with the majority of the code. My guess the listbox pulls a string value. So maybe it is really just two functions. One just takes the listbox, gets a string and calls the second.

 

[strongm]

>poor coding

Afraid that I have to disagree with you. It is perfectly reasonable VBA. VBA is not a strongly typed language (indeed, it is in fact less strongly typed than early versions of VB), and variants exist for a good reason (they are for example about the only way we can achieve function overloading in VBA, which is what we've done here)

Indeed, in your 3rd post you explicitly suggest exactly such a solution, only casting (sic) it aside because you didn't think it could be done

you could accept a variant argument and cast it to determine what it was

 

[MajP]

I agree there is a reason for variants especially in a working with Access where the value of a database can return a value or null. When I said avoid I should have said "when at all possible", that is what I meant. Did not mean that there is absolutely no place for them.
I still would avoid it, and not recommend it in this case. Simulating "overloading" with an if check inside the method saves nothing, and makes the code more likely to error at runtime.
The developer decides at the last minute they want a combob box instead of a listbox. Seems reasonable. The Code compiles fine but the logic does not match and is caught at runtime.
A small method to accept a listbox and pass a string to the second function that accepts a string, is as succinct or more succinct and less likely to cause problems.

 

[strongm]

We'll just have to agree to disagree, I'm afraid.

>and not recommend it

But you did, as I've already pointed out. Which is why I find your somewhat strong criticism of the technique as somewhat odd.

 

[may1hem]

Thanks Strongm, that code snippet worked perfectly!

Thanks for the idea MajP, but it was important to write only 1 function.

 

[combo]

To avoid errors and simplify coding one can use extra variables, in strongm' example:

Private Sub fnDoStuff(IdStringOrListbox As Variant)
    [!]Dim strIdString as String, lstIdListbox as Listbox[/!]
    Select Case TypeName(IdStringOrListbox)
        Case "String"
            [!]strIdString = IdStringOrListbox[/!]
            MsgBox "It's a string: " & IdStringOrListbox
        Case "ListBox"
            [!]Set lstIdListbox = IdStringOrListbox[/!]
            MsgBox "It's a listbox, currently selected: " & IdStringOrListbox.List(IdStringOrListbox.ListIndex)
        Case Else
            MsgBox "fnDoStuffExpects a string or a listbox. You have passed a " & TypeName(IdStringOrListbox)
    End Select
End Sub

combo