Prev: windows mobil develop
Next: Error 70 - Permission Denied
From: Jeff Johnson on 26 Mar 2010 23:20

"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message
news:Oa0V$$SzKHA.5936(a)TK2MSFTNGP04.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.

In which case you should use the "busy" cursor instead (default being the
mouse with hourglass) to let the user know that some lengthy operation is
taking place but you can still do other things. If you do throw up the true
wait cursor, though, I maintain it should stay that way for the entire form.
Even in the case of the busy cursor it should be that way for the entire
form. I truly cannot see why Form.MousePointer exists.


From: Eduardo on 27 Mar 2010 10:14
Webbiz escribi�:
> My app loads data that sometimes can be quite large. When it does, I
> don't want some events to fire, such as the MouseMove or KeyPress
> events.
>
> The reason is that these events rely on the number of records loaded
> as a value, such as RecCnt. Until the data is loaded, RecCnt will have
> a value based on the last datafile loaded. So until the new data is
> loaded, any action on the old value will cause an error.
>
> 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?
>
> It took me awhile to even find this bug. My code was running
> procedures that rely on RecCnt when I was changing from one datafile
> to another and it drove me crazy. But then I ran the Call Stack and
> discovered MouseMove was being triggered. So that explains why it was
> intermittent.
>
> Suggestions?

But... why are the events fired?
Are you using DoEvents in the procedure that loads the data?
From: Mike Williams on 28 Mar 2010 03:17
"Jeff Johnson" <i.get(a)enough.spam> wrote in message
news:erJJEyVzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>
> "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message
> news:Oa0V$$SzKHA.5936(a)TK2MSFTNGP04.phx.gbl...
>> 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.
>
> In which case you should use the "busy" cursor instead (default
> being the mouse with hourglass) to let the user know that some
> lengthy operation is taking place but you can still do other things.
> If you do throw up the true wait cursor, though, I maintain it
> should stay that way for the entire form. Even in the case of the
> busy cursor it should be that way for the entire form. I truly
> cannot see why Form.MousePointer exists.

I don't know what the "official view" on this is, but I am merely saying
what I personally would do and what I personally still stand by. If we all
follow then who is to lead? Personally I believe there is a very valid
reason why Form.MousePointer exists. For example, I would only show the
"Arrow and Hourglass" cursor when the mouse is over things that the user
cannot interact with and when there are other things somewhere else on the
Form than he can interact with, as is the case in the circumstances I
outlined in my post to which you are responding.

In the specific case I mentioned only the stuff in the Form's client area
was disabled (and therefore when the cursor is over the client area I would
show the "Arrow and Hourglass" cursor) but the user was still allowed to
move or resize or minimize the Form (and therefore when the cursor is over
the title bar and borders I would show the normal default cursor).
Therefore, to my mind, Form.MousePointer has a completely valid purpose.

Mike



From: Webbiz on 28 Mar 2010 14:28
On Sat, 27 Mar 2010 11:14:18 -0300, Eduardo <mm(a)mm.com> wrote:

>Webbiz escribi�:
>> My app loads data that sometimes can be quite large. When it does, I
>> don't want some events to fire, such as the MouseMove or KeyPress
>> events.
>>
>> The reason is that these events rely on the number of records loaded
>> as a value, such as RecCnt. Until the data is loaded, RecCnt will have
>> a value based on the last datafile loaded. So until the new data is
>> loaded, any action on the old value will cause an error.
>>
>> 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?
>>
>> It took me awhile to even find this bug. My code was running
>> procedures that rely on RecCnt when I was changing from one datafile
>> to another and it drove me crazy. But then I ran the Call Stack and
>> discovered MouseMove was being triggered. So that explains why it was
>> intermittent.
>>
>> Suggestions?
>
>But... why are the events fired?
>Are you using DoEvents in the procedure that loads the data?


I was, allowing for a break. But considering that now I'm disabling
the form for 1 sec, what's the point, right? Who needs to break a 1
sec load? LOL

So I've placed the DoEvents before the proc so that the screen can
finish drawing before the proc loop starts. Without DoEvents, the
startup isn't clean as the painting is delayed during data loading and
looks bad. It works good now.

:-)
Webbiz
From: Webbiz on 28 Mar 2010 14:31
On Sun, 28 Mar 2010 08:17:22 +0100, "Mike Williams"
<Mike(a)WhiskyAndCoke.com> wrote:

>
>"Jeff Johnson" <i.get(a)enough.spam> wrote in message
>news:erJJEyVzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>>
>> "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message
>> news:Oa0V$$SzKHA.5936(a)TK2MSFTNGP04.phx.gbl...
>>> 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.
>>
>> In which case you should use the "busy" cursor instead (default
>> being the mouse with hourglass) to let the user know that some
>> lengthy operation is taking place but you can still do other things.
>> If you do throw up the true wait cursor, though, I maintain it
>> should stay that way for the entire form. Even in the case of the
>> busy cursor it should be that way for the entire form. I truly
>> cannot see why Form.MousePointer exists.
>
>I don't know what the "official view" on this is, but I am merely saying
>what I personally would do and what I personally still stand by. If we all
>follow then who is to lead? Personally I believe there is a very valid
>reason why Form.MousePointer exists. For example, I would only show the
>"Arrow and Hourglass" cursor when the mouse is over things that the user
>cannot interact with and when there are other things somewhere else on the
>Form than he can interact with, as is the case in the circumstances I
>outlined in my post to which you are responding.
>
>In the specific case I mentioned only the stuff in the Form's client area
>was disabled (and therefore when the cursor is over the client area I would
>show the "Arrow and Hourglass" cursor) but the user was still allowed to
>move or resize or minimize the Form (and therefore when the cursor is over
>the title bar and borders I would show the normal default cursor).
>Therefore, to my mind, Form.MousePointer has a completely valid purpose.
>
>Mike
>
>

It's not really an hourglass these days, is it? More like a thick
blue circle that goes round and round. :-) Talking about Vista/Win 7
naturally.

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