Am I to assume that VB doesnt support function overloading? 4

[wolfie78uk]

In C++ functions can be 'overloaded' (i.e two functions share the same name but recieve different parameters and behave differently). This doesn't seem to be possible in VB.
Rather than making a mess of the application that I am building, I have created the following code to test it :

Private Sub cmdNo_Click()

Call ShowNumber

End Sub

Private Sub cmdWith_Click()

Call ShowNumber(25)

End Sub

Private Sub ShowNumber()

lblShow.Caption = "No parameters received"

End Sub

Private Sub ShowNumber(ByVal Number As Integer)

lblShow.Caption = "Parameter received is " & Number

End Sub


It doesnt even run. I recieve the error "Compile Error : Ambiguous name detected : ShowNumber.

It is not the end of the world if this can't be done but if it can be I would prefer to use it.

Cheers.

 

[patrician]

Hi you could try the optional keyword in the parameters list, the = 0 is a default value(not really needed but helps with error trapping) if nothing has been passed

for example

Private Sub ShowNumber(optional ByVal Number As Integer = 0 )



lblShow.Caption = "Parameter received is " & Number

End Sub

 

[CajunCenturion]

VB does not in the true sense provide for function overloading as in C++. But the simple example that you gave can be done using an Optional argument and the IsMissing function.

Private Sub cmdNo_Click()

Call ShowNumber
Call ShowNumber(25)

End Sub

Private Sub ShowNumber(Optional Number as Integer)

If IsMissing(Number) Then
lblShow.Caption = "No parameters received"
Else
lblShow.Caption = "Parameter received is " & Number
End If

End Sub

I would suggest that you look in the MSDN about the restrictions on Optional arguments. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[CCLINT]

uh, CajunCenturion, have you forgotten? That (IsMissing)doesn't work, as it used to, any more that way with variables declared as strings or numbers....they automatically default to "" or 0. You can now only do that now with variants....
The best thing that can be done in those cases is to assign a default that would never be passed under normal cases when used as intended, or if 0 or "" would never be used:

Private Sub ShowNumber(Optional Number as Integer=-9999,Optional sString as String = "ITWILLNEVERBETHIS&quot

Select Case Number
case 0
'do nothing
Case 1
'do something
case 2
'do something else
case else
'do nothing

end select

Select Case sString
case "ITWILLNEVERBETHIS"
'do nothing
case ""
'do again nothing
Case "ABC"
'do something
case "XYZ"
'do something else
case else
'do nothing

end select

 

[CCLINT]

Shoot,
I need to preview my posts more often....

 

[CajunCenturion]

you are quite correct CCLINT - how quickly we forget - my apologies.

Here's your star. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[CCLINT]

CajunCenturion : I also have to take a re-check sometimes.
By the way, I'll get back to that binding post one of these days. Just a bit bound myself on the subject right now, and the fact that I got a little concerned at what happened.....

 

[CajunCenturion]

I'm looking forward to your comments. Sometimes we, or at least I, get so used to doing things a certain way, because it works, and it ain't broke.... But it always a good idea to keep an open mind, because sometimes a better way does come down the pipe and we/I miss it. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[strongm]

Ah, now you see, we had a thread a few days ago about the pros and cons of variants. This is one of those times when variants come in handy (and I've slightly extended the remit to include strings as well):
[tt]
Private Sub ShowNumber(Optional varInput As Variant)
Dim strDisplay As String
If IsMissing(varInput) Then
strDisplay = "No parameters received"

Else
strDisplay = "Parameter received is " & varInput & ", which is "
Select Case VarType(varInput)
Case vbInteger, vbLong, vbSingle, vbDouble, vbDecimal
strDisplay = strDisplay + "a number"
Case vbVString
strDisplay = strDisplay + "a string"
Case Else
strDisplay = strDisplay + "neither a number nor a string"
End Select
End If
MsgBox strDisplay
End Sub

Private Sub Command1_Click()
ShowNumber
ShowNumber 5
ShowNumber "Hello"
End Sub

 

[strongm]

Oops - second Case statement should, to be consistent, read
[tt]
Case vbString
[/tt]
rather than
[tt]
Case vbVString

 

[Foada]

Thank you strongm ! In the thread222-317103 that is exactly what I said about the use of the variant type. If you choose to battle wits with the witless be prepared to lose.

 

[strongm]

You did indeed , and this was a prime opportunity to illustrate the point.

 

[CCLINT]

Quite so StrongM.

I have some similar properties and functions.

But what if I pass a string that looks like a number but should be dealt with as a string?

The right tool for the right job!
Now I'll look at that thread.

 

[CCLINT]

>But what if I pass a string that looks like a number but should be dealt with as a string?

That wasn't knocking anything...Just food for thought for anyone.

 

[strongm]

Well, I suggest that you try it with the routine as presented. If you pass a number as a string, it get's recognised as a string...

 

[CajunCenturion]

While on the discussion of function overloading, with different argument lists, should we bring the ParamArray construct into the discussion?

That's another way to pass an indefinate number of arguments into a routine. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[MichaelRed]

Hmmmmmmmmmmmmmm,

Missed the invitation. Is this the annual meeting of the mutual admiration society?

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[strongm]

>the mutual admiration society

Well...we're entitled to it every now and again...

 

[CCLINT]

strongm, of course, you are right, here - as I said I have instances almost of identical use, and that is how VarType works, (eval the variant type and not the value).
I was late and fast on the way out the door, and doing some copying and pasting at the same time.

I do not know what in the world I was thinking of here and I guess it's time for another vacation.

Prosit over the channel there in GB.