home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.visual.basic      MS Visual Basic discussions, NOT dot-net      10,840 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 9,087 of 10,840   
   SpeedBoy to Paul E. Orman   
   Re: Event handling precedence   
   17 Dec 04 10:47:58   
   
   From: speedboy@rogers.com   
      
   I have used a couple of things to instantly update status indicators on the   
   screen.   
      
   If the object supports it, try using the "[object].refresh" method   
   immediately   
   after updating the status to force the update (i.e., LED1.Refresh).   
      
   If that doesn't work (or if the object doesn't support the Refresh method)   
   I have used DoEvents to accomplish pretty well the same thing. This may,   
   however, have some unwanted side effects, allowing the user to click on   
   buttons while you are processing.   
      
   Good Luck   
      
   "Paul E. Orman"  wrote in message   
   news:4cGdncfb7eM_ul_cRVn-3w@comcast.com...   
   > I have a piece of VB code (.NET 1.1 - VB 2003) that loads data from a   
   > database through a timer.  So the timer is setup and from it I call the   
   > procedure that loads the latest records from the database.  This works   
   fine.   
   >   
   > However, I attempt to notify the user when data accesses occur.  The way I   
   > attempt to accomplish this is by changing the background color of a label   
   on   
   > the form the user is looking at.  I use red for when the database is   
   opened,   
   > yellow for data transfers and green for a successful completion of the   
   > operation - and then I set the color back to its original gray background   
   > after the operation.   
   >   
   > If this is put inline in my code - for most (not all) accesses the notify   
   > happens so fast you never see the color changes - so I want the change to   
   > last for a second or so.  So I set up another timer that essentially does:   
   >   
   > if color = gray then set color red   
   > if color = red then set color yellow   
   > if color = yellow then set color green   
   > if color = green then set color gray   
   >   
   > This timer works perfectly in any piece of standalone code.  However when   
   I   
   > set it from the routine that access the database, somehow the calls are   
   > stacked and I do not see them occur until the end of the database access.   
   >   
   > I initially suspected that the database I/O calls were occurring prior to   
   > the timer event and that the I/O was blocking the event.  However if I   
   place   
   > any type of debug statement in the code, the thing works.  So now I am   
   > wondering if it is caused by calling one timer event from a routine that   
   was   
   > launched from another timer event.   
   >   
   > Is there anyway to force the order of event handling (on time - and   
   without   
   > putting message boxes in the code) so that it would work as you would   
   > suspect based on code flow?   
   >   
   > Thanks for any and all help/suggestions,   
   > Paul Orman   
   > paul_orman@comcast.net   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca