So if i have a main class in a windows form applciation (say running the GUI).

I created another class that does a long process in the background, and needs to update the GUI when its done. (The class does a bunch of things, and uses backgroudn workers).

Right now im waitning for the work complete to finish then writing the results directly to the text display on the GUI.

There seems to be a better way to do this, perhaps poll the sub class? I guess my major concern is how do i monitor the progress of a background worker in another class without bogging the interface?

5/15/2013 5:42:01 PM

if I'm reading correctly why not just pass a pointer to the parent to the child, this may be done already. If thats the case the child frame can periodically call an "Update" function of the parent frame or use other functions to update the parent.

Am I missing something here?

5/15/2013 6:23:41 PM

PRobably not asking properly, because i'm at least in my mind building my first big application...

Most of the stuff i do is sequential scriping, and I havent had to deal with threading, and have made minimal uses of classes in the past.

Ill give you an example.

I want to copy files to a computer, so i run my copy file class, now I dont konw when it finished but when it does I want it to let the calling class know.

I guess i've kinda got it figured out but its uglier than I want.

5/15/2013 7:52:17 PM

So you have a view that needs to be periodically updated based on a long-running background task? I don't have any real experience with Windows forms, but generally speaking either strategy is workable (having the view check the background task or vice-versa).

If I were coding this in the framework of my choosing, I would do the following:
1. If the background task has discrete milestones, I would update the view from the task upon the completion of each milestone.
2. If the background task's progress is continuous, I would check the progress of the task and update the view periodically.

The caveat from both of those being, of course, if there is not an implementation specific reason to do otherwise.

5/15/2013 8:53:56 PM

In your background worker, "do work" function, you need to call the BackgroundWorker.ReportProgress function to report progress back to the calling object.

That object will need to have an event handler for the BackgroundWorker.ProgressChanged event, in the handler you would update your UI.


[Edited on May 16, 2013 at 9:20 AM. Reason : .]

5/16/2013 9:19:23 AM

if you're using wpf (you're writing a gui app in windows, you should be using wpf) then you have your xaml, your viewmodel bound to the xaml, and whatever the running bit of code is (could be the codebehind for the xaml, could be somewhere else). when your long running process exists and returns its results, the result handler should update the relevant fields in the viewmodel. at that point the binding will automatically update the ui. this way all updates to the gui are mediated through the view model. it makes it very easy to deal with multiple update sources.

5/16/2013 10:11:32 AM

This isn't an "object oriented programming question" this is a "GUI and threading question".

5/16/2013 10:47:26 AM

Quote :

"you're writing a gui app in windows, you should be using wpf"

RAW WIN32 4LYFE

5/16/2013 10:54:31 AM

Also, this isn't going to make any sense to you at first, but you won't be able to update the GUI from the worker thread, whether it's WPF or WinForms. However you try to update the GUI, you're gonna have to do it from it the GUI thread or marshal it to the GUI thread. For WinForms, look up the usage of Control.InvokeRequired. For WPF, it's a little different, but the same concept; use Control.Dispatcher

If you don't do this, you'll get a cross-thread exception. If you're going to be doing a lot of multi-threaded GUI work in .NET (i.e. if you don't want to suck), then you better learn this concept and learn it well.

5/17/2013 11:33:45 PM