Results 1 to 15 of 15
  1. #1
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts

    Temp version of global template after style copy

    I have all my styles in a global template on a server, and copy these styles to active docs by first attaching the global template to the active doc, then either reattaching the original template or attaching normal.

    This process leaves a temp version of the global template when Word is closed. (This temp is prefixed by ~$) This happens regardless of whether the active doc is the one that opened Word, or a secondary doc opened by Word, and also regardless of whether the active doc is saved or discarded.

    If I comment out the single line attaching the active doc to the global template, then there is no temp version of the global template left when Word closes.

    Clearly something remains active in memory. How can I kill it off?
    Stylus

  2. #2
    WS Lounge VIP
    Join Date
    Mar 2006
    Location
    Maryland, USA
    Posts
    690
    Thanks
    17
    Thanked 66 Times in 56 Posts
    The temp file you are seeing is called an owner file, described in this MS support article. It should be deleted when it and Word close properly. Perhaps you need to specifically close the global template after you attach a different template?

    Pam

  3. #3
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Pam

    I looked at the article you linked to. The file that remains doesn't have a .tmp extension, so I guess I should not have called it a temp file.

    The file I have a problem with drops the first two letters of the "real" file name and replaced them with "~$" - other than that, the file name is identical to the real file's name. One more thing: the real file's size is 525 KB, the leftover file is 1 KB.

    "Close the global template"... Hmmm. I don't think that I am "opening" it... Here is the code sequence:

    With ActiveDocument
    .UpdateStylesOnOpen = False
    .AttachedTemplate = strGlobalPath 'this is the line in question - commenting it out prevents the ghost file from remaining after word closes.
    .UpdateStyles
    .AttachedTemplate = strNrmlPath
    end with

    I figured that the link between the active doc and the global is broken once the active doc is connected to the normal template. Yet, clearly something remains in memory. If the Global is open in some sense, then how do I "close" it?

    Just ran an experiment by appending strGlobalPath = "" at the end of the code above and the ghost file still remains.

    I'm grateful for anybody's ideas!
    Stylus

  4. #4
    WS Lounge VIP
    Join Date
    Mar 2006
    Location
    Maryland, USA
    Posts
    690
    Thanks
    17
    Thanked 66 Times in 56 Posts
    It's a bit far down the page, but describes the temp file name you see:

    "Owner File (Same Directory as Source File)
    When a previously saved file is opened for editing, for printing, or for review, Word creates a temporary file that has a .doc [or .docx/t or dotx/t] file name extension. This file name extension begins with a tilde (~) that is followed by a dollar sign ($) that is followed by the remainder of the original file name. This temporary file holds the logon name of person who opens the file. This temporary file is called the "owner file." "


    When a template is attached to a doc fie, Word opens it. See for yourself: Open Word. Then go to C:\Users\[UserName]\AppData\Roaming\Microsoft\Templates. If you have Explorer set to show hidden file, you'll see a temp file called ~$Normal.dotm. When you close Word, that temp file will go away.

    In earlier versions (?), the owner file for a renamed document would remain until the new renamed file was closed (both ~$Oldname.doc(x) and ~$Newname.doc(x) appeared in the folder). It happened with W2003 and Windows XP and, I thought, with W2007. It is not happening with W2010 and Windows 7 today. I work on a lot of client systems and each has its own setup (O2007 on XP, O2003 on Windows 7, you name it) So I don't know whether the change came with the Office version or the operating system. At any rate, you might be able to use this info as a clue.

  5. #5
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Pam

    What can I say... it was Friday afternoon... Henceforth I will read ALL the material someone links me to. Thank you for patience!

    I have been experimenting with this situation and so far I manage to crash word... I can't figure out what exactly I'm aiming at. What is it that keeps this temp file open after Word closes?

    What confuses things is that when a doc is opened it first gets a connection to the global template as an AddIn, and then my style copy sub also attaches the same global template (after which it attaches the normal template). So at one point the doc in question has the global template both as an AddIn and as an attached template. Intrestingly, that doesn't cause a problem, it just leaves this temp file floating around.

    If I use VBA to close or delete the global, then Word crashes, because the main global template either closes or detaches.

    Does anybody else have some leads for me?
    Stylus

  6. #6
    WS Lounge VIP
    Join Date
    Mar 2006
    Location
    Maryland, USA
    Posts
    690
    Thanks
    17
    Thanked 66 Times in 56 Posts
    No apologies needed. I think you've hit on the problem--which is not really a problem in that it is the way Word works. From what you describe, when you start this process the template you want to attach as a document template is already loaded as a global template (say, Stillthere.dotx). You then attach it as a document template, update the document styles, and then detach it by attaching a different template. But you see the owner file, ~$illthere.dotx, in the folder. That's because it is still loaded as a global. I don't know much more than how to read VBA, so I used the interface to check out this issue.

    If Stillthere.dotx does not supply shortcuts, macros, a QAT, or ribbon customizations, you can avoid the problem by not loading it as a global template. If it does, users need the global Stillthere.dotx and its owner file. I found that unloading the global did not cause the owner file to close and unloading the global and then deleting the owner file did not cause problems.

    Best,
    Pam

  7. #7
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Pam

    Thank you for staying with this.

    My custom global does indeed provide macros and a custom ribbon, and I'd like to add building blocks to it as well, so my whole strategy depends on Word using this template.

    To walk through this in detail: when I open Word, my custom global appears as the AddIn, supplying the ribbon & macros - including the macro in question. Since this macro first attaches my custom global template and then attaches the normal template, I assume that the attachment "link" to my custom global is overwritten in memory and is not an issue. However, the owner file only remains if this macro runs.

    You write "unloading the global did not cause the owner file to close" - so was the macro running in another location? I mean, how can I unload my custom global when it contains the macro? One of my vba experiments apparantly did this, and Word crashed.

    How do you go about deleting the owner file - how is it addressed, simply by using the name as it appears? I wonder if I can delete it in a DocumentBeforeClose event.

    On an entirely different tack: what effect will this lingering owner file have when a number of people are using the same custom global? I am inclined to want to get rid of it from a "fear of unknown Word loose ends" - hence this thread.
    Stylus

  8. #8
    WS Lounge VIP
    Join Date
    Mar 2006
    Location
    Maryland, USA
    Posts
    690
    Thanks
    17
    Thanked 66 Times in 56 Posts
    Hi, Stylus,

    If the owner file goes away when Word closes (as it is supposed to do), there's no problem. While it's there, it prevents the file from being edited by someone other than the "owner". When Word cannot shut down gracefully, because of a power outage or operating system failure, for example, owner files get left behind. When you try to open a file, Word first looks for an owner file. If it finds one, it tells who has the document open and offers to open a copy. The presence of leftover owner files doesn't seem to affect the attachment or loading of templates, though.

    My experience is mostly with shared document templates, not shared global templates, but I think the behavior is the same. Many of my large corporate clients use project (proposal) document templates that have toolbars, keyboard shortcuts, macros and such. Five or 10 editors and formatters may be working at the same time on files that are attached to the template without problems. But when the template needs to be revised, all have to close Word—to get rid of the owner file and release the template for editing.

    It will be interesting to learn how owner files work with the team editing feature of W2010, where several people can edit a file at the same time. I haven't seen it in use yet.


    You write "unloading the global did not cause the owner file to close" - so was the macro running in another location? I mean, how can I unload my custom global when it contains the macro? One of my vba experiments apparantly did this, and Word crashed.
    When a global template is unloaded, its macros and so forth are not available to the documents. So its macros are probably not running anywhere and cannot be run. I'm hedging here because my understanding is that for a macro to run, the document or template it is in must be open (loaded into memory). If that's correct (anyone?), I can delete the "probably".


    Pam

  9. #9
    Super Moderator
    Join Date
    Jan 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    3,852
    Thanks
    4
    Thanked 259 Times in 239 Posts
    Stylus

    I can see this is really bugging you and it appears to some extent the problem is self-inflicted. I don't think MS ever intended people to use an add-in as an attached template at the same time.

    Instead of attaching the template temporarily solely for the purpose of importing styles, I recommend you explore the Style Set functionality. This 2007/2010 feature allows you to store just the style definitions as an xml file and import them via the interface. You can export a style set by going to Home>Change Styles>Style Set>Save As Quick Style Set...

    You may need to explore where you can store this file in a workgroup situation but I believe the old workgroup templates methodology is past its use-by date with so many users now using laptops which may not be LAN-connected all the time. I tend nowdays to store copies of templates locally on each hard disk and have the IT group run a log-on script to make sure the latest version is on each machine.
    Andrew Lockton, Chrysalis Design, Melbourne Australia

  10. #10
    WS Lounge VIP
    Join Date
    Mar 2006
    Location
    Maryland, USA
    Posts
    690
    Thanks
    17
    Thanked 66 Times in 56 Posts
    Stylus,

    I agree with Andrew about using style sets.

  11. #11
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Thank you both!

    Andrew, my concern has been to avoid changed/corrupted templates and styles breeding like rabbits in the brush. I've been through that, with year-old problems suddenly reappearing from the depths of someone's hard drive.

    However, after some 10 years of lurking/posting on this forum I also know to listen when you speak. Indeed, the network guys here argued for what you propose, even though neither they nor I were aware of the XML style set.

    You write that the XML file can be imported "via the interface". Could you elaborate on that? In attempting to "Save As Quick Style Set" just now I ended up with a .dotx file. Is this what you meant? I will have put on an old overcoat and sunglasses and sneak into a bookshop to buy a Word 2010 book - Oh! the ignominy! (perhaps an e-book in the privacy of my lair)

    If the XML file/log-on script strategy simplifies my life I'm all for it...

    A final thought on distributing the Word materials: yet another argument against the SharePoint-centric approach to documentation...

    Pam -

    In Word 2003 there were lots of owner files next to workgroup templates on the server. I found - then - that when upgrading a template I could get the network folks to delete those owner files, thereby releasing the template for replacement. Users were able to carry on with no interruption until they wanted to use a macro, at which point restarting Word put them back on track. I don't know if that's true for W2007/10, but since all my macros are now in my global (along with the custom Ribbon) I don't face that particular issue any more.

    <Edit - my memory deceived me, I had no macros in the WorkGroup templates. The only thing users could not access without a Word restart was NEW styles in the updated template>
    Last edited by Stylus; 2012-12-13 at 03:26.
    Stylus

  12. #12
    Super Moderator
    Join Date
    Jan 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    3,852
    Thanks
    4
    Thanked 259 Times in 239 Posts
    Stylus

    Perhaps in this case you shouldn't have listened to me. It does appear that the save as quick style set does actually save an entire template file rather than just the xml. That template file does contain a styles.xml inside it but perhaps that is not the only thing that is imported when you apply the quick styles back into a document. Applying the styles from the interface just requires you to select it from the Home>Change Styles>Style Set listing. This action can be recorded to show something like the following.

    ActiveDocument.ApplyQuickStyleSet2 "MyStyles"

    This code appears to work IF I save the styles as a Quick Style Set or I manually copy any template into the right location. The location for custom Quick Style templates is:
    %appdata%\Microsoft\QuickStyles

    Simply copying a template to this location allows it to appear and work in the quick style list although the live preview when I hover over the list item doesn't work so there may be something else saved into the template if you do this with the interface or via VBA. Code saving the template's styles as a new quick style set could be set as an automacro so the latest version of styles is always available eg.
    Code:
      Dim aDoc As Document
      WordBasic.DisableAutoMacros 1   'Disables auto macros
      Set aDoc = Documents.Add(ActiveDocument.AttachedTemplate.FullName)
      aDoc.SaveAsQuickStyleSet "New Styles"
      aDoc.Close SaveChanges:=False
      WordBasic.DisableAutoMacros 0   'Enables auto macros
      ActiveDocument.ApplyQuickStyleSet2 "New Styles"
    I understand your problem with copies of old/modified templates appearing from the archives of someone's machine but this is less of a problem than not having the template when you don't have access to the network. The logon script method of updating the templates on a local machine will certainly lead to lots of copies and the potential for old versions to be kicking around but an old version is better than no version. I include a version number in the ribbon so the user has a visual clue as to which template is currently attached - the same thing would work with your addins.

    Generally I don't try to use a document template as an addin since I don't want the overhead of the template on every file -just the ones I need the template for. Then I use the attached template. I do load an addin which provides buttons in the QAT to attach a template and create new docs based on a specific template but that is all.

    You are right on the Sharepoint approach - it is good for document management but the templates always need to be USED outside of there.
    Andrew Lockton, Chrysalis Design, Melbourne Australia

  13. #13
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Andrew,

    Thanks for these insights and the code snippet. I've been distracted, struggling with another issue (see my new thread), hence my delayed response.

    I am going to poll the Word users in the company to see how much work they do off-line. There is a lot of VPN use, so who knows. If there is very little off-line use then I will keep my current configuration for the time being.

    Meanwhile there may be a new facet to the problem I have with the Global owner file remaining after Word closes. It looks like this only happens when Word on my PC accesses the Global in my sandbox. When test users perform the same functions with their instances of Word, accessing the Global that is in the user folder (same filepath, next to my sandbox folder) there is NO lingering owner file. Puzzling, because both locations are on the server, yet it does narrow the scope of the problem...

    If I figure this out I will post.
    Stylus

  14. #14
    Super Moderator
    Join Date
    Jan 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    3,852
    Thanks
    4
    Thanked 259 Times in 239 Posts
    Does it make a difference if the template is attached before it is loaded as an addin? Do the users not have write access to the user folder?

    While you are polling the users you might want to ask how slow their access speeds are on VPN. If the template is on the server then speed may be an issue.
    Andrew Lockton, Chrysalis Design, Melbourne Australia

  15. #15
    2 Star Lounger
    Join Date
    May 2006
    Location
    Currently in Europe
    Posts
    103
    Thanks
    7
    Thanked 0 Times in 0 Posts
    Andrew,

    The macro that attaches the global, for stye updating purposes, resides in the global. The global therefore has to be added first. So the sequence is: Word opens, pulls in the Global from the location its Startup filepath points to (in this case, on the server), builds the custom ribbon, and then responds to a documentopen event by running the attach global/deattache global macro. Users do not have write access to the user folder. My own experience of using the VPN from home is that opening a document can be delayed by about 2 seconds or so: a tolerable amount. I don't know what users experience at airports & hotels...

    Meanwhile, the situation has evolved...

    We are in a transitional state in the company, where my styles and templates are being taken into use while there are lots of previous "hand made" docs floating around. These hand made docs sometimes use built in styles that have been changed. For example, the footer uses the "Footer" style, with font size changed from Normal's 11pt to 6pt.

    When the Global is attached, and the macro runs .UpdateStyles, ALL styles are updated, thereby overwriting any locally modified native styles. The macro also counts the number of custom styles in the target doc... This appears to trigger the list style "article/section" bug, causing this list style to overwrite the native heading styles. Finally, the docopen event responds to docs in protected mode (received in email, etc), yet can't see them, and so an error message is generated. The result is ugly, and my test users are up in arms...

    These issues would appear regardless of whether the custom style update happens from the server in real time or from a location on the local drive that is periodically updated.

    I have already deleted the style count which was a bit of paranoid double-checking. After all, the styles are not being "copied" so I don't see a real danger that there would be an error there. I found a solution to the protected doc invisibility conundrum on the net.

    I am going to see if your notion of dealing with a style set can limit the update to my custom styles. That will hopefully get me out of this mess.

    I appreciate your ongoing help!

    Edit: I have just experimented with your procedure (manually, not the macro) and found that I can edit a style set by selecting each non-custom style and deleting it from the style set (one at a time - can't find any way of selecting more than one). This gives me a style set with ONLY custom styles that I can name, save, and import into another document. However... My custom list styles are tied to custom MultiLevel lists... and they are not included in the Quick Set. A given list style is imported ok into a new blank doc, but since the custom multilevel list it is tied to is not in the new doc I'm unsure how it will behave, or how stable it will be.
    Last edited by Stylus; 2012-12-18 at 18:49.
    Stylus

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •