Help! Tab Pages and the Tab Control

[joey.powell]

Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

I already have a variable to track the status of this (i.e. "bool
IsBusy"), but I cannot figure out now to "freeze" the tab pages when
"IsBusy" is true. The idea is to freeze them while the processing is
going on and then unfreeze them once it has completed.

So far I have tried setting the "CanSelect" properties for each of the
other tab pages, but they are read-only. Also, each tab page does not
appear to have an "Enabled" property like most other controls. That
would make things a lot easier.

Gusy, how can I get this to work?

[Joe Cool]

On Mon, 28 Apr 2008 14:31:09 -0700 (PDT), jo*********@topscene.com
wrote:

>Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

I already have a variable to track the status of this (i.e. "bool
IsBusy"), but I cannot figure out now to "freeze" the tab pages when
"IsBusy" is true. The idea is to freeze them while the processing is
going on and then unfreeze them once it has completed.

So far I have tried setting the "CanSelect" properties for each of the
other tab pages, but they are read-only. Also, each tab page does not
appear to have an "Enabled" property like most other controls. That
would make things a lot easier.

Gusy, how can I get this to work?

There are several events that get fired when you click on another tab.
You may be able to accomplish your task by checking you status
variable in one of these. I would suggest the Validating event. You
will also need a variable that points to the current tab, so you know
where to go back to if needed.

[Peter Duniho]

On Mon, 28 Apr 2008 14:31:09 -0700, <jo*********@topscene.comwrote:

[...]
So far I have tried setting the "CanSelect" properties for each of the
other tab pages, but they are read-only. Also, each tab page does not
appear to have an "Enabled" property like most other controls. That
would make things a lot easier.

You can disable the entire TabControl.

I think that would be the most user-friendly approach. There are other
hacks you might try, but I think they would be less user-friendly as well
as significantly more difficult (depending on how TabControl is
implemented, it could even involve the need to override the WndProc()
method and handling window messages directly...yuck!)

By the way, just a minor suggestion: there's no need to write the word
"Help!" in your subject. I think we can all take it as granted that if
you're asking a question here, you're requesting help. :)

Pete

[Richard Carpenter]

<jo*********@topscene.comwrote in message
news:dc**********************************@y38g2000 hsy.googlegroups.com...

Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

Is there a reason you're using worker threads? If the processing occurred in
the same thread as the calling function, wouldn't that take care of the
problem? If you're firing off *multiple* processes, that would explain it.
In that case, perhaps a check on the process status in a while loop?

--
Richard Carpenter

[Richard Carpenter]

<jo*********@topscene.comwrote in message
news:dc**********************************@y38g2000 hsy.googlegroups.com...

Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

Is there a reason you're using worker threads? If the processing occurred in
the same thread as the calling function, wouldn't that take care of the
problem? If you're firing off *multiple* processes, that would explain it.
In that case, perhaps a check on the process status in a while loop?

--
Richard Carpenter

[Peter Duniho]

On Mon, 28 Apr 2008 17:43:59 -0700, Richard Carpenter
<ru*******@hotmail.comwrote:

<jo*********@topscene.comwrote in message
news:dc**********************************@y38g2000 hsy.googlegroups.com...

>Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

Is there a reason you're using worker threads? If the processing
occurred in
the same thread as the calling function, wouldn't that take care of the
problem?

If nothing else, using a worker thread for a lengthy operation ensures
correct visual behavior from the user interface, by avoiding the blockage
of the UI thread's message pump.

This would be important even if the UI wasn't updated during the operation
-- for example, if the window is dragged or obscured in a way that
requires it to be redrawn -- but it's obviously even more so if the
lengthy operation is updating some sort of progress indicator in the UI.

IMHO, my previous suggestion to disable the TabControl is probably going
to work for the OP (since he already looked at disabling the tab to
prevent switching to another tab, and that's effectively what disabling
the control will do). But if not, an alternative would probably be to put
up a modal dialog box while the operation is proceeding.

Blocking the UI thread while the operation proceeds is a poor solution.

Pete

[John B]

jo*********@topscene.com wrote:

Hello,

I have an app that uses a tab control with several tab pages.
Sometimes some of the processing initiated on one of the tab pages
gets busy doing stuff that is farmed out to worker threads. I have to
be able to prevent the tab page from changing (prevent users selecting
other tabs) while this is going on.

I already have a variable to track the status of this (i.e. "bool
IsBusy"), but I cannot figure out now to "freeze" the tab pages when
"IsBusy" is true. The idea is to freeze them while the processing is
going on and then unfreeze them once it has completed.

So far I have tried setting the "CanSelect" properties for each of the
other tab pages, but they are read-only. Also, each tab page does not
appear to have an "Enabled" property like most other controls. That
would make things a lot easier.

Gusy, how can I get this to work?

Handle the Selecting event and set e.Cancel to IsBusy

ie
void tab_Selecting(object sender, TabControlCancelEventArgs e)
{
e.Cancel = IsBusy;
}

JB

[Peter Duniho]

On Mon, 28 Apr 2008 18:09:52 -0700, John B <jb******@yahoo.comwrote:

Handle the Selecting event and set e.Cancel to IsBusy

ie
void tab_Selecting(object sender, TabControlCancelEventArgs e)
{
e.Cancel = IsBusy;
}

Note that if you use this approach, be sure to provide the user with some
feedback as to _why_ you've canceled the tab change. For example,
displaying an alert.

That's one advantage of simply disabling the control: it becomes
immediately apparent to the user that the control isn't going to accept
user input. Other alternatives are viable though, as long as the user is
always presented with clear information about why they aren't able to
change tabs in the control.

Pete

[Peter Duniho]

On Mon, 28 Apr 2008 21:22:57 -0700, mgsram <mg****@gmail.comwrote:

Disabling the tab control OR canceling the tab change _alone_ can lead
to confusion to the user due to inactivity, especially if the wait
time is longer.

Disabling the control is not mutually exclusive with providing progress
feedback. I agree that progress feedback is desirable _as well_, and
never intended anyone to take my suggestion to mean otherwise. I'm sorry
if I didn't make that clear enough.

Ignoring the issue of progress feedback though, disabling the control
provides the user with a clear indication that the UI will not respond at
the moment. That's a lot different from a control that looks ready to
respond but ignores your input without any feedback at all.

Pete

[joey.powell]

On Apr 29, 2:57*am, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 28 Apr 2008 21:22:57 -0700, mgsram <[e-mail]:

Disabling the tab control OR canceling the tab change _alone_ can lead
to confusion to the user due to inactivity, especially if the wait
time is longer.

Disabling the control is not mutually exclusive with providing progress *
feedback. *I agree that progress feedback is desirable _as well_, and *
never intended anyone to take my suggestion to mean otherwise. *I'm sorry *
if I didn't make that clear enough.

Ignoring the issue of progress feedback though, disabling the control *
provides the user with a clear indication that the UI will not respond at *
the moment. *That's a lot different from a control that looks ready to *
respond but ignores your input without any feedback at all.

Pete

We are already using a progress bar and status text to provide visual
feedback. And this is another reason why we are using worker threads -
we would see "white out," and it would get really ugly otherwise.

As for disabling the entire tab control, well that is not an option.
This is because the associated progress bar, status text, and a cancel
button are containted within it.

I agree with John B, wow a Selecting event with an EventArg e with a
cancel option would be a great solution. And that's what I went
looking for first. Unfortunately these options do not exist with the
tab control (at least not in .net 3.5)!

And Peter, I understand about the "Help in the subject" thing. You're
right.

Any other suggestions?

[joey.powell]

On Apr 29, 8:12*am, [e-mail] wrote:

On Apr 29, 2:57*am, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 28 Apr 2008 21:22:57 -0700, mgsram <[e-mail]:

Disabling the tab control OR canceling the tab change _alone_ can lead
to confusion to the user due to inactivity, especially if the wait
time is longer.

Disabling the control is not mutually exclusive with providing progress *
feedback. *I agree that progress feedback is desirable _as well_, and *
never intended anyone to take my suggestion to mean otherwise. *I'm sorry *
if I didn't make that clear enough.

Ignoring the issue of progress feedback though, disabling the control *
provides the user with a clear indication that the UI will not respond at *
the moment. *That's a lot different from a control that looks ready to*
respond but ignores your input without any feedback at all.

Pete

We are already using a progress bar and status text to provide visual
feedback. And this is another reason why we are using worker threads -
we would see "white out," and it would get really ugly otherwise.

As for disabling the entire tab control, well that is not an option.
This is because the associated progress bar, status text, and a cancel
button are containted within it.

I agree with John B, wow a Selecting event with an EventArg e with a
cancel option would be a great solution. And that's what I went
looking for first. Unfortunately these options do not exist with the
tab control (at least not in .net 3.5)!

And Peter, I understand about the "Help in the subject" thing. You're
right.

Any other suggestions?- Hide quoted text -

- Show quoted text -

OK OK not sure what was going on earlier, but I found a "Selecting"
event. I'm checking into that now...

[Ignacio Machin ( .NET/ C# MVP )]

On Apr 28, 9:20*pm, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 28 Apr 2008 18:09:52 -0700, John B <[e-mail]:

Handle the Selecting event and set e.Cancel to IsBusy

ie
void tab_Selecting(object sender, TabControlCancelEventArgs e)
{
* *e.Cancel = IsBusy;
}

Note that if you use this approach, be sure to provide the user with some *
feedback as to _why_ you've canceled the tab change. *For example, *
displaying an alert.

That's one advantage of simply disabling the control: it becomes *
immediately apparent to the user that the control isn't going to accept *
user input. *Other alternatives are viable though, as long as the user is *
always presented with clear information about why they aren't able to *
change tabs in the control.

Pete

Hi,

I think that the best solution is your proposed modal dialog

[Peter Duniho]

On Tue, 29 Apr 2008 06:12:28 -0700, <jo*********@topscene.comwrote:

We are already using a progress bar and status text to provide visual
feedback. And this is another reason why we are using worker threads -
we would see "white out," and it would get really ugly otherwise.

Agreed.

As for disabling the entire tab control, well that is not an option.

Why not? Your first post implied that disabling an individual tab page
would have been okay, and that would have had the exact same effect, had
it worked.

This is because the associated progress bar, status text, and a cancel
button are containted within it.

Personally, I don't see why those things would be in the tab page if you
want to basically disable the entire tab control while the processing is
going on. However, if you insist, then I suppose that's an issue (at
least for the Cancel button...the other stuff can stand to be disabled
while still providing feedback).

Still, IMHO you should disable all of the tab page contents except those
items, to provide the user with useful feedback (at least, if there are
editable controls that shouldn't be modified during the operation, which
seems implied by your description). IMHO, better would be to put the
status UI somewhere else. Either in the same form, but outside the tab
control, or -- even better -- in a modal dialog.

It's hard to know for sure what's the right thing without knowing more
about the rest of your UI design. But you seem to have a user-modal
sitaution here in which nothing else should be touched while the
processing is going on.

Pete