Update control(s) on Form1 in a module that uses threads.

Hi I am using a module for a bunch of subs and functions that will perform things related to a certain textbox and combobox e.g. loading/saving data into them. I am using threads for those methods to keep things running nice and smooth. I noticed that I cannot update the textbox/combobox from my module using Form1.TextBox/Form1.ComboBox.

That in mind, I pass the TextBox/ComboBox as a parameter into a public procedure that then passes the control(s) to the thread and that in turn passes the controls as parameters to a sub that I invoke to be able to update those controls on the Form1 thread.

This works fine, but I wonder if there is a better way of doing this? It seems to me that I am creating 3 copies of the control(s) references in order to be able to update them. Not only that but I have to combine them in an object array and fish them back out in order to pass them to my thread.

I thought about making a class with a TextBox/ComboBox property and using that either as the parameter of the procedures or as a property of the module. Am I going about this the wrong way?

Thanks
Jay

The reason that you can't use the default instance that you first suggested is that default instances are thread-specific. Because you're on a different thread to the one that created your original form, it will create a new default instance, so the code will succeed but it will not be affecting the form you're looking at. In cases like this, you should use the SynchronizationContext class. Follow the CodeBank link in my signature and check out my thread on Accessing Controls From Worker Threads. Later in that thread you'll find an example that uses a SynchronizationContext.

That's brilliant thank you so much.

While I was looking through other forums and articles, the general opinion seemed to favour using classes with shared members opposed to modules when interacting with the form thread. I can see why it might be favourable without using the SynchronizationContext but I wondered about others opinions as to what they consider best practice?

Thanks
Jay

I would use instance members and methods, writing code that was as thread-agnostic as possible, and concentrate all the code that dealt with threading in as small an area as possible.
This would mean any calculations that you wanted to run in a background thread would need to be in its own method that doesn't reference the UI controls in any way (i.e. needs to pass data in as arguments, not pull the data from controls) and returned the calculated data. Another method would be written that updates the UI based on the calculated value that was, again, passed in as an argument. These two methods would be passed to an object that dealt with the thread synchronisation and ensuring things were run on the correct threads (and do so by relying on various threading libraries, probably TPL these days). This object would be decoupled from the application logic through an interface.

However, the reason I would do all this is because I work on large systems that would quickly be swamped with the sort of boilerplate code that goes along with thread synchronisation, needs a high degree of separation and decoupling to improve maintainability and enable unit testing. I suspect you can very easily get away with something like a BackgroundWorker that provides an easy to use abstraction that is fairly robust (assuming you use it correctly).

One point is that a module IS a class with all Shared members. The module is left in to be more familiar to VB6 users migrating to .NET, and there is one little gift added where you don't need to use the module name to refer to the method whereas you would if you used a class with shared members. However, that's just something the compiler does to make a module act in a VB6 fashion. Behind the scenes, it is still just a class with all Shared members.

Another point is that from your description, I don't see any reason to have the module at all. If those methods will work with multiple forms then it would make sense, but you make it sound like they work ONLY with the controls on one particular form. If that is the case, then those methods should be members of that form and not out in a module.