[AccessD] Shelling to a batch file - doevents

Gustav:  I believe you are right, time I moved on.  Right now application development/maintenance is a part time job I fit in as other duties allow and I'd have to take learning on as a hobby which is pretty much the way I started all this.  The odd emergency arises where I am the only person competent to efficiently deal with a specific IT problem.  I've been tasked with finding my replacement for the past two years.  The problem is that they are looking for someone who understands in house business processes and i've been unable to find someone willing or able to do what it takes.  The management job in safety I've been given allows them to pay me several times over what I was previously paid and my boss sees the IT role as only an intermittent or part time job for me or any replacement.

 

I wasn't seeking a solution for the progress bar but was merely giving an example of using ShellWait to force an external process to run synchronously with Access code and in that context, one point where I found DoEvents useful.

 

Undoubtedly most listers are aware of the built in progress bar and I like to leverage built in capabilities and am familiar with the lack of responsiveness of the built in progress indicator when running queries.  For those who haven't used it, the built in progress bar allows you to set a number representing 100% completion and allows a parameter to allow it to set where it is in relation to that completion number.  It works great if Access does not commadeer its use when you want to use it.  The only thing I've found is that I need to call DoEvents to allow Access to breath when it gets busy so it actually displays the bar update running on a workstation.  All users now run the application from a remote site over a VPN connection and DoEvents is inadequate to update the bar.

 

I've found and built pop up progress bar form examples but really can't be bothered.  The hourglass mouse pointer works and most people have some concept of how long things take when they've used the application a few years.

 

I hadn't bothered to log in to get the syntax I've been using but did so this morning.  Given a long, lngC that represents a count of records, each of which require creation of a document or some other process that takes a fairly standard block of time per iteration:

 

DoCmd.Hourglass True

If not r.Eof

r.MoveLast

r.MoveFirst

lngC = r.RecordCount

 

Do While not r.Eof

.

.

If lngC > 1 Then
    SysCmd acSysCmdInitMeter, lngC & " Documents selected for creation", lngC
Else
    SysCmd acSysCmdInitMeter, "One Document selected for creation", lngC
End If
.

.'build document

.

SysCmd acSysCmdUpdateMeter, lngC
DoEvents

 

r.MoveNext

Loop

 

'exit routine

DoCmd.Hourglass False
SysCmd acSysCmdRemoveMeter


 


Ciao Jürgen Welz

Edmonton, Alberta jwelz at hotmail.com


 
> Date: Sun, 7 Mar 2010 09:48:25 +0100
> From: Gustav at cactus.dk
> To: accessd at databaseadvisors.com
> Subject: Re: [AccessD] Shelling to a batch file - doevents
> 
> Hi Jürgen
> 
> Oh, I thought you were running some custom progress bar.
> In my experience, if the native progress bar runs in the status bar of Access, you can't do anything about it - except pressing Ctrl+Break if you are running a query manually.
> Whatever you ask your app to do, it will impose some load at server side - that's the basic idea of Citrix and other terminal services - the client only handles screen display and user interaction. One of the differences between Citrix and other terminal solutions including Remote Desktop is, as I have understood it, that it is better at compressing and optimizing data between server and client.
> My guess is that during this optimizing process, Citrix misses that the status bar has updated (it is not part of your nett application screen area), thus fails to send an updated screen display to your clients. As there is no event for progress-bar-updated you can't even do some API call to Citrix to force an update - and even if you could, that wouldn't help as Access will be busy with its single thread running the query. Seems like you are out of luck.
> 
> Time to move to dotNet, Visual Studio and C#. I think you will love it as you have bumped nearly every corner and edge of Access through the years. As you are a man of the details you will appreciate to be able to tweak almost everything - as Charlotte wrote a while back, in dotNet you can do almost everything in not one but many ways so you can easily be caught in exploring options.
> 
> /gustav 		 	   		  
_________________________________________________________________
Take your contacts everywhere
http://go.microsoft.com/?linkid=9712959