Home > Archive > Visual Basic Syntax > March 2005 > Custom progress alert: Disabling main form
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Custom progress alert: Disabling main form
|
|
|
| I've created a custom progress alert box for long processes to amuse
the user - they seem fascinated with shiny things that move... ;o)
The thing is, I would also like to disable all the controls on the
main form. Of course, I can't make the custom alert box form modal
because that would stop all the processing in the background.
So, I'm wondering what's the canonical way around this?
I can think of several semi-solutions e.g., implement a flag check in
every control (messy), or put a transparent control over the whole
main form to prevent any clicks getting through (better, but still
messy), etc... Any other "cleaner" ideas?
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Michael D. Ober 2005-03-23, 8:59 pm |
| Lock the form.
Mike Ober.
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:ngl34112thjjk96cq7rlt9l4j3f5j9p340@
4ax.com...
> I've created a custom progress alert box for long processes to amuse
> the user - they seem fascinated with shiny things that move... ;o)
>
> The thing is, I would also like to disable all the controls on the
> main form. Of course, I can't make the custom alert box form modal
> because that would stop all the processing in the background.
>
> So, I'm wondering what's the canonical way around this?
>
> I can think of several semi-solutions e.g., implement a flag check in
> every control (messy), or put a transparent control over the whole
> main form to prevent any clicks getting through (better, but still
> messy), etc... Any other "cleaner" ideas?
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Jeff Johnson [MVP: VB] 2005-03-23, 8:59 pm |
|
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:ngl34112thjjk96cq7rlt9l4j3f5j9p340@
4ax.com...
> I've created a custom progress alert box for long processes to amuse
> the user - they seem fascinated with shiny things that move... ;o)
>
> The thing is, I would also like to disable all the controls on the
> main form. Of course, I can't make the custom alert box form modal
> because that would stop all the processing in the background.
>
> So, I'm wondering what's the canonical way around this?
>
> I can think of several semi-solutions e.g., implement a flag check in
> every control (messy), or put a transparent control over the whole
> main form to prevent any clicks getting through (better, but still
> messy), etc... Any other "cleaner" ideas?
I've done this a couple of ways but the most recent couple of times I've
used a method which is quite slick but requires a little more setup.
Basically you open the progress form modally and then the progress form
immediately calls a Public procedure in the main form to initiate the
processing. Let's say frmMain is the caller and frmProg is the shiny thing.
In frmMain you called InitiateLongProcess. A few lines down it say
frmProg.Show vbModal. InitiateLongProcess is now "suspended" pending the
de-modalizing of frmProg. However, frmProg can call RunLongProcess in
frmMain and that procedure WILL execute. You can then update frmProg from
this procedure as it does its work. The benefit of this is that you truly
have a modal situation going on, so if, say, the user clicks on the taskbar
icon for your app frmProg will be activated. If you go the "display a form
modelessly but disable the main form," the scenario I just described will
actually make the main form look as though it's active (it'll get the active
title bar colors) and the progress form will appear inactive.
The extra setup I mentioned involves the fact that you're going to have at
least two different procedures: InitiateLongProcess and RunLongProcess in my
example. If you pass parameters to InitiateLongProcess they won't be
available to RunLongProcess unless you store them in module-level variables
(in which case passing them as parameters is unnecessary) or you pass them
all into frmProg and then have frmProg re-pass them to RunLongProcess. I
don't like that approach and go with either multiple module-level variables
or a single module-level class or UDT with members that correspond to all
the necessary parameters that RunLongProcess will need.
| |
|
|
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:ngl34112thjjk96cq7rlt9l4j3f5j9p340@
4ax.com...
> I've created a custom progress alert box for long processes to amuse
> the user - they seem fascinated with shiny things that move... ;o)
>
> The thing is, I would also like to disable all the controls on the
> main form. Of course, I can't make the custom alert box form modal
> because that would stop all the processing in the background.
>
> So, I'm wondering what's the canonical way around this?
>
> I can think of several semi-solutions e.g., implement a flag check in
> every control (messy), or put a transparent control over the whole
> main form to prevent any clicks getting through (better, but still
> messy), etc... Any other "cleaner" ideas?
>
Uh.....set the main form's Enabled property to False and then when the long
process is done set it back to True? Or am I missing something in what you
wrote, perhaps not understanding the question?
--
Mike
Microsoft MVP Visual Basic
| |
| J French 2005-03-24, 8:59 am |
| On Wed, 23 Mar 2005 21:51:06 +0100, Danny
<NOSPAMFORdaniel_ahorn@yahoo.com> wrote:
>I've created a custom progress alert box for long processes to amuse
>the user - they seem fascinated with shiny things that move... ;o)
They are indeed
- it gives them a sense of security knowing
a) the App is not dead
b) how long they have got to get a coffee
>The thing is, I would also like to disable all the controls on the
>main form. Of course, I can't make the custom alert box form modal
>because that would stop all the processing in the background.
Put the whole lot on a Frame and disable the Frame
>So, I'm wondering what's the canonical way around this?
Personally I now put progress bars on the current form
- using a UserControl
>I can think of several semi-solutions e.g., implement a flag check in
>every control (messy), or put a transparent control over the whole
>main form to prevent any clicks getting through (better, but still
>messy), etc... Any other "cleaner" ideas?
You could make a Progress Bar as a Modal Form
- that Form could Raise an Event in its parent that actually does the
processing
Having said that, you can get a similar effect by disabling all other
Forms except for the 'Not Really Modal Alert Form'
The most generic way of doing that is by remembering all enabled Forms
in a Control Array
Quite a few ways of skinning your cat.
| |
|
| Date: Wed, 23 Mar 2005 17:15:46 -0500
Name: "MikeD" <nobody@nowhere.edu>
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:ngl34112thjjk96cq7rlt9l4j3f5j9p340@
4ax.com...
>
>
>Uh.....set the main form's Enabled property to False and then when the long
>process is done set it back to True? Or am I missing something in what you
>wrote, perhaps not understanding the question?
No, no, you understood perfectly! It was that elementary. Thanks!
Sometimes one just can't see the forest for the trees, as they say!
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| Date: Thu, 24 Mar 2005 08:19:55 +0000 (UTC)
Name: erewhon@nowhere.uk (J French)
>
>They are indeed
>- it gives them a sense of security knowing
>a) the App is not dead
>b) how long they have got to get a coffee
Of course, feedback is essential, I was just being facetious.
Nevertheless, that corollary to Murphy's Law holds:
Nothing is foolproof because fools are so ingenious... ;o)
>
>Personally I now put progress bars on the current form
>- using a UserControl
Do you mean use VB's native Progress Bar? I used to do that but I'm
running out of space on the main form and don't want to fork it into
separate forms yet or use tabs.
Also, native Progress Bar is somewhat limiting (no % display, for
example). By using a custom progress bar I can also provide additional
information, say, color it conditional on the process currently taking
place and so on.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| Date: Wed, 23 Mar 2005 16:44:09 -0500
Name: "Jeff Johnson [MVP: VB]" <i.get@enough.spam>
>
>I've done this a couple of ways but the most recent couple of times I've
>used a method which is quite slick but requires a little more setup.
>Basically you open the progress form modally and then the progress form
>immediately calls a Public procedure in the main form to initiate the
>processing. Let's say frmMain is the caller and frmProg is the shiny thing.
>In frmMain you called InitiateLongProcess. A few lines down it say
>frmProg.Show vbModal. InitiateLongProcess is now "suspended" pending the
>de-modalizing of frmProg. However, frmProg can call RunLongProcess in
>frmMain and that procedure WILL execute. You can then update frmProg from
>this procedure as it does its work. The benefit of this is that you truly
>have a modal situation going on, so if, say, the user clicks on the taskbar
>icon for your app frmProg will be activated. If you go the "display a form
>modelessly but disable the main form," the scenario I just described will
>actually make the main form look as though it's active (it'll get the active
>title bar colors) and the progress form will appear inactive.
Thanks Jeff! I like the idea of calling the Public procedure on the
main form from the modal form.
You're also right about the taskbar issues and the inconsistency in
general appearance regarding what's active. I was thinking about same
things which is why I also set the ShowInTaskabar property of the
progress form to False, of course, so it doesn't clutter the taskbar.
>The extra setup I mentioned involves the fact that you're going to have at
>least two different procedures: InitiateLongProcess and RunLongProcess in my
>example. If you pass parameters to InitiateLongProcess they won't be
>available to RunLongProcess unless you store them in module-level variables
>(in which case passing them as parameters is unnecessary) or you pass them
>all into frmProg and then have frmProg re-pass them to RunLongProcess. I
>don't like that approach and go with either multiple module-level variables
>or a single module-level class or UDT with members that correspond to all
>the necessary parameters that RunLongProcess will need.
I've been thinking along those very lines as well, and also prefer the
module level (global) variables. For example, that's where my
CancelFlag lives which the custom progress bar form sets to signal the
main form if the user decides to stop the procedure.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| J French 2005-03-25, 8:59 am |
| On Thu, 24 Mar 2005 19:36:42 +0100, Danny
<NOSPAMFORdaniel_ahorn@yahoo.com> wrote:
<snip>
[color=darkred]
>Do you mean use VB's native Progress Bar? I used to do that but I'm
>running out of space on the main form and don't want to fork it into
>separate forms yet or use tabs.
No way !
I wrote my own years back
>Also, native Progress Bar is somewhat limiting (no % display, for
>example). By using a custom progress bar I can also provide additional
>information, say, color it conditional on the process currently taking
>place and so on.
Absolutely - if you write your own you have 100% control over it
|
|
|
|
|