Jurgen Welz
jwelz at hotmail.com
Sat Mar 6 15:37:38 CST 2010
Max: I rarely use doevents. I used to initialize the status bar with a recordset count and then update the progress indicator with the absolute position in the recordset as the records are sequentially processed. Works great on a PC running a local FE. Refresh appears to go get the data again. Not overhead I wish to incur. Repaint? Haven't tried. Over VPN to thin client both are a lot of bandwith to pump over an internet connection just to get a little status bar progress indicator to move. On a workstation the doevents around 'accmdupdateprogress, lngI' or whatever the constant is to update the progress indiator in the status bar works fine and does not require a refresh or repaint. It's in the Terminal Services environment where it doesn't work for me and that's exactly where I avoid additional overhead. I still have the code in place with th doevents but all that happens is the progress bar initializes and is removed when the processes complete. The calls to update it go unheeded and I write it off as a Microsoft feature. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com > From: max.wanadoo at gmail.com > To: accessd at databaseadvisors.com > Date: Sat, 6 Mar 2010 18:04:49 +0000 > Subject: Re: [AccessD] Shelling to a batch file > > Jurgen > > Have your tried frm.refresh : frm.repaint > Sometimes when doevents doesn't doevents, the above does ;0) > > > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz > Sent: Saturday, March 06, 2010 3:18 PM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Shelling to a batch file > > > I've never had much luck with doEvents in our Terminal Services environment. > For example, I used it tu update the status bar when processing a number of > files (say 100 invoice Word docs) that are written in sequence as a > recordset is traversed. Generally the status bar shows progress nicely on a > PC but just sort of stays put on our thin clients even with DoEvents. > Polling in a loop is the kind of thing that I always worried would get me > into trouble in a multi user environment. > > > > An example where shellWait shines is when I need to move a block of files > into place and need to be sure that they are there before processing them. > Our estimating data is housed in a header file, a sub folder and then 65 odd > files in the sub folder and then there may be additional sub foldlers. > That's the way of Pervasive data. I have a choice of creating an ODBC link > to the file structure wherever it is or moving the files into an existing > linked location and name them according to what the Access link expects. > > > > I used to do this using an API filecopy routine with an overwrite parameter > by building arrays of file names using the DIR function and then creating > the folders and copy/naming the files into the existing ODBC location. The > process ran synchronously so the code that worked with the data in situ > completed before processing the Pervasive data proceeded. > > > > By the way, moving the files is at least 30 times faster than creating the > link on the fly. > > > > All that was replaced by a single call to shellWait calling Robocopy.exe > (and then Name twice). > > > > Different strokes. > > Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com _________________________________________________________________ Take your contacts everywhere http://go.microsoft.com/?linkid=9712959