|
Need some help out there. To give an example of my problem suppose the following...
Public Module MathHelpers
Public Function Add(ByVal param1 As Object, ByVal param2 As Object) As Object
Return param1 + param2
End Function
End Module
And you wanted to be a bit more OOP by overloading the function to prevent unboxing and boxing you decide to do this. Also, not only for the aforementioned reasons you wanted to add 2 class objects that have something specific to these class objects that can be added. But leaving the parameter data type as Object will not suffice to capture the differences between say adding 2 class objects in comparison with 2 integer types. Does that make sense?
Public Module MathHelpers
Public Overloads Function Add(ByVal param1 As Integer, ByVal param2 As Integer) As Integer
Return param1 + param2
End Function
End Module
After running into this error[^]. I am bit unsure what to do next.
Since the MSDN hints that Classes can overload functions I decided if I could create a Static Class. Since that proved pointless all I want is to overload this function without creating an instance of it.
MSDN does poor job in this scenario telling me A) Why this is not encouraged to do and B) some helpful advice on how to encapsulate my functions/routines with overloading.
Any advice you can offer I would greatly appreciate.
If you need me to clarify anything just let me know.
|
|
|
|
|
Clark Kent123 wrote: MSDN does poor job in this scenario telling me A) Why this is not encouraged to do and B) some helpful advice on how to encapsulate my functions/routines with overloading.
Try overloading with using the keyword. It'll work, and I have no explanation why.
Bastard Programmer from Hell 
|
|
|
|
|
within a module you dont use the overloads keyword as Modules dont have instances.
You can achieve the two functions by
Module Module1
Public Function add(ByVal param1 As Object, ByVal param2 As Object) As Object
Return param1 + param2
End Function
Public Function add(ByVal param1 As Integer, ByVal param2 As Integer) As Integer
Return param1 + param2
End Function
End Module
the above works as you are changing the signature of the function.
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
Thanks Simon for that response. Very helpful. What I am having a hard time grasping is how is the compiler supposed to know that your encapsulating this?
For instance we use keywords in VB to let the compiler know what we want to achieve; Class, Module, Integer, etc. So by removing the "Overload" keyword the compiler will just "know" that I want to encapsulate a sub/function within a module?
|
|
|
|
|
as Dave stated you mainly use the overloads keyword when you are creating an overloaded method from a base class. But in the instance of creating overloaded methods in the same class or module it uses infered overloading
have a read of this I found this useful in understanding the difference Overloads keyword in VB.NET[^]
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
Thanks that does help. I just wish that MSDN document I linked to in my original post just said "Get rid of the Overload keyword and you will be all set". I guess that's just wishful thinking on my end.
I did check the link out that you posted. I will bookmark it so I don't make the same mistake twice. Thanks.
|
|
|
|
|
Anytime 
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
You don't have to put the Overload keyword in there unless yuo're inheriting from a base class and overloading a base method.
You just do this in a Module and it works fine:
Public Function Add(ByVal parm1 As Object, ByVal parm2 As Object) As Object
Return parm1 + parm2
End Function
Public Function Add(ByVal parm1 As Integer, ByVal parm2 As Integer) As Integer
Return parm1 + parm2
End Function
Truthfully, I would not be using Object as one of these overloads. You're casting too big of a net catching case that you didn't overload with that one.
|
|
|
|
|
Oh 
Thanks Dave for that. Since overloading is for classes and inheritance the compiler will know within a module that I am "overloading" a sub/function by just duplicating the same name sub/function, but just changing the params data types? I was always under the impression that you had to use the Overload keyword let the compiler know that you're encapsulating the sub/function.
By the way I had no intention of using the Object data type. It was the VB6 style of attempting at encapsulation even though we both know this is unhelpful in that situation.
I appreciate the advice and didn't realize my solution was that simple. Thanks.
|
|
|
|
|
Clark Kent123 wrote: I am "overloading" a sub/function by just duplicating the same name
sub/function, but just changing the params data types
Yes.
|
|
|
|
|
Hello,
I was wondering if you could programically, force/automatically pull the vertical scrollbar down, I'm using this for a chat program, and some users find it annoying, when there on chat and it scrolls completely up, each time it updates, it updates pretty much every second.
Regards,
Brandon T. H.
|
|
|
|
|
For what kind of control?? You're appending text to the bottom of a textbox or a listbox? or what?
|
|
|
|
|
A rich text box, but you could also give me the code for a plain text box.
Dave Kreskowiak wrote: You're appending text to the bottom of a textbox
Yes I'm also doing that, if it detects a new message, which there always is
|
|
|
|
|
RichTextBox.ScrollToCaret[^]
The trick with the is the caret must be at the end of the text in order for this to work. That's easy enough with RTB.SelectionStart = RTG.Text.Length.
The same code works for a TextBox.
|
|
|
|
|
How to check the double vaue is "1.#QNAN" in VB 6?
modified 7-Mar-12 5:16am.
|
|
|
|
|
Have a read of this Double.IsNaN[^]
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
This method is avaialble inVB.NET.But I wnat to use in vb6.Kindly support me for vb6 programme
|
|
|
|
|
Private Sub btnStart_Click(sender As System.Object, e As System.EventArgs) Handles btnStart.Click
lblTextHere.Text = "READY"
System.Threading.Thread.Sleep(2000)
lblTextHere.Text = "SET"
System.Threading.Thread.Sleep(2000)
lblTextHere.Text = "FIRST PLAYER'S TURN"
Timer1.Start()
End Sub
sometimes i wonder why this thing can't work.
it works just the last text. 
|
|
|
|
|
No, not a threading problem. The problem is all of this code runs on the UI thread. The UI thread also handles the apps message pump, where Windows send messsages to your application, like Paint messages.
So, you set the label text to "READY", then you put the UI thread to sleep, so it can't possibly get and handle the Paint message (your code gets this as a Paint event) and your label never gets painted. The thread wakes up and the next line of code sets the label text to "SET" and then goes to sleep again. You get the idea.
Meanwhile, all these paint messages are piling up in the message queue, waiting for your UI thread to get around to picking them up, which it won't do until your Click handler code finishes and returns. Once that happens, the UI thread gets to the messages and process them all. All the Paint messages are processed and you see the final result, the label text changing to "FIRST PLAYER'S TURN".
Oddly enough, the solution is a threading problem.
In order to keep the UI thread from stalling, you have to move your Sleeps to another thread and ship the setting of the Label Text property back to the UI thread, called Invoke. You can read up more on the technique
here[^].
modified 5-Mar-12 22:11pm.
|
|
|
|
|
Your code won't do what you want for the reason Dave explained.
As the delays are there to get some pause in between changes to the user interface, the better approach is to use a "state machine" and a timer, and more particularly a System.Windows.Forms.Timer which will fire its Tick event periodically; the state machine evolves form state 0, to state 1, then state 2, etc until it is done, so you'll need at least one state variable to know how far your state machine has progressed. This may be simpler than adding another thread, as extra threads are easy for scheduling stuff, but not so for accessing Controls.
|
|
|
|
|
Wow. The Vicodin I'm on is really messing with me! This never crossed my mind.
|
|
|
|
|
There is always a dilemma between coding some asynchronous operations, and adding an extra thread. Asynchronous may be cheaper (no stack, it gets borrowed from the threadpool), an explicit thread may be simpler to code (no explicit state machine required, the program counter works like a state variable). Therefore, whenever you think of the one solution, you should also consider the alternative; however for GUI stuff, the timer most often will win.
BTW: you shouldn't be taking drugs while coding, it may be dangerous to the health of your code.
|
|
|
|
|
Luc,
we might just let this one slip... After all, Dave did say he was coding in VI
|
|
|
|
|
HEY! VI looks like Word when comered to EDLIN! Now that's a REAL mans IDE!
|
|
|
|
|
Luc Pattyn wrote: BTW: you shouldn't be taking drugs while coding, it may be dangerous to the
health of your code.
Well, there's the beuty of it! Because around here, it's not MY code that's in danger! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
