Freeze Event Responses...How?
in [Visual Basic]
|
From: Webbiz on 25 Mar 2010 19:10 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? Thanks. Webbiz
From: Webbiz on 25 Mar 2010 19:14 On Thu, 25 Mar 2010 18:10:44 -0500, Webbiz <nospam(a)noway.com> wrote: >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? > >Thanks. > >Webbiz 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? Thanks. Webbiz
From: GS on 25 Mar 2010 19:36 Webbiz explained : > 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? > > Thanks. > > Webbiz I use global flags to set AppState to whatever I'm doing. Events monitor AppState to determine their function status. If AppState says go then they execute, otherwise they terminate. AppState also sets the Enabled property for menus and other controls that I don't want the user to have access to during the running process that shouldn't be interupted. AppState is then reset at the end of the process and menus/controls return to their normal status for the new AppState. I've never had to disable an entire form myself, but I've used apps where that method is used. I suppose it depends on what you feel will be most beneficial for your project overall. Perhaps you'll find use for both approaches and use which ever is best for different situations. HTH -- Garry
From: Helmut Meukel on 25 Mar 2010 19:48 "Webbiz" <nospam(a)noway.com> schrieb im Newsbeitrag news:ufrnq5h3r79ikj3pq97q00c3jj05vppjk0(a)4ax.com... > On Thu, 25 Mar 2010 18:10:44 -0500, Webbiz <nospam(a)noway.com> wrote: > >>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. >> > > 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? > > Thanks. > > Webbiz Hi, is it just one form? Then I would definitively change the Cursor to hourglass. And always display a message like "Busy data loading - please wait" in a status bar. Helmut.
From: Bob Butler on 25 Mar 2010 19:54
"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: <cut> > 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} DoEvents ' suck in and discard any pending events > frmForm.Enabled = True > > > Proper programming or bad practice? 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. |