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*********@top scene.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*********@to pscene.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*********@to pscene.comwrote in message
news:dc******** *************** ***********@y38 g2000hsy.google groups.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*********@to pscene.comwrote in message
news:dc******** *************** ***********@y38 g2000hsy.google groups.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*******@hotm ail.comwrote:

<jo*********@to pscene.comwrote in message
news:dc******** *************** ***********@y38 g2000hsy.google groups.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*********@top scene.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(o bject sender, TabControlCance lEventArgs 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(o bject sender, TabControlCance lEventArgs 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.c omwrote:

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" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Mon, 28 Apr 2008 21:22:57 -0700, mgsram <mgs...@gmail.c omwrote:

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?