Jay
Tue Sep 28 14:06:51 CDT 2004
You have to think about how Word finds the code that it executes.
- If the macro is stored in the active document and you close the document,
the code is immediately removed from memory and the macro gets killed off
immediately.
- If the macro is stored in the template you based the active document on,
and the active document is the only open document that loads that template,
then closing the document also unloads the template. Ditto.
- If the macro is stored in the template of the active document, but there
is at least one other open document based on that template, the macro will
remain in memory and (I think) executing after closing the active document.
- Finally, if the macro is stored in a global template (possibly normal.dot,
maybe another global), opening and closing documents has no effect except
that any statements involving ActiveDocument or the Selection will cause
errors. This is probably the direction you should go.
--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:
http://word.mvps.org
kiln wrote:
> Thanks I'll try that, but first, and this is something I've never
> understood about word programming (how to get around it I mean), if I
> Close the activedoc, then all code after that line never fires. I've
> seen other Word novices ask about the same issue but don't recall if
> there was a solution posed.
>
> So essentially, if I have the users click on a custom toolbar button
> that closes the active doc, and immedately tries the Name routine,
> it'll never get to the Name line.
>
> Too bad, the SaveAs behavior of word 2002 seems to work correctly; is
> the broken SaveAs of Word 2000 documented? Such an essential method to
> leave trashed over several service packs, I just don't get it.
>
> In article <43nhl05n3uq3egk3ouggcv68khlkvic2bi@4ax.com>,
> jay.freedman@verizon.net says...
>> Hi kiln,
>>
>> I haven't tried it, so I don't know what gotchas you'll run into, but
>> I think the Name function is your tool of choice here. Close the
>> original document, and then run the statement
>>
>> Name oldpathname As newpathname
>>
>> Here's the Remarks section from the help topic on Name:
>>
>> "The Name statement renames a file and moves it to a different
>> directory or folder, if necessary. Name can move a file across
>> drives, but it can only rename an existing directory or folder when
>> both newpathname and oldpathname are located on the same drive. Name
>> cannot create a new file, directory, or folder.
>>
>> Using Name on an open file produces an error. You must close an open
>> file before renaming it. Name arguments cannot include
>> multiple-character (*) and single-character (?) wildcards."
>>
>> --
>> Regards,
>> Jay Freedman
http://aspnet2.com/mvp.ashx?JayFreedman
>> Microsoft Word MVP FAQ:
http://word.mvps.org
>>
>> kiln <kiln@brick-like.com> wrote:
>>
>>> This is my third post on the subject; it's creating real problems
>>> for me, I hope someone who understands the peculiarities of Word
>>> programming will lend a hand. Strangely there is almost nothing I
>>> can find via google on the subject.
>>> ...
>>> How does one move the active doc; this issue is givimg all sorts of
>>> problems. I've tried several solutions but not work reliably.
>>>
>>> For instance, I thought I'd perform a SaveAs from within Word; that
>>> should move the Active Document pointer or whatever it's called to
>>> the newly saved doc; the orig doc should be closed. Then, use Kill
>>> to delete the orig file. This approach works fine on some machines,
>>> on other machines it fails with error 70 permission denied. The
>>> orig file is still open on some machines (but not others). On those
>>> machines I can see that the file exits in both locations, and the
>>> open file is the orig file.
>>>
>>> Why is word so inconsistent with this fundemental behavior? Via menu
>>> choices, in all cases SaveAs moves the current file to the "new"
>>> file. I am programming in Word 2002 and the machines that have this
>>> issue are Word 2000 - but the saveas behavior is so basic that I
>>> can't imagine that it's deliberately different programming this in
>>> the two versions.