How difficult to switch from DoEvents to Threading?
-
This question is a new post prompted by my other thread, "The old DoEvents and UserControls". I created a separate thread here, since it is branching off from the old discussion. In the other thread, it was looking like converting code from supporting DoEvents, to supporting threading might be a big rewrite. But now I am not so sure. I downloaded an example Pause/Resume Thread program from online and that program had a separate class that was threaded. It then communicated to the main form via a delegate. But I wanted to find out if it was possible to do threading of a procedure that was NOT in a separate class...But one residing in the main form's class, like any other sub. The reason this was important to me, was to cut down on the amount of code rewriting by keeping my existing code in place, and merely adding on additional code to thread one of those main form procedures. My revision to that original threading example seems to say, "yes", to that question. Here is my version of that little demo. It simply runs a counter that counts from 1 to whatever, and when the thread is suspended, the counter halts, until resumed. Since I am new to threading, is there anything wrong with this idea that could end up biting me in the rear? Here is the code:
Imports System.Threading
Imports SystemPublic Class Form1
'Form1 controls:
'Button1: Starts/Resumes thread execution.
'Button2: Suspends thread execution.
'txtResults: Textbox for count results.
'Quit_cmd: End program.'Define a delegate type for the form's DisplayValue method:
Private Delegate Sub DisplayValueDelegateType(ByVal txt _
As String)'Declare a delegate variable to point to the form's
'DisplayValue method:
Private m_DisplayValueDelegate As DisplayValueDelegateTypePrivate m_Thread As Thread
'This value is incremented by the thread:
Public Value As Integer = 0'Add the text to the results. The form provides this
'service because the thread cannot access the form's
'controls directly:
Public Sub DisplayValue(ByVal txt As String)
txtResults.Text = txt
'txtResults.Select(txtResults.Text.Length - 1, 0)End Sub
Private Sub Form1_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles MyBase.Load
'Make a new counter object:
Dim new_counter As New Counter(Me, my_number:=1)
'...is the same as:
' -
This question is a new post prompted by my other thread, "The old DoEvents and UserControls". I created a separate thread here, since it is branching off from the old discussion. In the other thread, it was looking like converting code from supporting DoEvents, to supporting threading might be a big rewrite. But now I am not so sure. I downloaded an example Pause/Resume Thread program from online and that program had a separate class that was threaded. It then communicated to the main form via a delegate. But I wanted to find out if it was possible to do threading of a procedure that was NOT in a separate class...But one residing in the main form's class, like any other sub. The reason this was important to me, was to cut down on the amount of code rewriting by keeping my existing code in place, and merely adding on additional code to thread one of those main form procedures. My revision to that original threading example seems to say, "yes", to that question. Here is my version of that little demo. It simply runs a counter that counts from 1 to whatever, and when the thread is suspended, the counter halts, until resumed. Since I am new to threading, is there anything wrong with this idea that could end up biting me in the rear? Here is the code:
Imports System.Threading
Imports SystemPublic Class Form1
'Form1 controls:
'Button1: Starts/Resumes thread execution.
'Button2: Suspends thread execution.
'txtResults: Textbox for count results.
'Quit_cmd: End program.'Define a delegate type for the form's DisplayValue method:
Private Delegate Sub DisplayValueDelegateType(ByVal txt _
As String)'Declare a delegate variable to point to the form's
'DisplayValue method:
Private m_DisplayValueDelegate As DisplayValueDelegateTypePrivate m_Thread As Thread
'This value is incremented by the thread:
Public Value As Integer = 0'Add the text to the results. The form provides this
'service because the thread cannot access the form's
'controls directly:
Public Sub DisplayValue(ByVal txt As String)
txtResults.Text = txt
'txtResults.Select(txtResults.Text.Length - 1, 0)End Sub
Private Sub Form1_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles MyBase.Load
'Make a new counter object:
Dim new_counter As New Counter(Me, my_number:=1)
'...is the same as:
'treddie wrote:
I wanted to find out if it was possible to do threading of a procedure that was NOT in a separate class
No need to test. Yes, you can thread just about any code you want. A form is just a class, like any other.
treddie wrote:
The reason this was important to me, was to cut down on the amount of code rewriting by keeping my existing code in place, and merely adding on additional code to thread one of those main form procedures.
Wrong approach. If your going to go through the trouble of threading the code, scrap what you have and do it write instead of trying to Frankenstein a solution together.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
treddie wrote:
I wanted to find out if it was possible to do threading of a procedure that was NOT in a separate class
No need to test. Yes, you can thread just about any code you want. A form is just a class, like any other.
treddie wrote:
The reason this was important to me, was to cut down on the amount of code rewriting by keeping my existing code in place, and merely adding on additional code to thread one of those main form procedures.
Wrong approach. If your going to go through the trouble of threading the code, scrap what you have and do it write instead of trying to Frankenstein a solution together.
A guide to posting questions on CodeProject[^]
Dave KreskowiakBut the example program I showed does basically what I'm suggesting. So it doesn't SEEM like a kludge. Especially since all I basically have is one procedure that I need to thread, and everything else is called from it sequentially. So from a performance point of view, it all has to work sequentially anyway, so my only benefit from threading is to have the ability to pause execution at will, which was the primary reason to begin with. Is that a reasonable enough reason for doing it that way? I don't see any future versions of this program gaining any other benefits from threading.