Updating .DOT Files in Startup Folder 
Author Message
 Updating .DOT Files in Startup Folder

        Thanks in advance to anyone with advice/opinions/input.
        I've designed a VBA application we call be the acronym "FAST" (an in-joke
because little in our company ever runs fast ...).  It's a set of about 100 automated
documents users access through menus on the Word 97 menu bar.  These are all .DOC
files stored out on their servers; the code to run the system is stored in a template
file, FAST.DOT.
        Originally, we placed FAST.DOT out on the server in the same public folder as
the .DOC files.  For various reasons (including performance), we've decided to move
the FAST.DOT from the server to each user's workstation, to the C:\FAST folder.
        FAST always loads automatically upon Startup.  Originally, the Startup folder
was the FAST folder on the server; now, it's C:\FAST.
        All pretty much routine stuff, right?
        Okay, here's the problem ... What happens when FAST.DOT needs to be updated?
        If FAST.DOT is out on the server, no problem, I just go in when no one is using
the system and overwrite it with the upgrade.  But now that FAST.DOT is on each
user's workstation, I need to write a procedure that copies the upgrade (FAST.NEW)
from the server to the workstation and overwrites the old file (removing the old
FAST.DOT and renaming FAST.NEW to FAST.DOT in the C:\FAST folder).
        FAST.DOT is in the Startup folder, so it loads automatically when Word starts.
FAST.DOT contains an AutoExec macro which installs an AddIn on the server called
UPDATE.DOT.  This update file has its own AutoExec macro which uninstalls FAST.DOT as
an AddIn and then attempts to copy FAST.NEW up to the workstation to overwrite
FAST.DOT.
        Here's the problem I'm having -- it seems that when FAST.DOT loads, it opens a
temporary file, ~$FAST.DOT.  Even after I uninstall FAST.DOT as an AddIn -- when I
run the UPDATE.DOT's AutoExec procedure step-by-step, I can switch over and see it's
no longer listed as an AddIn -- this ~$FAST.DOT file is still open in the C:\FAST
folder.  Because it's there, when the update tries to overwrite the old file, I get
an error message "Permission Denied" because it thinks the old file is still in use.
        I suspect the problem is because the FAST.DOT AutoExec is still in memory,
running UPDATE.DOT's AutoExec.  If I manually uninstall FAST.DOT as an AddIn, then
open UPDATE.DOT and run AutoExec manually, the upgrade installs just fine because no
~$FAST.DOT file is open.
        Any suggestions?  It seems to me that the solution is not only to detach
FAST.DOT as an AddIn but I need to figure out some way for it to stop running its
AutoExec macro before the UPDATE.DOT AutoExec runs.
        Thanks,
        Stephen


Mon, 08 Mar 2004 22:26:12 GMT  
 Updating .DOT Files in Startup Folder
Stephen,

Much simpler to update each PC's copy with an XCOPY command at bootup.
See http://www.mvps.org/word/FAQs/MacrosVBA/DistributeMacros.htm for
details.


-- See the MVP FAQ at http://www.mvps.org/word --------------------
----------- "Life is nothing if you're not obsessed." --John Waters
-------------------------------------------------------------------
Please reply only to the newsgroup.

Quote:

>         Thanks in advance to anyone with advice/opinions/input.
>         I've designed a VBA application we call be the acronym "FAST" (an in-joke
> because little in our company ever runs fast ...).  It's a set of about 100 automated
> documents users access through menus on the Word 97 menu bar.  These are all .DOC
> files stored out on their servers; the code to run the system is stored in a template
> file, FAST.DOT.
>         Originally, we placed FAST.DOT out on the server in the same public folder as
> the .DOC files.  For various reasons (including performance), we've decided to move
> the FAST.DOT from the server to each user's workstation, to the C:\FAST folder.
>         FAST always loads automatically upon Startup.  Originally, the Startup folder
> was the FAST folder on the server; now, it's C:\FAST.
>         All pretty much routine stuff, right?
>         Okay, here's the problem ... What happens when FAST.DOT needs to be updated?
>         If FAST.DOT is out on the server, no problem, I just go in when no one is using
> the system and overwrite it with the upgrade.  But now that FAST.DOT is on each
> user's workstation, I need to write a procedure that copies the upgrade (FAST.NEW)
> from the server to the workstation and overwrites the old file (removing the old
> FAST.DOT and renaming FAST.NEW to FAST.DOT in the C:\FAST folder).
>         FAST.DOT is in the Startup folder, so it loads automatically when Word starts.
> FAST.DOT contains an AutoExec macro which installs an AddIn on the server called
> UPDATE.DOT.  This update file has its own AutoExec macro which uninstalls FAST.DOT as
> an AddIn and then attempts to copy FAST.NEW up to the workstation to overwrite
> FAST.DOT.
>         Here's the problem I'm having -- it seems that when FAST.DOT loads, it opens a
> temporary file, ~$FAST.DOT.  Even after I uninstall FAST.DOT as an AddIn -- when I
> run the UPDATE.DOT's AutoExec procedure step-by-step, I can switch over and see it's
> no longer listed as an AddIn -- this ~$FAST.DOT file is still open in the C:\FAST
> folder.  Because it's there, when the update tries to overwrite the old file, I get
> an error message "Permission Denied" because it thinks the old file is still in use.
>         I suspect the problem is because the FAST.DOT AutoExec is still in memory,
> running UPDATE.DOT's AutoExec.  If I manually uninstall FAST.DOT as an AddIn, then
> open UPDATE.DOT and run AutoExec manually, the upgrade installs just fine because no
> ~$FAST.DOT file is open.
>         Any suggestions?  It seems to me that the solution is not only to detach
> FAST.DOT as an AddIn but I need to figure out some way for it to stop running its
> AutoExec macro before the UPDATE.DOT AutoExec runs.
>         Thanks,
>         Stephen



Mon, 08 Mar 2004 22:42:45 GMT  
 Updating .DOT Files in Startup Folder
        Mark, thank you for the suggestion.  While your solution is obviously the
simplest way to do it, unfortunately for political reasons unique to our company the
I.S. department responsible for workstation configurations will not cooperate with
application upgrade deployment.  We developers are stuck with supporting ourselves,
therefore I need to find a way to do it within the VBA application itself.
        Stephen
Quote:

>Stephen,

>Much simpler to update each PC's copy with an XCOPY command at bootup.
>See http://www.mvps.org/word/FAQs/MacrosVBA/DistributeMacros.htm for
>details.


>-- See the MVP FAQ at http://www.mvps.org/word --------------------
>----------- "Life is nothing if you're not obsessed." --John Waters
>-------------------------------------------------------------------
>Please reply only to the newsgroup.



Tue, 09 Mar 2004 00:26:38 GMT  
 Updating .DOT Files in Startup Folder

Nnngh, well, it's going to be tough.  VBA gets quite upset if you
try to do things to an open file, so doing it in a Word VBA macro
will be quite a chore, if not impossible.  As I recall there is a
sneaky method using the WordBasic object (WordBasic being not quite
as protective as VBA in this area), but I'm unfamiliar with the
specifics.  Years ago I attempted something similar using VBA and
gave up.

Sure sounds like the politics of your I.S. department could stand a
little revolt.  What could possibly be the reason for stonewalling
needed updates?  And (shudder) is the network small enough that you
could just install the little XCOPY batch file in each PC's Startup
folder?


-- See the MVP FAQ at http://www.mvps.org/word --------------------
----------- "Life is nothing if you're not obsessed." --John Waters
-------------------------------------------------------------------

Quote:

>         Mark, thank you for the suggestion.  While your solution is obviously the
> simplest way to do it, unfortunately for political reasons unique to our company the
> I.S. department responsible for workstation configurations will not cooperate with
> application upgrade deployment.  We developers are stuck with supporting ourselves,
> therefore I need to find a way to do it within the VBA application itself.
>         Stephen


> >Stephen,

> >Much simpler to update each PC's copy with an XCOPY command at bootup.
> >See http://www.mvps.org/word/FAQs/MacrosVBA/DistributeMacros.htm for
> >details.


> >-- See the MVP FAQ at http://www.mvps.org/word --------------------
> >----------- "Life is nothing if you're not obsessed." --John Waters
> >-------------------------------------------------------------------
> >Please reply only to the newsgroup.



Tue, 09 Mar 2004 01:40:46 GMT  
 Updating .DOT Files in Startup Folder

Quote:

>Sure sounds like the politics of your I.S. department could stand a
>little revolt.  What could possibly be the reason for stonewalling
>needed updates?  And (shudder) is the network small enough that you
>could just install the little XCOPY batch file in each PC's Startup
>folder?


>-- See the MVP FAQ at http://www.mvps.org/word --------------------
>----------- "Life is nothing if you're not obsessed." --John Waters
>-------------------------------------------------------------------

        Yeah, my company is pretty screwed up.  I could tell you some real horror
stories.  It's so bad that some non-I.S. divisions have hired their own programmers
because I.S. won't support them.  I have about 12 years in computer
programming/support and come from an I.S. background but I'm on the payroll of one of
the non-I.S. divisions.
        Most of the problems stem from our CEO.  Our company has 6,000 employees yet he
personally reviews just about everything related to computer technology.  To buy one
workstation, we have to write a five-page cost/benefit analysis and get his personal
approval.  The only reason we have NT networks now is thanks to Y2K, otherwise we'd
still be on old PS/2 diskless workstations running Netware, WordPerfect for DOS and
Q&A.  In fact, when we got Windows during the Y2K upgrade we developers were told --
this is word for word -- "Y2K is not an excuse for improvement in productivity."  We
were to replicate old DOS apps exactly in their Windows equivalents.  We were not
allowed to improve them.  Old flat-file Q&A databases had to be replicated as
flat-files in MS Access.  Very frustrating.
        I'll give some thought to the XCOPY/Startup folder suggestion.  It's intriguing
but rather difficult to support.  Many times our tech support's solution to a problem
is to reimage a workstation.  There's no way they'd include such a scheme in the
image.
        Stephen


Tue, 09 Mar 2004 05:17:03 GMT  
 Updating .DOT Files in Startup Folder
You might be able to do it with two globals, A and B. Have the first one (A)
in the user's startup folder and the second (B) elsewhere on the user's
system (possibly a folder called "Global" in the startup folder). Have the A
use an AutoExec macro check to see if a new version of B is on the network,
if there is, copy it to "Global," overwriting the existing file, then
outside of the IF structure, load B as an Add-In. You probably could have B
unload A and perform the same kind of check/replace if you wanted. And no, I
haven't written the code to do this, just thinking out loud. Hope it helps.
--
Charles Kenyon

Word New User FAQ & Web Directory:
<URL: http://www.addbalance.com/word/index.htm>

Intermediate User's Guide to Microsoft Word (supplemented version of
Microsoft's Legal Users' Guide)
<URL: http://www.addbalance.com/usersguide/index.htm>

See also the MVP FAQ: <URL: http://www.mvps.org/word/> which is awesome!
 --------- --------- --------- --------- --------- ---------
This message is posted to a newsgroup. Please post replies
and questions to the newsgroup so that others can learn
from my ignorance and your wisdom.



Quote:
> Mark, thank you for the suggestion.  While your solution is obviously the
> simplest way to do it, unfortunately for political reasons unique to our
company the
> I.S. department responsible for workstation configurations will not
cooperate with
> application upgrade deployment.  We developers are stuck with supporting
ourselves,
> therefore I need to find a way to do it within the VBA application itself.
> Stephen



> >Stephen,

> >Much simpler to update each PC's copy with an XCOPY command at bootup.
> >See http://www.mvps.org/word/FAQs/MacrosVBA/DistributeMacros.htm for
> >details.


> >-- See the MVP FAQ at http://www.mvps.org/word --------------------
> >----------- "Life is nothing if you're not obsessed." --John Waters
> >-------------------------------------------------------------------
> >Please reply only to the newsgroup.



Tue, 09 Mar 2004 05:27:56 GMT  
 Updating .DOT Files in Startup Folder
        Thank you Charles.  I'll give it some thought.
        Actually, I think I have an idea and I'm going to try it right now ... Part of
the AutoExec procedure writes the version number to the Registry.  When the
UPDATE.DOT template loads, the first thing it does is compare its version number to
that stored in the Windows Registry.  If the new version's number is higher than the
Registry number, it runs the update, otherwise it exits and life goes on.
        Here's what I'm going to try ... If the above check determines an upgrade is
necessary, it will change the Startup folder from C:\FAST to a server folder where
the Upgrade template will be (for the sake of argument, G:\UPGRADE).  A message box
will appear advising the user that Word is about to automatically close; they will
need to restart Word to install the upgrade.
        So Word restarts with the Startup folder now set to G:\UPGRADE.  The FAST.DOT
template in C:\FAST does *not* load because C:\FAST is no longer the Startup folder.
UPDATE.DOT is now free to overwrite FAST.DOT with the new version.  The procedure
finishes up by changing the Startup folder back to C:\FAST, and advises the user that
after Word automatically closes again they need to restart it one more time.  When
they do so, Word loads the upgraded FAST.DOT template because once again C:\FAST is
the Startup folder.
        Sounds like it should work, doesn't it?  It's kinda kludgy but as we know
Windows users are used to having to restart apps all the time so upgrades can take
effect.
        Anyway, I'll report back if it works.
        Stephen

On Thu, 20 Sep 2001 16:27:56 -0500, "Charles Kenyon"

Quote:

>You might be able to do it with two globals, A and B. Have the first one (A)
>in the user's startup folder and the second (B) elsewhere on the user's
>system (possibly a folder called "Global" in the startup folder). Have the A
>use an AutoExec macro check to see if a new version of B is on the network,
>if there is, copy it to "Global," overwriting the existing file, then
>outside of the IF structure, load B as an Add-In. You probably could have B
>unload A and perform the same kind of check/replace if you wanted. And no, I
>haven't written the code to do this, just thinking out loud. Hope it helps.
>--
>Charles Kenyon



Tue, 09 Mar 2004 06:51:22 GMT  
 Updating .DOT Files in Startup Folder
        Just a note that this idea seems to work.  The user winds up having to restart
Word twice but it does get around the problem of closing the template so it can be
overwritten.
        Stephen


Wed, 10 Mar 2004 03:55:29 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. loading another dot file automatically at startup.....

2. Build XML of folders, sub folders and files from specified folder

3. How to delete folders/files within a folder but not the folder itself

4. Find files updated after certain date in a folder

5. Application/Startup folder

6. how to access the common startup folder?

7. How to debug code in startup folder

8. updated question: .doc references .dot in same directory, instead of template directory (not what I wanted)

9. access the common startup folder

10. The Windows startup folder

11. Prevent startup folder via VB

12. How autostart startup folder

 

 
Powered by phpBB® Forum Software