run Shell with /wait

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm creating a cmd file I want to run with Shell which copies an existing
file, performs an operation on it which will change the file size, and then
deletes the original and saves the new file back with the old file name.
After the cmd file finishes, I want to report the length of the new file size
using FileLen.

By default, Shell executes asynchronously, which means my VBA code which
runs after the Shell statement and tries to report the length of the file
created using FileLen, fails. It reports the size of the original file.

I've tried using /wait in the cmd file which runs, but that hasn't helped.

Is there a way to make Shell Wait until the operation it started finishes,
and then proceed to the rest of the VBA code?

Thanks,

Kevin
 
Allen -

Thanks very much for your response. I know you've been one of the Most
Valuable Players here for a long time, and I certainly appreciate your help

But really, isn't it time we just acknowledged that the Emperor has no
clothes? Why the hell shouldn't have the MS designers have recognized that
this is something that people want to do, and have built it in, instead of
having to have us jump through all the hoops we have to? I just heard, for
example. that vb.net has no Left or Right function. Have their designers
never had to develop an app? It's a typical example of why people like me
are gettting disgusted with MS. There are a thousand examples of how MS has
blown it in the past 30 years, changing things which worked in W/2k to things
which don't work in W/XP.

Believe me, this is not a diatribe at you, but because I think you may have
MS's ears, a diatribe to them. If they'd written their software right in the
first place, a lot of these support forums wouldn't be necessary. And it's
not because they're short of cash, they're just short of user wisdom, and
long on techs. Hey, ask anyone who deals with Word!

A thoroughly disgusted with MS, and eternally grateful to you..

Kevin (Who promises he won't write any more diatribes like this to you.)
 
Kevin, you're very welcome to your opinion, and no offence taken.

MS has had a couple of goes at plugging the FileOpen dialog into Access. The
earlier example was a "common control", but it was quite buggy, and broke
the database when you moved versions, so most of us gave up on it recently.
The more recent example is the FileDialog object supplied by the Office
library, but it is also unworkable. It is version dependent, fails to work
with SaveAs (even though it appears to offer this option), and does not work
at all in the runtime version. So, the API call is still the best approach.

For me, this kind of thing is just mildly annoying. Once you get the API
call working the first time, you just copy the module and use it in any
database where you need this. What really annoys me are the cases where
Access actually *appears* to work but gives you the wrong answers! Those are
the ones I would like to get Microsoft to fix, but I've not been very
successful to date. We are talking about basic stuff like Access sorting
wrongly, returning the wrong records in a query, silently losing the data
you typed into a form, corrupting your data, displaying the wrong
information and so on. Since I can't get them to fix this stuff, the best I
can to is to warn other users about these flaws:
http://allenbrowne.com/tips.html#flaws

On the positive side, though, MS should be commended for the knowledgebase
where you can get to know about these flaws, traps, and other issues. It is
also commendable that they encourage these groups with free feedback and
assistance, even though we sometimes use these forums to complain about what
we don't like.
 
Thanks again, Allen. I hadn't seen your tips before, and they're very
useful. And ShellWait worked a treat.

Kevin
 
Back
Top