Open Form: Multi-Threading

[Tom Newman]

I'm currently developing a management application for a client. As the application retrieves data from a remote database, I aim to use multi-threading to allow the best functionality.

I would appreciate any advice on the following scenario. I need to open a form which contains a ComboBox which is populated with data from the database. I would ideally like the ComboBox to to be populated within a different thread; it would be preferable if the form could be hidden until this population is completed.

My main issue lies with transferring data inbetween threads. At the current time, I reference a class function which gets the data for the ComboBox in the form of a DataTable. The ComboBox data source is set to the DataTable which leads to its population. My attempts so far have resulted in cross-thread violations, as I try to set the ComboBox data source from a different thread. I have tried to have a look at information on delegates, however none of the tutorials seem to fit my context.

This is my first attempt at multi-threading, and would appreciate any help anyone can provide to ease the attempt.

Kindest Regards
Tom Newman

 

[JohnH]

Try the BackGroundWorker component, it saves you doing the delegate invocation threading yourself (not that its difficult, you just have read multithreadin tutorial ). BackGroundWorker is simple, saves time and coding and usable for many things. Add one from Toolbox, use the asynchronous DoWork event to do the lift, you can pass the load through e.Result or assign it some class fields, then in Completed event which is UI safe you can set data for the UI controls.

 

[Tom Newman]

John

Thanks for the quick reply.

I have looked at the background worker component, but did not feel it was necesary to use it: this isn't the only form I have to open like this, there's several of them. Surely this would mean declaring a background worker for every form I wanted to open?


Thanks
Tom

 

[JohnH]

I don't see the difference between using a Thread and a BackGroundWorker in this regard. Surely you wouldn't need to create any more BackGroundWorkers than Threads?

 

[Tom Newman]

Sure, my only concern was that whilst the Threads are created dynamically when the code is run, the Background Workers would exist throughout the time the MDI window is open. If this only has a negligible effect on the application, I would be quite happy to use the Background Worker tool.

 

[JohnH]

That depends on how you declare it. Like Thread class and other classes the BGW class may be declared at different places and with different scope. Dim b as new button, Dim t as new thread, Dim bgw as new backgroundworker... you see?

 

[Tom Newman]

John

Thanks once again for the reply.

I understand that you could Declare a New background worker from within the code, but then how would you write the event code to fire when the background worker is asynchronously started?


Thanks

 

[JuggaloBrotha]

John

Thanks once again for the reply.

I understand that you could Declare a New background worker from within the code, but then how would you write the event code to fire when the background worker is asynchronously started?

Thanks

When you declare it in code, use the 'WithEvents' keyword. Now you can select the control from the left dropdown in the IDE and the events for it will show in the right hand drop down in the IDE

 

[Tom Newman]

Thanks for clearing this up.
This problem is now resolved.

Tom