views:

619

answers:

4

I've inherited a Winforms application that does a lot of long running calls into the application server from the UI thread, so the UI stays unresponsive, unusable, unclosable for quite some time. (Which makes me really go AAAAAAAAARGH!)

I plan to move the server calls to a background thread and have the UI disabled - but movable & closable - while the background thread does its work.

So what would be the best way to inhibit user input to my application? I'm thinking along the lines of "modal progress dialog", but I'd prefer a solution that does not force me to throw visuals into the face of the user (some server operations run within less than 500ms so a dialog is not optimal ...)

Is there any way in Winforms to prevent the user from launching actions or changing data in the application while letting through a few select things (resize, show, hide and family and the user closing the window)? I'd prefer a way that does not make me access every UI element in my forms and set it to disabled ... there are quite a lot of them and that application really has a "hacked in the UI designer until it shows flashy things" style of source code. No way of refactoring EVERY smelly thing until release date ...

Oh, by the way, this App lives in .net framework 2

+1  A: 

The only way I know of is to get some/all controls as disabled. However, depending on how the controls are laid out, it isn't necessary to set every control as disabled - when a container control is disabled, then all of its children are disabled, too. For example, if you have a GroupBox with some controls, if you set the GroupBox to disabled, then all of the controls within the GroupBox will be disabled, too.

Andy
+1  A: 

Choose some upper level container control (might be the form itself), and set it's Enabled property to false. All controls placed on that control will be disabled, which will prevent them from receiving input.

driis
A: 

Unfortunately, with WinForms, you'll probably need to disable/enable the buttons in a single shared method. This is one of the advantages WPF brings over windows forms - it's much easier to handle these situations.

As for not blocking your UI - you'll need to move your calls to an asynchronous programming model. In your case, I'd recommend taking a look at the ThreadPool.

You'll want to do something like have the button disable your controls, call out your operation on the thread pool, then reenable them on completion.

Reed Copsey
A: 

On the Win32 API level, there's a EnableWindow function you can disable any window hand with (you need to get the underlying handle of your main window, of course, and of any other top level windows). I haven't tested it in WinForms, though. (I'm pretty sure there are other answers on the User32 level, but I can't remember the API calls right now.)

Note: this doesn't grey out controls, which decreases its utility from a usability point of view (the user just sees a 'frozen application'). It gets marginally better if you at least set an hourglass cursor.

However, this is a quick-and-dirty way of dealing with asynchronous processing. Do you really need to lock the user out of your entire application? Perhaps it's just a few functions that should be banned while a request is underway?

Pontus Gagge