Responsive GUI: design question

Hello all! :wave:

I'm trying to make my program more user friendly and the first thing that came into my mind was making the GUI fully responsive. I have a lot of methods that involve looping and other time consuming tasks. I created a window to show a message to user, like "Doing some task, please wait...". The window then calls a method on a separate thread, to stay responsive. Now the question is:

I have some methods that I would like to report their progress. Like, for example, an auto-update method - I would like it to be able to show messages like "Checking for updates" then change to "Updating..." and finally "Update successful!".

I do already have a method SetText() implemented for the information window, but I can't think of the best way to use it. I want the methods I call in another thread to NOT contain any GUI related code, so I don't want to pass the information window object to the methods. Note, I do know about invoking and I already solved all GUI and MT related problems ;)

Please share your thoughts about this issue, maybe there's some effective way you're all using?

I appreciate, as always, any comments of the gurus :)

Hi !
In my applications for very long cycles e.g long dataloading I'm using progressbar. In short cases I'm using text in the statusbar, when ready this again shows 'ready' then. I'm having all the texts for everything in the resources files because there it aslo can be localized if necessary and using only short strings to access this strings like ERR_OPEN, WAIT_LOAD,
... Errormessages are posted in MessageBoxes, Wait messages are in the statusbar.

I dont know if this helps you, but so do I. :D ;)

Thanks, JonnyPoet, for input, but this doesn't solve my problem... :(

My problem is how to have the lengthy methods report their progress without using any calls to GUI from the code. The biggest problem is that I need the progress to be reported several times, not only one, so I can't just set the waiting message in GUI level. I was thinking about a delegate as one of the arguments to all these methods, something like:

Code:

---

public delegate void ProgressCallback(string text);

---

From the GUI code I would pass the SetText(string text) method as the argument then.

Is this a good enough way to do this?..

Thanks.

Check out the 'Model View Presenter' and 'Model View Controller' design patterns.

I found the 'Design Patterns Bootcamp: Model View * Patterns' to be helpful.

Check out the videos in the article as well as the MVP code stub generator.

The idea here is that an interface is used to connect the view to a presenter. The interface can contain events, methods, properties etc (eh, the usual stuff). In your case, your form class would be derived from Form and this interface and you would connect up the interface items with the form controls.

The presenter class typically call other class(es) that implement the multithreading or other service operations.

Have a look at this:

MSDN Magazine - Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads

It explains how to update form controls from inside a thread.

Quote:

---

Originally Posted by gecka

....My problem is how to have the lengthy methods report their progress without using any calls to GUI from the code. The biggest problem is that I need the progress to be reported several times, not only one,....

---

Yes but isn't this just the same way as if you are feeding a progressbar with information that the progressincreases and it has to show a new state of progress now. During loading I do this several times and in different amounts using a callback delegate from the GUI. The GUI would report in any way I want, so I also could show different messages instead of using a progressbar. (I'm working with a backgroundworker this way.) So in the moment I cannot see the problem ? Is it how to transport data or hw to build the calllback ?

Hmm, I'll probably go with delegates in this program then, like JonnyPoet said.
But the link Arjay gave is very useful too, thanks for it.

As the program is getting bigger and bigger, I'm starting to feel the need of clear design from the beginning of the project... Gonna have to rewrite some code now. :\

Thanks for all replies. :)

Quote:

---

Originally Posted by gecka

...As the program is getting bigger and bigger, I'm starting to feel the need of clear design from the beginning of the project...

---

I think everybody of us, who ever did bigger projects, knows that feeling ;) I'm just on rerwriting an old Access.mdb VBA application to an C# MS-SQLServer - Client Application and I'm in the design matter since one year now, doing some small testings and the most work is only going into how to design the new database for a better and easier handling of the given needs in some very complex data relations.

Just use a BackgroundWorker component. You call its RunWorkerAsync method and you do the work in its DoWork event handler. You call its ReportProgress method and update the UI in its ProgressChanged event handler. The whole point of the BackgroundWorker is to simplify multi-threading by removing the need for you to worry about what thread you're on. You don't have to create a background thread and you don't have to use any delegation to access the UI. All that happens but it happens behind the BackgroundWorker so you don't have to worry about the details. It's not suitable for all multi-threading scenarios but for most it will make your life easier.