[dba-VB] Background worker threads

John,

Sorry, I'm jumping in your dispute with Charlotte - just wanted to note that
the fact that "The basic code WAS working before I carved it out into a
worker." doesn't mean that the same code (copied & pasted) into
multi-threading environment will work OK - very often the opposite will be
the truth - it could produce (very) faulty solution in multi-threaded
environment, which will not be easy to sort out into properly running
multi-threaded code...

I'd dare to advise you to prepare and test your code in VS console
application (or .net console app as test-bed app and .net classlib(s)
keeping all your non-UI code), and when that will work OK then add some more
code to run your classlibs with your .NET WinForms application: you have a
lot to do, to learn and to test - multi-threading and .NET programming can't
be "captured by attack" - it's a painful and lengthy natural process, which
usually takes a lot of time - I know that from my own experience and
experience of others - and better not "read all that books" - find just one
but good and then experiment a lot on your own - then you'll get it working
properly and you'll teach all of us here - I'm quite sure about that latter!


Thank you.

--
Shamil


-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, April 30, 2008 8:05 PM
To: Discussion concerning Visual Basic and related programming issues.
Subject: Re: [dba-VB] Background worker threads

Charlotte,

Could you be a little more verbose?

I have spent about 6 hours now Googling and reading EXACTLY the same 
(though written by different authors) code "the button starts the 
thread, the thread increments the number, the thread raises its event 
and passes a "percent done" to the form where it is used to update a 
progress bar".

Give me a break!

To be honest I am astonished that FORTY different people thought that it 
was necessary to publish identical content articles.  None of which 
answers either of my questions.

I have a class.

The class has TWO BackgroundWorker objects defined Withevents.

bgwParseData is running a function that creates a class to load data 
from a SQL server, and once loaded, parse that data.  The basic code WAS 
working before I carved it out into a worker.

bgwUpdateData is running a method of a class that updates data back to 
SQL Server.  The basic code WAS working before I carved it out into a 
worker.

So... a single data class, two methods, one reads / parses the data in 
an ADO DataTable, the second writes the datatable back to SQL Server.

Two threads, bgwParseData generates the data class and calls the 
read/Parse method, then stores the class in a collection.  bgwUpdateData 
watches the collection, pulls the class out and calls the update method.

Or that is the theory.  I have asked whether it is legal for one 
background worker to write to a collection while a second background 
worker reads that collection.  No answer so far.

The second issue is how can bgwParseData update THREE different text 
boxes on the main form.  All of the examples show a cute "progress bar". 
  I don't want a progress bar, I want THREE text boxes to display data 
from the process running in the background worker.

I know that I can create events and raise them, and I DID THAT before I 
started converting to backgroundworkers.  That was easy.  HOWEVER the 
way I read it I can't raise those same events from the BackgroundWorker 
thread because the event sink updates a physical control on the form, 
and that is a no-no from a thread.

Unfortunately, as always happens with the books, they don't discuss 
anything more complicated than incrementing a number and passing that 
number back to a progress bar on the form.  I have seen that (almost) 
identical code in probably FORTY different articles on using the 
backgroundworker.  All saying EXACTLY the same, useless (to me) thing.

Sigh.

John W. Colby
www.ColbyConsulting.com


Charlotte Foust wrote:
> You can create your own events with whatever parameters you want and
> raise those.  Just Dim Public Event Whatever(parameter)  Then raise it
> as needed.
> 
> Charlotte Foust 
_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com