Quicky on "Overloaded"

Quote:

---

Originally posted by AFterlife

Quote:

---

Originally posted by Mike Hildner
Side note.

Although I guess I understand the "rules" of rounding, logically this does not make sense to me:


visual basic code:--------------------------------------------------------------------------------
MsgBox(Math.Round(42.5, 0)) ' Displays "42"
MsgBox(Math.Round(43.5, 0)) ' Displays "44"
--------------------------------------------------------------------------------

But that's the design.

---

also your msgbox is legacy code for message box
it should be messagebox.show(and in here goes your stuff)
it is a overloaded procedure so its much more versatile then
msgbox.

---

Overloaded. Exactly what does that mean?
And, if MsgBox("Whatever") achieves satisfactory results, even if messagebox.show, being "overloaded", is much more versatile, why would messagebox.show("whatever") be better than msgbox("whatever")?

Is it a speed thing? Does it give the user .01 more milliseconds to notice that a msgbox has popped up?

:wave:

Overloaded is a OOP concept. Basically, it gives you one function name, with multiple sets of arguments...

VB Code:

Public Sub DoSomething(ByVal x As Integer)
    '...
End Sub
 
Public Sub DoSomething(ByVal x As String)
    '...
End Sub
 
Public Sub DoSomething(ByVal x As Integer, ByVal y As String)
    '...
End Sub

As long as the function signatures (the order of the datatypes of all the parameters) are unique, you can have several procedures of the same name that do slightly different things.

And the reason to use MessageBox.Show instead of MsgBox is because you don't want to bind yourself to back level code. If MS decides to take away compatability for some reason, your code will no longer work.

Quote:

---

Originally posted by crptcblade

As long as the function signatures (the order of the datatypes of all the parameters) are unique, you can have several procedures of the same name that do slightly different things.

---

Neat!
Nice Info!

Quote:

---

Originally posted by crptcblade

And the reason to use MessageBox.Show instead of MsgBox is because you don't want to bind yourself to back level code. If MS decides to take away compatability for some reason, your code will no longer work.

---

Very True. Very Similar to how Picturboxes don't have AutoRedraw in VB.Net, so you have to figure the BitMap workaround out.

However, are you suggesting if you've used the back level code in a project, and compiled it to a binary, that if the .Net Platform changes, that the binary won't function anymore?

Well, I doubt that kind of thing would happen any time soon, but who knows with MS. ;)

What I was really going at, was if you need to do any sort of update to the program, you might be caught by surprise one day when a newer version of the compiler doesn't accept VB6 code anymore.

Quote:

---

Originally posted by crptcblade
Well, I doubt that kind of thing would happen any time soon, but who knows with MS. ;)

What I was really going at, was if you need to do any sort of update to the program, you might be caught by surprise one day when a newer version of the compiler doesn't accept VB6 code anymore.

---

Hmm anyways I highly doubt it....at least in the following years. Anyways im in C# so I use MessageBox.Show()

If you try to create an overloaded procedure in VB6 youll get a ambigious name detected. They are nice to have.

Quote:

---

Originally posted by PT Exorcist
Hmm anyways I highly doubt it....at least in the following years. Anyways im in C# so I use MessageBox.Show()

---

I highly doubt it, too, but the point is, if something is only there to support backward compatibility, then you shouldn't rely on it always being there.