Prev: windows mobil develop
Next: Error 70 - Permission Denied
From: Karl E. Peterson on 25 Mar 2010 20:11
Webbiz wrote:
> My first thought is to create a flag called gbDataLoading and place
> this at the start of the MouseMove, MouseUp, MouseDown, KeyPress,
> KeyUp, KeyDown...etc. event procedures. When gbDataLoading is True,
> these event procedures will exit immediately before running their
> code.
>
> But is this the way to go? Or does VB offer a better way to do this?

My "vote" would be for this, rather than freezing the form. That way,
you're not queuing events. Sure wouldn't hurt to display progress in
some way, though. Might be better to pop a modal form with a progbar
on it, if it's really taking more than a couple seconds.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: MikeD on 25 Mar 2010 20:42


"Webbiz" <nospam(a)noway.com> wrote in message
news:ufrnq5h3r79ikj3pq97q00c3jj05vppjk0(a)4ax.com...
> On Thu, 25 Mar 2010 18:10:44 -0500, Webbiz <nospam(a)noway.com> wrote:
>
> While thinking about this, I decided to try disabling the form the
> events are in to see how that would work out. It seems to be working
> this way.
>
> frmForm.Enabled = False
>
> {do my long winded code}
>
> frmForm.Enabled = True
>
>
> Proper programming or bad practice?
>

Like the other responses, I don't think there's anything wrong with this as
long as the user doesn't need to interact with the form or controls on the
form (for example, click a cancel button). Per other suggestions, some sort
of progress display would probably be nice, be it on this form (you can
still update a progressbar even if the form is disabled) or another "static"
form.

--
Mike



From: Webbiz on 26 Mar 2010 03:19
On Thu, 25 Mar 2010 17:11:33 -0700, Karl E. Peterson <karl(a)exmvps.org>
wrote:

>Webbiz wrote:
>> My first thought is to create a flag called gbDataLoading and place
>> this at the start of the MouseMove, MouseUp, MouseDown, KeyPress,
>> KeyUp, KeyDown...etc. event procedures. When gbDataLoading is True,
>> these event procedures will exit immediately before running their
>> code.
>>
>> But is this the way to go? Or does VB offer a better way to do this?
>
>My "vote" would be for this, rather than freezing the form. That way,
>you're not queuing events. Sure wouldn't hurt to display progress in
>some way, though. Might be better to pop a modal form with a progbar
>on it, if it's really taking more than a couple seconds.


It's about a one second delay, but enough to catch a mouse move and
cause havec <sp?>.

:-)
Webbiz
From: Jeff Johnson on 26 Mar 2010 17:09
"Bob Butler" <noway(a)nospam.ever> wrote in message
news:%232LYpaHzKHA.4492(a)TK2MSFTNGP05.phx.gbl...

> IMO, it's fine except you should change the MousePointer on the form andor
> the screen object and you may need a Doevents or a refresh to make that
> change show up.

I can't imagine why anyone would ever use Form.MousePointer to set the wait
cursor. It only applies to the client area of the form (the mouse changes
back to the default cursor over the title bar, etc.) and no other Windows
apps on the planet behave that way when they go into a busy state. As far as
I'm concerned, "wait cursor" ALWAYS means Screen.MousePointer.


From: Mike Williams on 26 Mar 2010 18:02

"Jeff Johnson" <i.get(a)enough.spam> wrote in message
news:ONa3uiSzKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> "Bob Butler" <noway(a)nospam.ever> wrote in message
> news:%232LYpaHzKHA.4492(a)TK2MSFTNGP05.phx.gbl...
>
>> IMO, it's fine except you should change the MousePointer on the
>> form and or the screen object and you may need a Doevents or
>> a refresh to make that change show up.
>
> I can't imagine why anyone would ever use Form.MousePointer to
> set the wait cursor. It only applies to the client area of the form (the
> mouse changes back to the default cursor over the title bar, etc.)
> and no other Windows apps on the planet behave that way when
> they go into a busy state. As far as I'm concerned, "wait cursor"
> ALWAYS means Screen.MousePointer.

Perhaps it's all those other apps that are doing it wrong ;-) Personally I
would make the decision based on exactly what it is I am doing, without
regard to what other apps do. From Webbiz's description he wants to disable
the events for most or all of the contents of the Form whilst a specific
task which takes a fairly long time is carried out. That does not
necessarily mean that he wants to disable the entire Form. In fact in most
cases it is probably not what you would want to do, otherwise the user would
be unable to move the Form around the display or minimize it or whatever
whilst the task was being carried out, which would annoy most users. In such
cases you would not want to use Screen.MousePointer because it would appear
to the user that he is not allowed to perform certain actions on the Form
when he is in fact permitted to do so.

Mike



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: windows mobil develop
Next: Error 70 - Permission Denied