PDA

View Full Version : Challenge!! Can you solve this problem?



Anne Troy
09-29-2004, 12:41 AM
Item #1 at:

http://www.standards.com/OhMyWord/VBABugsFeatures.html#DeleteToolbar

:)

Jacob Hilderbrand
09-29-2004, 01:01 AM
I tried with Word 2002 and could not duplicate the issue.

johnske
09-29-2004, 02:16 AM
Hi Anne,

I couldn't duplicate the exact problem as described either, but I did get a duplicate once....See if this fixes it on yours (it appears it did on mine) :dunno

John :bink:

Edit: The problem appears to be that the single procedure was deleting the toolbar and then immediately adding the toolbar back in, and there was also a duplication of one piece of code. I deleted the duplication and split delete and add into two separate procedures (done on Office 2000 Premium edition)

mdmackillop
09-29-2004, 05:28 AM
Hi,
I couldn't replicate it either (Word 2000). I agree the delete and remake are too close together and this may cause the problem. Things don't always happen in "real life" as they do in stepping through a macro. I would allocate Delete Tooolbar to a DocumentOpen event in the template
MD

johnske
09-29-2004, 06:19 AM
Hi,
.....I agree the delete and remake are too close together and this may cause the problem. Things don't always happen in "real life" as they do in stepping through a macro. I would allocate Delete Tooolbar to a DocumentOpen event in the template
MD
Yep, that's definitely it! I went back in and ran the delete/remake as a single procedure again, followed instructions, and ended up with THREE toolbars. It seems that there is simply not always enough TIME for the toolbar to be successfully deleted before the code creating a new one is activated.

Even slowing it down by simply changing "debug.print" to "MsgBox" slows everything down enough for it to run correctly (without duplicated toolbars) - a simple pause or some other operation should also do the trick :bink:

TonyJollans
09-29-2004, 06:54 AM
I can replicate this (2000 w/o SP1 or SP2 at the moment).

I am not comfortable with the explanation given though. It is perfectly reasonable (and not uncommon) to delete an object (for safety's sake) before (re-)creating it and I've never heard of this happening before.

Tommy
09-29-2004, 09:46 AM
I think this is the problem.

tempORary:=False

When the tool bar is created it sets the temporary flag to false. I don't know this but Word may place the information (the toolbar) in a seperate area for permanent tollbars vs temp toolbars.

mdmackillop
09-29-2004, 10:14 AM
Hi Tony,
I had a similar problem here.
Solved: Find text in Excel workbook
My code created added a worksheet and then tried to add code to that sheet. Although it worked fine in "step through", in practice, the sheet was not added until the macro had completed, and the AddCode was "missed"
MD

Howard Kaikow
09-29-2004, 11:28 AM
Changing the timing, by splitting the code, does not always work.
Tried that many times, not always successful.

In the real applications in which I have encountered the problem, the code was not always so close together, so there's no simple timing solution.
I constructed the example to exacerbate the timing aspect.

Howard Kaikow
09-29-2004, 11:37 AM
The problem was not discovered by moi alone, a number of others also reported/confirmed the problem.

It's clearly a timing issue, Word has this worse than the other Office apps, so a "general" solution ain't so easy. Users would not be happy of macros included long wait loops.

I wonder if the problem is going to get worse when Office is .NET-ized as garbage collection is very different in .NET. Wow, think of all the new bugs we will have to investigate! Something to look forward too!

Howard Kaikow
09-29-2004, 11:40 AM
Hi,
I couldn't replicate it either (Word 2000). I agree the delete and remake are too close together and this may cause the problem. Things don't always happen in "real life" as they do in stepping through a macro. I would allocate Delete Tooolbar to a DocumentOpen event in the template
MDIn the general case that won't work as one does not always easily know WHEN the toolbar will need to be deleted.

The posted example was constructed to exacerbate the problem.

TonyJollans
09-29-2004, 11:56 AM
May not be relevant but, in playing with this, I ended up at one point with three copies of the toolbar - all invisible. I deleted them all through Tools > Customize and closed Word and restarted and they were all still there.

mdmackillop
09-29-2004, 11:56 AM
Sorry, should have said DocumentClose event.
MD

Howard Kaikow
09-29-2004, 12:00 PM
May not be relevant but, in playing with this, I ended up at one point with three copies of the toolbar - all invisible. I deleted them all through Tools > Customize and closed Word and restarted and they were all still there.
Ayup, that is also how I encountered the problem several years ago.

Howard Kaikow
09-29-2004, 12:06 PM
I think this is the problem.

tempORary:=False

When the tool bar is created it sets the temporary flag to false. I don't know this but Word may place the information (the toolbar) in a seperate area for permanent tollbars vs temp toolbars.

My recollection is that I had tested that hypothesis several years ago.

TonyJollans
09-29-2004, 12:12 PM
Temporary = False is the default so explicitly specifying it shouldn't make any difference. If memory serves, there used to be a problem with Temporary=True not working properly, but I think that's now fixed.

Tommy
09-29-2004, 12:20 PM
I tested and got 5+ commandbars. I saved changes. I opened Normal.dot and deleted the commandbars. I then changed the Temporary = False to Temporary = True. I now do not get duplicates of the commandbars I just get 1. What am I missing?

Anne Troy
09-29-2004, 12:25 PM
Hey, Tommy. Just to be clear, in which version are you testing?

Howard Kaikow
09-29-2004, 12:30 PM
Temporary = False is the default so explicitly specifying it shouldn't make any difference. If memory serves, there used to be a problem with Temporary=True not working properly, but I think that's now fixed.I sometimes specify certain defaults as that makes the code clearer.

In addition, specifying the defaults eliminates bugs due to MSFT changing defaults from version to version, rarely done, but it'd cheap protection.

TonyJollans
09-29-2004, 12:32 PM
Howard,

MS Bugs - surely not!!
Tommy,

Temporary=True, if it works, means that the toolbars never get saved, no matter how many there are

johnske
09-29-2004, 12:33 PM
May not be relevant but, in playing with this, I ended up at one point with three copies of the toolbar - all invisible. I deleted them all through Tools > Customize and closed Word and restarted and they were all still there.Had the same thing...I still think the problem is timing, but exacerbated by the fact that there is actually no macro/module in the workbook being used. The macro is in the template and is being referenced by the workbook and what happens in one is not neccessarily being duplicated in the other at the same time (this is instanced by the fact that you can rename, change, and save, the workbook but on exiting the book you will then be asked if you want to save the template) :bink:

Howard Kaikow
09-29-2004, 12:39 PM
I tested and got 5+ commandbars. I saved changes. I opened Normal.dot and deleted the commandbars. I then changed the Temporary = False to Temporary = True. I now do not get duplicates of the commandbars I just get 1. What am I missing?The behavior you see is going to vary from version to version.
And, as I point out in the code comments, the problem does not occur every time the code is run.

Note that I've NEVER seen the problem with Word 97, so sumptin changed in Word 2000 and beyond.

Of course, until about a year ago, I was running Office 97 in Win 98, the other versions of Office in Win 2000, so the OS could also be a factor. Maybe the problem will now be seen in Word 97 under Win 2000? Next time I boot to the system with Word 97, I'll try to remember to test, but that may not occur for a looong time.

In the original app in which I found the problem I was indeed using Temporary=False The example uses Temporary=False to emphasize the problem. After all, a tempory toolbar should vanish on its own anyway.

Tommy
09-29-2004, 12:40 PM
The one at the site that was posted above. I did not download the one John posted.
I am using Word 2000 9.0.6926 with SP 3. Win98, IE 6 SP1 with all updates installed.


Public Sub DeleteToolbars()
Dim intBeforeIndex As Integer
Dim cmdbar As CommandBar
Dim cmdbutton As CommandBarButton
Const strToolbar As String = "Double Vision HK VBA"
' CustomizationContext = MacroContainer
CustomizationContext = NormalTemplate
On Error Resume Next
CommandBars(strToolbar).Delete
If Err.Number = 0 Then
Debug.Print "Toolbar deleted"
Else
Debug.Print "Toolbar NOT deleted"
End If
On Error GoTo 0

On Error Resume Next
CommandBars(strToolbar).Delete
On Error GoTo 0
Set cmdbar = CommandBars.Add(Name:=strToolbar, Position:=msoBarTop, Temporary:=True, MenuBar:=False) '<-- the line I changed
cmdbar.Visible = True
Set cmdbar = CommandBars(strToolbar)

intBeforeIndex = 1
Set cmdbutton = cmdbar.Controls.Add(Type:=msoControlButton, Temporary:=False, Before:=intBeforeIndex)
With cmdbutton
.Style = msoButtonCaption
' Use whatever you need in next line to avoid compile errors.
.OnAction = "modReplaceStringNames.ReplaceStringNames"
.Caption = "String Names"
End With
End Sub



Thing is I did change the temp back to false and was able to reduplicate it. On the commandbar I noticed a funny thing when I looked at the code I saw this tempORary:=False I changed it to true and it went to this Temporary:=True :confused: go figure.

Howard Kaikow
09-29-2004, 12:41 PM
Had the same thing...I still think the problem is timing, but exacerbated by the fact that there is actually no macro/module in the workbook being used. The macro is in the template and is being referenced by the workbook and what happens in one is not neccessarily being duplicated in the other at the same time (this is instanced by the fact that you can rename, change, and save, the workbook but on exiting the book you will then be asked if you want to save the template) :bink:
We need to stick to Word in this thread, Excel is usually not as misbehaving as Word.

johnske
09-29-2004, 12:48 PM
Sorry - I meant Doc of course

Tommy
09-29-2004, 12:53 PM
Another funny, while testing I had a commandbar set to false and a command button set to true. I changed the commandbar to true, reran the code and when I reopened Word it had 2 buttons on the commandbar.

Howard Kaikow
09-29-2004, 12:54 PM
To simplify discussionm do not use Temporary=True.

Temporary=False must be used as the intent of the original app was to replace an extant toolbar.

The easiest way was to delete and recreate the toolbar.
That's when I encountered the problem.

Howard Kaikow
09-29-2004, 12:57 PM
Another funny, while testing I had a commandbar set to false and a command button set to true. I changed the commandbar to true, reran the code and when I reopened Word it had 2 buttons on the commandbar.
I've also seen that behavior, but I didn't want to complicate the example.

Hey, it's almost 16:00 and I've had no food or drink since about 03:00.
Is VBAExpress hazardous to my health?

Anne Troy
09-29-2004, 01:01 PM
If so, Howard, you need only refresh yourself in the arcade (http://www.vbaexpress.com/forum/arcade.php?).

johnske
09-29-2004, 02:13 PM
....timing, but exacerbated by the fact that there is actually no macro/module in the (DOC) being used. The macro is in the template and is being referenced by the (DOC) and what happens in one is not neccessarily being duplicated in the other at the same time.... :bink:Re: My last post (quoted above) anyone else wanna try this?
1) export the module from the template
2) move the template to the recycle bin
3) now import the module into the document
4) goto tools/references and untick any reference to the template
5) disable CustomizationContext = NormalTemplate by putting an apostrophe in front of it
6) save...
Now run the macro (delete & instant remake) and see if you get any duplications

I did and couldn't get any....:dunno :bink:

TonyJollans
09-29-2004, 04:10 PM
This is very interesting.

My suspicion is that it is somehow related to the customization context - customizing one template from another seems to be flawed,

1. Make sure Word is closed
2. Double click on the DoubleVision template to create a new document based on it
3. Run the macro - from Word, not the VBE
4. The toolbar is NOT added to Normal

I have done this several times and never get the toolbar

5. Now, click on the New icon open a new document based on Normal
6. Go back to the document based on doubleVison
7. Run the macro again, from Word
8. This time I get a toolbar

I have repeated this several times, again with consistent results.

(edited to add this comment - and the related amendments above)
A bit more testing shows this behaviour only to happen when the macro is run via Alt+F8 from Word - it does not happen when run from within the VBE

Howard Kaikow
09-29-2004, 04:16 PM
Re: My last post (quoted above) anyone else wanna try this?
1) export the module from the template
2) move the template to the recycle bin
3) now import the module into the document
4) goto tools/references and untick any reference to the template
5) disable CustomizationContext = NormalTemplate by putting an apostrophe in front of it
6) save...
Now run the macro (delete & instant remake) and see if you get any duplications

I did and couldn't get any....:dunno :bink:
Is not your code using Temporary=True?
If so, that ignores the problem, and is not a solution.

Howard Kaikow
09-29-2004, 04:22 PM
This is very interesting.

My suspicion is that it is somehow related to the customization context - customizing one template from another seems to be flawed,

1. Make sure Word is closed
2. Double click on the DoubleVision template to create a new document based on it
3. Run the macro - from Word, not the VBE
4. The toolbar is NOT added to Normal

I have done this several times and never get the toolbar

5. Now, click on the New icon open a new document based on Normal
6. Go back to the document based on doubleVison
7. Run the macro again, from Word
8. This time I get a toolbar

I have repeated this several times, again with consistent results.

(edited to add this comment - and the related amendments above)
A bit more testing shows this behaviour only to happen when the macro is run via Alt+F8 from Word - it does not happen when run from within the VBE
CustimizationContext is precisely intended for this purpose.
However, would not astonish me if there were a "bug"/"feature" depending on HOW the code was run.

I'll try your experiment a bit later.

johnske
09-29-2004, 04:22 PM
Is not your code using Temporary=True?
If so, that ignores the problem, and is not a solution.
Sorry, nope...I'm using Temporary=False :bink:

Howard Kaikow
09-29-2004, 04:23 PM
If so, Howard, you need only refresh yourself in the arcade (http://www.vbaexpress.com/forum/arcade.php?).I have not played a computer game in over a year.
I've overcome the addiction!

Anne Troy
09-29-2004, 04:24 PM
This just gets more and more interesting.
The peanut gallery is *in attendance*!
:bore

TonyJollans
09-29-2004, 04:52 PM
Best to ignore my last post until I am sure I report what I actually did. It's late here is the only excuse I have. :dunno

It is still interesting.

Howard Kaikow
09-29-2004, 06:12 PM
Best to ignore my last post until I am sure I report what I actually did. It's late here is the only excuse I have. :dunno

It is still interesting.


I;ve got about a 2 hour window in which to play.

I'm gonna start over and document EVERY step.
Let's see what happens.

Anne Troy
09-29-2004, 06:13 PM
LOL, Howard. I hope Tony is in bed by now. He's in the UK. :)
johnske is down under.

johnske
09-29-2004, 07:15 PM
Hi Howard,

Inconsistent little beggar aint it?...Went back to your original code and converted it from "Template" to "Normal" and it came back!!!

Have a look at this attachment, it's in "Normal" with some of your error-handling procedure disabled being the only difference and - for whatever reason - it gives the right results every time.

But remember that the toolbar(s) are added to ALL your word docs when you add it to one doc, so goto view/toolbars and delete all occurrences of the toolbar before running this...You then only get one toolbar every time :bink:

Howard Kaikow
09-29-2004, 08:07 PM
LOL, Howard. I hope Tony is in bed by now. He's in the UK. :)
johnske is down under.Well, here's something they can read when they awaken.

I added an additional .zip at the same URL.

The following are my notes from the past 2 hours or so.
I renamed things in the new .zip.

1. Cleared read-only attribute for Normal.dot.
2. Double-clicked on HowardKaikowDoubleVision.dot.
3. Ran DeleteToolbars macro from Tools | Macros menu in Word GUI, not from VBIDE.
4. Exited from Word.
5. Started Word using Word icon on task bar.
6. "String Names" toolbar was present.
7. Exited Word.
8. Double-clicked on HowardKaikowDoubleVision.dot.
9. Ran DeleteToolbars macro from Tools | Macros menu in Word GUI, not from VBIDE.
10. Exited from Word.
11. Started Word using Word icon on task bar.
12. An additional "String Names" toolbar was present.
At this point, I noticed something I had forgotten about.
Likely rather significant
13. Exit from Word
14. As Word was exiting, one of the toolbars (the leftmost) disappeared and the other remained.
15. When I next opened Word using the icon on the task bar, the second "String Names" toolbar re-appeared AND,
likely significant, both toolpars moved one position to the right.
16. Each time steps 13-15 were repeated, both toolbars appeared AND were shifted one position to the right EACH time!
17. Looking at the toolbars listed for the Normal template in Tools | Macros Organizer, TWO tooolbars are listed with the SAME name. Obviously the names cannot be the same, so something is amiss.

18. I then added code to the DeleteToolbar macro to list the toolbars.
19. I changed the file name to HowardKaikowDoubleVision-Revised.dot.
20. Went back to a copy of the Normal template from before step 1 supra.
21. Repeated steps 1-16 supra. Same behavior.

Next
21. Went back to a copy of the Normal template from before step 1 supra.
22. Set read-only attribute for Normal.dot.
23. Added code to work on MacroContainer, instead of Normal template and then
double-clicked on HowardKaikowDoubleVision-Revised.dot.
24. Ran WorkWithMacroContainer macro from Tools | Macros menu in Word GUI, not from VBIDE.
25. Exited from Word.
26. Double-clicked on HowardKaikowDoubleVision-Revised.dot.
27. "String Names" toolbar was present BUT caption was empty!
28. Exited Word.
29. Double-clicked on HowardKaikowDoubleVision-Revised.dot.
30. Ran WorkWithMacroContainer macro from Tools | Macros menu in Word GUI, not from VBIDE.
31. Msgbox showed that there were two toolbars!
32. Exited from Word.
33. Double-clicked on HowardKaikowDoubleVision-Revised.dot.
34. An additional "String Names" toolbar was present, both had empty captions.
35. Exited from Word.
36. Repeatedly, double-clicked on HowardKaikowDoubleVision-Revised.dot and exited Word.
37. Each time, the two empty captioned toolbars were present, however, unlike the case with the Normal template, they did not shift position.

johnske
09-29-2004, 09:11 PM
OK Howard, here's something else very strange for you to ponder on:- I ran the following modification of your code inserted into a module of a "normal" word doc 23 times (typing something and saving each time) without a single recurrence of 'multiple toolbars'. :)

Then, I went into VB edit and changed a comment slightly, saved it, exited and then re-opened the doc. There were then two toolbars present...on deleting these through view/toolbars/delete there were no more problems.

Next, I went back into VB edit and changed the comments again....SAME THING! Every time something is changed in the module the problem re-appears, but if nothing is changed in the module...NO problems :p :wot

John :bink:


Option Explicit
Public Sub DeleteToolbars()
Dim intBeforeIndex As Integer
Dim cmdbar As CommandBar
Dim cmdbutton As CommandBarButton
Const strToolbar As String = "Double Vision HK VBA"
' CustomizationContext = MacroContainer
'CustomizationContext = NormalTemplate

On Error Resume Next '//all that's really needed
CommandBars(strToolbar).Delete

'//the rest of the error handling procedure is superfluous as the
'//only error you should get is the one from attempting to delete
'//a non-existent toolbar. The 1st "On Error Resume Next" then shifts
'//the procedure to the code below - i.e. to creating a toolbar.

Set cmdbar = CommandBars.Add(Name:=strToolbar, Position:=msoBarTop, Temporary:=False, MenuBar:=False)
cmdbar.Visible = True
Set cmdbar = CommandBars(strToolbar)


intBeforeIndex = 1
Set cmdbutton = cmdbar.Controls.Add(Type:=msoControlButton, Temporary:=False, Before:=intBeforeIndex)
With cmdbutton
.Style = msoButtonCaption
' Use whatever you need in next line to avoid compile errors.
.OnAction = "modReplaceStringNames.ReplaceStringNames"
.Caption = "String Names"
End With
End Sub

johnske
09-29-2004, 10:46 PM
Howard, (from my previous) here's what appears to be the sequence of events when any of the code is changed: :)

(Change = any change made in the code/comments)

i) Change/Save/Exit/Open always gives you ONE toolbar

ii) Change/Save/RUN/Exit/Open gives you either one or two toolbars

iii) Change/RUN/Save/Exit/Open always you TWO toolbars

??? It almost seems in the last case that there appears to be two versions of the doc co-existing momentarily in the memory if the macro is run before exiting the first time, the original and the changed one, so the toolbar is shown twice - one for each version ???? :bink:

Edit: PS ...I know you've stated the following "Temporary=False must be used as the intent of the original app was to replace an extant toolbar. The easiest way was to delete and recreate the toolbar. That's when I encountered the problem."....

But after all this I still fail to see the reason why one would want to delete & replace a toolbar that already exists...also, as others have already stated, the problem simply doesn't arise when you put Temporary = True ?

Or, as MD suggested, wouldn't it be simpler to maybe put the "delete" and/or "create" as 'DocumentOpen' and 'DocumentClose' events or t'other way round? :confused:

johnske
09-30-2004, 12:24 AM
OF COURSE! THAT'S IT...(reading my last 2 posts)...If we make the procedure an Open event, any changes to the code can't be run until the document is saved and re-opened.

Copy and paste the following code into "ThisDocument", save it, exit and open...


Option Explicit
Private Sub Document_Open()

Dim intBeforeIndex As Integer
Dim cmdbar As CommandBar
Dim cmdbutton As CommandBarButton
Const strToolbar As String = "Double Vision HK VBA"

On Error Resume Next
CommandBars(strToolbar).Delete

Set cmdbar = CommandBars.Add(Name:=strToolbar, Position:=msoBarTop, Temporary:=False, MenuBar:=False)
cmdbar.Visible = True
Set cmdbar = CommandBars(strToolbar)

intBeforeIndex = 1
Set cmdbutton = cmdbar.Controls.Add(Type:=msoControlButton, Temporary:=False, Before:=intBeforeIndex)
With cmdbutton
.Style = msoButtonCaption
.OnAction = "modReplaceStringNames.ReplaceStringNames"
.Caption = "String Names"
End With
End Sub


Hopefully we can mark this solvered now :bink:

Howard Kaikow
09-30-2004, 02:18 AM
OF COURSE! THAT'S IT...(reading my last 2 posts)...If we make the procedure an Open event, any changes to the code can't be run until the document is saved and re-opened.

Copy and paste the following code into "ThisDocument", save it, exit and open...


Option Explicit
Private Sub Document_Open()

Dim intBeforeIndex As Integer
Dim cmdbar As CommandBar
Dim cmdbutton As CommandBarButton
Const strToolbar As String = "Double Vision HK VBA"

On Error Resume Next
CommandBars(strToolbar).Delete

Set cmdbar = CommandBars.Add(Name:=strToolbar, Position:=msoBarTop, Temporary:=False, MenuBar:=False)
cmdbar.Visible = True
Set cmdbar = CommandBars(strToolbar)

intBeforeIndex = 1
Set cmdbutton = cmdbar.Controls.Add(Type:=msoControlButton, Temporary:=False, Before:=intBeforeIndex)
With cmdbutton
.Style = msoButtonCaption
.OnAction = "modReplaceStringNames.ReplaceStringNames"
.Caption = "String Names"
End With
End Sub


Hopefully we can mark this solvered now :bink:
Not yet. That is not the problem I posed.
The example I posted is a simplified example of a more general case.

The code cannot be in Document_Open because it is not known at that time that the toolbar will be modified or deleted. The code to replace the toolbar might be run at any time, or not at all.

And CustomizationContext must be used.

A few minutes ago, I posed a further simplified example in CombinedHowardKaikowDoubleVision.zip at the same link.

TonyJollans
09-30-2004, 03:01 AM
My apologies if I misled anyone with my post last night. At least some of the time, and probably all of the time, when nothing happened it was bacuase I had run the wrong code. I just got too excited :rofl



Hopefully we can mark this solvered now :bink:

I don't see how this is solved by showing that something different works. The question as to why the original fails remains open.

I will play with this over the day to see if I can distill anything from it. Of course this is old and greater minds than mine have, presumably, been applied to it. but I'm not one to let something like that get in the way of making a fool of myself.

One thing I did was add a check for the command bar's existence, by looping through the collection, at various points in the code and it was always shown as expected (i.e not there after a delete, there after a create). Despite that I still got two toolbars. I will try checking the collection for duplicates later.

It seems as though it's something that happens when Normal is saved. I thought perhaps there was an extra copy of an object lying around so made sure all object variables were set to nothing but it made no difference. I removed the "Set cmdbar .." line because it seemed redundant but that made no difference either.

I'll check out the latest code at Howards's site and I might try playing with the CommandBars Update Event although I've found that to be a pain in the past as it gets invioked so often.

johnske
09-30-2004, 04:19 AM
[QUOTE=Howard Kaikow]Not yet. That is not the problem I posed.....

The code cannot be in Document_Open because it is not known at that time that the toolbar will be modified or deleted. The code to replace the toolbar might be run at any time, or not at all.

And CustomizationContext must be used....
QUOTE]

i) Re-insert "CustomizationContext = NormalTemplate" if you like - you'll find that it still works...

ii) Apart from that, I just trimmed it up for posting by removing comments and some extraneous error procedures - the code is exactly the same as in your original...

ii) If you read carefully, the problem I found was that the double tool-bars appeared if ANY changes were made to the code, so you must not run the code before the book was saved, exited and re-opened. If you simply follow that simple constraint there is no problems. (The Open event was simply introduced to counter anyone's tendency to run the code before saving and exiting)

I also saved this as a MS word template and ran it - no probs. there either :dunno

John :bink:

johnske
09-30-2004, 05:53 AM
Hi Howard,

Firstly, open a word doc on your computer, goto view/toolbars and delete any existing references to Double Vision HK VBA.

Now download the attached word template, open it, save it as a word doc, then open the doc and run the macro as many times as you like and try to get a duplicate toolbar - does this or does this not do exactly what you want it to (delete and re-make a singletoolbar when the macro is run)?

AFTER you're satisfied, have a look at the code (it's locked for viewing but the password is "Howard") - just remember that if you change any of the code don't be tempted to run it until AFTER you have saved and exited the doc....

John :bink:

Howard Kaikow
09-30-2004, 12:00 PM
My apologies if I misled anyone with my post last night. At least some of the time, and probably all of the time, when nothing happened it was bacuase I had run the wrong code. I just got too excited :rofl


I don't see how this is solved by showing that something different works. The question as to why the original fails remains open.

I will play with this over the day to see if I can distill anything from it. Of course this is old and greater minds than mine have, presumably, been applied to it. but I'm not one to let something like that get in the way of making a fool of myself.

One thing I did was add a check for the command bar's existence, by looping through the collection, at various points in the code and it was always shown as expected (i.e not there after a delete, there after a create). Despite that I still got two toolbars. I will try checking the collection for duplicates later.

It seems as though it's something that happens when Normal is saved. I thought perhaps there was an extra copy of an object lying around so made sure all object variables were set to nothing but it made no difference. I removed the "Set cmdbar .." line because it seemed redundant but that made no difference either.

I'll check out the latest code at Howards's site and I might try playing with the CommandBars Update Event although I've found that to be a pain in the past as it gets invioked so often.
Please put off further analysis of my updated posted code.

I may have found a SOLUTION, at least for the case that puts the toolbar in the MacroContainer template. Not yet tested for the Normal template.

If I indeed did find a solution, then I gotta figure out why.

My schedule for today, as I just woke up about an hour ago:

1. Eat (one of my all too favorite activities).
2. Test some more.
3. Exercise (have not done so since Sunday!).
4. Eat again!
5. If necessary, and time permitting, test/analyze some more.
6. Watch presidential candidate debate.
7. Watch silly news analysts discuss debate.
8. If necessary, test/analyze some more.
9. Post result.

If I have found the solution, the cause, at this time, is not very obvious.
I might test in Word 97, Word 2000, Word 2002 and Word 2003 BEFORE I might believe the solution.

mdmackillop
09-30-2004, 01:20 PM
Can I suggest

5.1 Large glass of Lagavulin malt whisky

6.1 Even larger glass of Lagavulin malt whisky

Anne Troy
09-30-2004, 01:27 PM
MD: Do you think Howard should INSERT those steps? Or REPLACE them?

mdmackillop
09-30-2004, 01:45 PM
To carry out steps 6 and 7, I consider 5.1 and 6.1 a prerequisite!

Anne Troy
09-30-2004, 01:51 PM
Oh!!

I thought the 1 and the 1 were ONE. i.e.:

5. One Large glass of Lagavulin malt whisky

6. One Even larger glass of Lagavulin malt whisky

and I wondered why you were limiting him... ROFL!!

mdmackillop
09-30-2004, 02:56 PM
Maybe limits are required, after all, there may be some testing and analysing to be done. Wouldn't want him ROF :drunkard:

Howard Kaikow
09-30-2004, 02:59 PM
Can I suggest

5.1 Large glass of Lagavulin malt whisky

6.1 Even larger glass of Lagavulin malt whisky
I am not allowed to drink alcoholic beverages.

Howard Kaikow
09-30-2004, 03:01 PM
Item #1 at:

http://www.standards.com/OhMyWord/VBABugsFeatures.html#DeleteToolbar

:)
I've added a second link to a .zip file.
That link will contain my latest testing version.

mdmackillop
09-30-2004, 03:13 PM
I sympathise; I don't think politicians should be taken without one, but maybe a large pinch of salt would do.

Howard Kaikow
09-30-2004, 03:21 PM
Please put off further analysis of my updated posted code.

I may have found a SOLUTION, at least for the case that puts the toolbar in the MacroContainer template. Not yet tested for the Normal template.

If I indeed did find a solution, then I gotta figure out why.

My schedule for today, as I just woke up about an hour ago:

1. Eat (one of my all too favorite activities).
2. Test some more.
3. Exercise (have not done so since Sunday!).
4. Eat again!
5. If necessary, and time permitting, test/analyze some more.
6. Watch presidential candidate debate.
7. Watch silly news analysts discuss debate.
8. If necessary, test/analyze some more.
9. Post result.

If I have found the solution, the cause, at this time, is not very obvious.
I might test in Word 97, Word 2000, Word 2002 and Word 2003 BEFORE I might believe the solution.I have done steps 1 and 2, and part of 3, i.e., I've put on sweatsocks and exercise shoes.

I added a link at the original URL to a 2nd .zip file that greatly simplifies the code and helps isolate what may be the problem.

A common sub is used for all processing. The only difference is whether it is passed MacroContainer or NormalTemplate.

So far, the code seems to work as desired using MacroContainer, but not with NormalTemplate.

I have not yet investigated whether it would make any difference if the code were put in the NormalTemplate, in which case, there should be no difference between using MacroContainer or NormalTemplate for those cases in which I want the toolbar in the Normal Template. I would rarely desire this as I run with Normal template as read-only except when I need to do some testing or modifications. Anyway, application specific stuff should be in app specific templates.

Running in Word 2003, the current code seems to work for MacroContainer, but not for NormalTemplate.

Ditto for Word 97 and Word 2000.

For Word 97, I had to add error handling in the output sub because it didn't like the Parent property, I've not investigated why.

For Word 2000, I had to run a few times before the case using NormalTemplate failed. Similar to what I found 3+ years ago.

Did not bother to try in Word 2002.

Further pounding will determine whether the MacroContainer case really works.

Obviously, there's an oddity with NormalTemplate as the problem does not surface immediately in Word 2000, but does in other versions.

I'm not sure what can be done to further simplify the code, remembering that CustomizationContext must be used.

I started to fool around with using OpenAsDocument, instead of using CustomizationContext, but that seemed to always store the toolbar in the NormalTemplate.

Howard Kaikow
09-30-2004, 03:35 PM
I sympathise; I don't think politicians should be taken without one, but maybe a large pinch of salt would do.Up until about 2 weeks ago, I had not had ANY salt, other than the salt already in food, in my house for more than 10 years.

On 13 September 2004, I had oral surgery and the dentist wanted me to use a rinse of salt water and hydrogen peroxide. I purchased salt, but instead decided to use Peroxyl from Colgate-Palmolive. Let's see how many years I go without opening the box of salt!

If I can tolerate oral surgery, I sure can tolerate the debate.

Oh well, 'nuff fer now, gotta stretch, then exercise, then ...

johnske
09-30-2004, 03:38 PM
I note you have not bothered to download my last attachment :bawl

If you had, you would find that it's YOUR OWN original post from your URL, it's just been re-named and locked for viewing... :rolleyes:

As I've stated, it runs perfectly IF you leave the code alone - you get two tool-bars IMMEDIATELY on re-open if you run any changes to the code or the comments before saving and quitting.

Obviously this is a MS bug that needs to be looked at by microsoft :bore

John :bink: :hi:

Anne Troy
09-30-2004, 03:43 PM
LOL. Before this thing is closed up and neatly put away, I'll knock out some of the off-topic comments. :)

Howard Kaikow
09-30-2004, 04:18 PM
I have done steps 1 and 2, and part of 3, i.e., I've put on sweatsocks and exercise shoes.

I added a link at the original URL to a 2nd .zip file that greatly simplifies the code and helps isolate what may be the problem.

A common sub is used for all processing. The only difference is whether it is passed MacroContainer or NormalTemplate.

So far, the code seems to work as desired using MacroContainer, but not with NormalTemplate.

I have not yet investigated whether it would make any difference if the code were put in the NormalTemplate, in which case, there should be no difference between using MacroContainer or NormalTemplate for those cases in which I want the toolbar in the Normal Template. I would rarely desire this as I run with Normal template as read-only except when I need to do some testing or modifications. Anyway, application specific stuff should be in app specific templates.

Running in Word 2003, the current code seems to work for MacroContainer, but not for NormalTemplate.

Ditto for Word 97 and Word 2000.

For Word 97, I had to add error handling in the output sub because it didn't like the Parent property, I've not investigated why.

For Word 2000, I had to run a few times before the case using NormalTemplate failed. Similar to what I found 3+ years ago.

Did not bother to try in Word 2002.

Further pounding will determine whether the MacroContainer case really works.

Obviously, there's an oddity with NormalTemplate as the problem does not surface immediately in Word 2000, but does in other versions.

I'm not sure what can be done to further simplify the code, remembering that CustomizationContext must be used.

I started to fool around with using OpenAsDocument, instead of using CustomizationContext, but that seemed to always store the toolbar in the NormalTemplate.I forgot to mention that I added a toolbar to the template to make it easier to run the code.

One button sets the target as MacroContainer, the other as Normaltemplate.

johnske
09-30-2004, 04:19 PM
Fine by me Anne,

I've shown how the error can be unerringly provoked and (if you include the open event) two different ways to step around it. I really don't see what else can be done...

Regards,
John :bink:

Howard Kaikow
09-30-2004, 04:36 PM
I note you have not bothered to download my last attachment :bawl

If you had, you would find that it's YOUR OWN original post from your URL, it's just been re-named and locked for viewing... :rolleyes:

As I've stated, it runs perfectly IF you leave the code alone - you get two tool-bars IMMEDIATELY on re-open if you run any changes to the code or the comments before saving and quitting.

Obviously this is a MS bug that needs to be looked at by microsoft :bore

John :bink: :hi:
Thanx for verifying the error that I had described.
Since I already had my own code, I did not feel that I needed to download code you stated was identical.

MSFT likely does not consider this a bug, it is more likely considered a "feature", the question is how to consistently live with the feature in each Word version.

I think I reported the problem to MSFT 3+ years ago. If not, it's been raised often enough in the various MSFT newsgroups, somebody from MSFT must have heard of this.

Not clear whether MSFT would fix this "feature" if it is inherent in VBA.

The way to get their attention is likely to reproduce the problem using Word in VSTO, since I think the toolbars in VSTO are still VBA, not .NET. I've not yet checked out this option.

johnske
10-01-2004, 04:05 AM
Hi Howard,

If you insert something like this as the first line of your code it will stop the double toolbars appearing if someone fiddles with the code...(or if you forget to exit after making a change) - It can always be removed later when you finalise it and lock your project for viewing :D


If ThisDocument.VBProject.Saved = False Then
MsgBox "This document will now be closed - You" & vbLf & _
"must open it again to run your new code"
Application.Quit
End If


Regards,
John :bink:

Tommy
10-01-2004, 06:24 AM
I think part of the problem is the buttons are not being deleted from the commandbar before the commandbar is deleted. It could be causing a memory leak and brain cramp. :)


When I run the revised code I get a Error 5852 which is a mailmerge error?

Howard Kaikow
10-01-2004, 07:02 AM
Hi Howard,

If you insert something like this as the first line of your code it will stop the double toolbars appearing if someone fiddles with the code...(or if you forget to exit after making a change) - It can always be removed later when you finalise it and lock your project for viewing :D


If ThisDocument.VBProject.Saved = False Then
MsgBox "This document will now be closed - You" & vbLf & _
"must open it again to run your new code"
Application.Quit
End If


Regards,
John :bink:
I believe this is addressing a different problem than the one I posed.

Howard Kaikow
10-01-2004, 07:05 AM
I think part of the problem is the buttons are not being deleted from the commandbar before the commandbar is deleted. It could be causing a memory leak and brain cramp. :)


When I run the revised code I get a Error 5852 which is a mailmerge error?
Which Sub are you running, there are two?
Which version of Word?
Which OS?

johnske
10-01-2004, 07:06 AM
IGNORE THIS POST!!!


Hi Howard,

If you insert something like this as the first line of your code it will stop the double toolbars appearing if someone fiddles with the code...(or if you forget to exit after making a change) - It can always be removed later when you finalise it and lock your project for viewing :D


If ThisDocument.VBProject.Saved = False Then
MsgBox "This document will now be closed - You" & vbLf & _
"must open it again to run your new code"
Application.Quit
End If


Regards,
John :bink:
Theoretically, it should solve the problem, but when I actually tried it on a copy that had previously been extremely well behaved it actually INVOKED the problem even though I saved and quit without running the code.

After removing the above code everything went back to being well behaved again - the "save changes and quit before running" only works when it is done MANUALLY????

Go figure THAT one :dunno :dunno :dunno

Tommy
10-01-2004, 07:19 AM
Originally Posted by Howard Kaikow

Which Sub are you running, there are two?
Which version of Word?
Which OS?

Which Sub are you running, there are two? <- TestCustomizationContextMacroContainer
Which version of Word? <- Word 2000 9.0.6926 with SP 3
Which OS? <- Win98, IE 6 SP1 with all updates installed

I also have VS 6.0 SP6 installed Mdac 2.8 and the JEt 4.0

johnske
10-01-2004, 08:16 AM
I believe this is addressing a different problem than the one I posed.
Pardon? I thought the problem was:

Quote (from your comments in the original file posted on your URL):- :)
"Test failure to delete toolbar in Word 9. Although the macro appears to delete the toolbar. When Word is exited and then restarted, there are two instances of the toolbar. Note that the following sequence has to be executed 2 or 3 times before problem occurs"

I have shown how the problem can be unfailingly invoked, not every 2 or 3 times, but EVERY single time the sequence is executed and I have shown how the problem will NEVER occur if a manual sequence of events is followed...(at least on MY computer - Win98SE, Office 2000)...i.e. There is no "Test failure to delete" when this manual procedure is followed.

I completely fail to see how attempting to AUTOMATE the manual sequence of events that avoids "two instances of the toolbar" is addressing a different problem....If that was not the problem :dunno :dunno ...I really DO give up now :bink: :hi:

Howard Kaikow
10-01-2004, 12:04 PM
Pardon? I thought the problem was:

Quote (from your comments in the original file posted on your URL):- :)
"Test failure to delete toolbar in Word 9. Although the macro appears to delete the toolbar. When Word is exited and then restarted, there are two instances of the toolbar. Note that the following sequence has to be executed 2 or 3 times before problem occurs"

I have shown how the problem can be unfailingly invoked, not every 2 or 3 times, but EVERY single time the sequence is executed and I have shown how the problem will NEVER occur if a manual sequence of events is followed...(at least on MY computer - Win98SE, Office 2000)...i.e. There is no "Test failure to delete" when this manual procedure is followed.

I completely fail to see how attempting to AUTOMATE the manual sequence of events that avoids "two instances of the toolbar" is addressing a different problem....If that was not the problem :dunno :dunno ...I really DO give up now :bink: :hi:
It's my fault for not being clearer.

I made the example very simple to force the problem to more easily occur.

In a real app, one might have something like the following.

I distribute a template that installs an app on a user's system.
The installation code allows the user to set up toolbar in various ways, e.g., to choose whether to locate the toolbar in Normal or another template.
An option might be presented that causes no change to an extant toolbar.

So, in most general case, one cannot do the deed in document_open.
Sorry for not being as clear as I could have been.

Howard Kaikow
10-01-2004, 12:13 PM
Which Sub are you running, there are two? <- TestCustomizationContextMacroContainer
Which version of Word? <- Word 2000 9.0.6926 with SP 3
Which OS? <- Win98, IE 6 SP1 with all updates installed

I also have VS 6.0 SP6 installed Mdac 2.8 and the JEt 4.0I booted to my system with Word 2000.
I have the same version of Word, but I am using Win 2000.
I get no error 5852 using TestCustomizationContextMacroContainer.

Actually, there's nothing in the code that should cause any error, especially a "mailmerge" error. That type of weirdness is usually caused by a 3rd party macro/add-in interfering, Usually something like Acrobat or auntie virus software or your guess is at least as good as mine.

The code itself is actually fairly simple, just that there is some bug/feature in Word of which we are not yet aware.

TonyJollans
10-01-2004, 12:43 PM
I've just been playing (for that is what it is, isn't it?)

I thought perhaps if I renamed the toolbars I might avoid the problem and got rather a surprise. Of course, Howard, as you've been playing with it for years you probably already know this.


I added a global integer to the module
Before deleting, I renamed the existing toolbar as "Deleted #" (where # was my global integer incremented every time)
So I never, at any time, had more than one toolbar with the same name
I ran the code (a few times) and closed Word
On reopening I had two toolbars both called "Double Vision"
I'm not sure what the implications of this are, but it seems that there is no question of an extra object not being properly deleted from memory and then being saved, because any such object would have a different name.


Also, from limited testing, I don't seem to get the problem when I run via Alt+F8 but get it pretty consistently when I run via F5 in the VBE.

Tommy
10-01-2004, 01:00 PM
Sorry I am using Win98SE, not Win98.

I ran Spy++ to capture the messages that are transfered back and forth. If you want a copy let me know.

As far as the error it only occurs on the .dot I download from the link posted last, so if something else is interfereing why now? I have a COM-Add-in I created and run that is installed, Adobe is installed but it hasn't interfered till now (if that is it). I have helped many people develope and trouble shoot Add-ins with commandbars/menus all with no error of this type.

What I have noticed is there are 2 command buttons on the bottom of the screen on a command bar that I do not see code to create, etc. The File Exit button with commandbar are displayed in the upper left hand corner. As soon as I pick the enable macro button these command bars are visible. I am picking the button that says "CustomizationContextMacroContainer" the commandbar is named "Test Customization Context Macro Container" the label is "Test Toolbar".

I think when the code to create these items is deleted, there is a call that is now deleted that makes this error get thrown.

Howard Kaikow
10-01-2004, 01:01 PM
I've just been playing (for that is what it is, isn't it?)

I thought perhaps if I renamed the toolbars I might avoid the problem and got rather a surprise. Of course, Howard, as you've been playing with it for years you probably already know this.

I added a global integer to the module
Before deleting, I renamed the existing toolbar as "Deleted #" (where # was my global integer incremented every time)
So I never, at any time, had more than one toolbar with the same name
I ran the code (a few times) and closed Word
On reopening I had two toolbars both called "Double Vision"
I'm not sure what the implications of this are, but it seems that there is no question of an extra object not being properly deleted from memory and then being saved, because any such object would have a different name.


Also, from limited testing, I don't seem to get the problem when I run via Alt+F8 but get it pretty consistently when I run via F5 in the VBE.It is not clear to me whether you are using MacroContainer or NormalTemplate.

My code also demonstrates that there are identically named toolbars, so some internal pointer is getting screwed up.

In addition, as I pointed out, the toolbars travel in position in subsequent runs.

However, I've now been seeing the problem only with NormalTemplate, no longer with MacroContainer, at least with my latest code.

I'd like to see folkes do the following:

Run MY code for MacroContainer on all your Word versions. Perhaps, we can then rule out the problem for MacroContainer. In theory, I can see why this would be less of a problem because the toolbar is actually being created in the MacroContainer template itself.

When putting the toolbar in the NormalTemplate, the code is running in MacroContainer, so CustomizationContext is likely somehow getting messed up.

One hypothesis I've not yet tested is to move the code into the NormalTemplate and then try using both MacroContainer and NormalTemplate. My guess is that both will work.

Heck, why put this off, I'll do this right now.
Be back in a bit ...!

Howard Kaikow
10-01-2004, 01:23 PM
One hypothesis I've not yet tested is to move the code into the NormalTemplate and then try using both MacroContainer and NormalTemplate. My guess is that both will work.

Heck, why put this off, I'll do this right now.
Be back in a bit ...!
Heeeeeee's back!

Wow, do I have additional info!

Using my currently posted example, the MacroContainer arg seems to work (subject to further testing) but using the NormalTemplate arg fails. Let's accept this as true for now.

Well, I just added the code and the test toolbar to my Normal template.
In theory, using either the NormalTemplate or MacroContainer arg should produce identical results. They do, but BOTH are wrong!!!

So it seems that the problem may be limited to adding the toolbar to the NormalTemplate, whether the code is run within the NormalTemplate or from another template.

This most certainly is a bug, unless we are all overlooking something.

Gee, I feel like I just discovered the Mississippi river, but now how to get to the other side?

Howard Kaikow
10-01-2004, 01:45 PM
Sorry I am using Win98SE, not Win98.

I ran Spy++ to capture the messages that are transfered back and forth. If you want a copy let me know.

As far as the error it only occurs on the .dot I download from the link posted last, so if something else is interfereing why now? I have a COM-Add-in I created and run that is installed, Adobe is installed but it hasn't interfered till now (if that is it). I have helped many people develope and trouble shoot Add-ins with commandbars/menus all with no error of this type.

What I have noticed is there are 2 command buttons on the bottom of the screen on a command bar that I do not see code to create, etc. The File Exit button with commandbar are displayed in the upper left hand corner. As soon as I pick the enable macro button these command bars are visible. I am picking the button that says "CustomizationContextMacroContainer" the commandbar is named "Test Customization Context Macro Container" the label is "Test Toolbar".

I think when the code to create these items is deleted, there is a call that is now deleted that makes this error get thrown.

The toolbar, "Test Toolbar", at the bottom is harcoded into the template just to facilitate running the two macros. The toolbar was created using the Word GUI, not with code.

I did create the toolbar in Word 2003, so it could be that our Word 2000's are not really identical even tho the versions appear to be the same. I am using the English(US) version.

Two suggestions.

1. Try dirtying and then saving the template on your system, maybe that will reset whatever.
2. Delete and, if you wish, recreate "Test Toolbar".

There's nothing in the code itself that should be interacting with anything outside of Word/Office.

Tommy
10-01-2004, 02:15 PM
There's nothing in the code itself that should be interacting with anything outside of Word/Office.


That in there is where I think the problem is, do you think it is because MS has tried to reduce the possibility of spreading viruses?

Notice how I keep changing my thinking? :)

Howard Kaikow
10-01-2004, 02:43 PM
That in there is where I think the problem is, do you think it is because MS has tried to reduce the possibility of spreading viruses?

Notice how I keep changing my thinking? :)
Let me clarify "There's nothing in the code itself that should be interacting with anything outside of Word/Office".

I meant that there's no references to external libraries or use of OLE. That's what oft causes problems interacting with 3rd party stuff. Virus protection has nothing to do with this problem.

Internally, Word is somehow losing the unique identifier for each toolbar when included in the NormalTemplate. This would appear to be a scope/context issue.

If we can conclude the following:

1. There is no problem if the code is running outside of the Normal template and the toolbar is written in the MacroContainer.

2. There is a problem if:

a. the code is running outside of the Normal template and the toolbar is written in the NormalTemplate;
b. the code is running within the Normal template and the toolbar is written in the Normal template using either MacroContaine ror NormalTemplate

3. Not yet investigated, because of less importance (at least to me), is what happens if the code is run in the Normal template and the toolbar is written in other than the Normal template. I'm not really interested in this case as it would be a bad way to distribute code.

Tommy
10-01-2004, 05:18 PM
I agree, I think the scope is the answer, as in Commandbars would refer to the ActiveDocument (here and now) where Application.Commandbars would refer to Normal or everything instead of what is currently active (scope).

I have not had a chance to check this.

johnske
10-02-2004, 02:13 AM
It's my fault for not being clearer.

In a real app, one might have something like the following.

I distribute a template that installs an app on a user's system.
The installation code allows the user to set up toolbar in various ways, e.g., to choose whether to locate the toolbar in Normal or another template.
An option might be presented that causes no change to an extant toolbar.

So, in most general case, one cannot do the deed in document_open.
Sorry for not being as clear as I could have been.
Option Explicit
Public Sub DeleteToolbars()
Dim intBeforeIndex As Integer
Dim cmdbar As CommandBar
Dim cmdbutton As CommandBarButton
Const strToolbar As String = "Double Vision HK VBA"
CustomizationContext = MacroContainer
CustomizationContext = NormalTemplate

'//NOTE VERY CAREFULLY: IF you change/paste this code & run this macro before
'//quitting you will have TWO toolbars on re-opening the doc. Running the macro
'//again on re-open deletes the duplicate and youll NEVER have this problem again
'//unless you tinker with the code & run it before quitting (a new user is not going
'//to do that if the code is locked). IF you DONT run the code before quitting
'//the two toolbars NEVER appear & the whole issue is totally redundent - WHY
'//IS THIS SO? Who really cares? - It's an issue imposed on Word users by MS so
'//we just have to accept, adapt, and think of ways to deal with the issue...E.G.

'<< THIS (deletes all strToolbars) >>
On Error Resume Next
For Each cmdbar In CommandBars
CommandBars(strToolbar).Delete
Next cmdbar

'<< INSTEAD OF THIS >>
'On Error Resume Next
'CommandBars(strToolbar).Delete
'If Err.Number = 0 Then
'Debug.Print "Toolbar deleted"
'Else
'Debug.Print "Toolbar NOT deleted"
'End If
'On Error GoTo 0

'On Error Resume Next
'CommandBars(strToolbar).Delete
'On Error GoTo 0

'//<< NOW LET'S MAKE A (strToolbar) >>
Set cmdbar = CommandBars.Add(Name:=strToolbar, Position:=msoBarTop, tempORary:=False, MenuBar:=False)
cmdbar.Visible = True
Set cmdbar = CommandBars(strToolbar)

intBeforeIndex = 1
Set cmdbutton = cmdbar.Controls.Add(Type:=msoControlButton, tempORary:=False, Before:=intBeforeIndex)
With cmdbutton
.Style = msoButtonCaption
' Use whatever you need in next line to avoid compile errors.
.OnAction = "modReplaceStringNames.ReplaceStringNames"
.Caption = "String Names"
End With

End Sub

Howard Kaikow
10-02-2004, 02:16 AM
I agree, I think the scope is the answer, as in Commandbars would refer to the ActiveDocument (here and now) where Application.Commandbars would refer to Normal or everything instead of what is currently active (scope).

I have not had a chance to check this.
CommandBars would refer to whatever is the current CustomizationContext.

Application.CommandBars should do the same, unless MSFT coded this to reset the context.

Anne Troy
10-02-2004, 02:24 AM
Don't you people ever sleep (either)??

johnske
10-02-2004, 02:40 AM
Don't you people ever sleep (either)??:yes :yes :yes (and):bore :bore :bore (and) :rofl :rofl :rofl :rofl :rofl
:bink:

Howard Kaikow
10-02-2004, 04:19 AM
It was suggested in another posting in this thread that it is possible to delete all occurrences of the toolbar prior to rebuilding the toolbar. I investigated this several years ago, alas, it is not true.

Thus far, it seems that attempting to write the "Double Vision" toolbar in the Normal template always, eventually, causes both the multiple toolbar problem AND the travelling toolbar problem.

TestingHowardKaikowDoubleVision.zip now contains:

AttemptsToForcesDeleteTestingHowardKaikowDoubleVision.dot
DoesNotForceDeleteTestingHowardKaikowDoubleVision.dot

Clearly, there is at least a problem adding toolbars to the Normal template.

In order to wind down this thread, I suggest the following.

I will run both templates unchanged, using both MacroContainer and NormalTemplate, in Word 97, Word 2000, Word 2002, and Word 2003.

I am hoping to satisfy myself that there is not a problem using MacroContainer, and that there is a problem using NormalTemplate, and in which Word versions.

It would be useful if at least, say, 3 others ran the same tests with unchanged code, for each version of Word. And posted their findings here.

P.S. I pulled out the hard coded "Test toolbar" and added code (not tested very well) to dynamically add the toolbar. This might help eliminate the 5852 error somebody encountered.

johnske
10-02-2004, 04:54 AM
It was suggested in another posting in this thread that it is possible to delete all occurrences of the toolbar prior to rebuilding the toolbar. I investigated this several years ago, alas, it is not true.

Thus far, it seems that attempting to write the "Double Vision" toolbar in the Normal template always, eventually, causes both the multiple toolbar problem AND the travelling toolbar problem.

TestingHowardKaikowDoubleVision.zip now contains:

AttemptsToForcesDeleteTestingHowardKaikowDoubleVision.dot
DoesNotForceDeleteTestingHowardKaikowDoubleVision.dot

Clearly, there is at least a problem adding toolbars to the Normal template.

In order to wind down this thread, I suggest the following.

I will run both templates unchanged, using both MacroContainer and NormalTemplate, in Word 97, Word 2000, Word 2002, and Word 2003.

I am hoping to satisfy myself that there is not a problem using MacroContainer, and that there is a problem using NormalTemplate, and in which Word versions.

It would be useful if at least, say, 3 others ran the same tests with unchanged code, for each version of Word. And posted their findings here.

P.S. I pulled out the hard coded "Test toolbar" and added code (not tested very well) to dynamically add the toolbar. This might help eliminate the 5852 error somebody encountered.
1) You say you have investigated this.....But have you actually TRIED what I have posted above? I have tried it many many times and can either get it to run flawlessly every single time, or, by tinkering with the code as I've commented, can get a duplicate every single time.

2) I have also used microsofts own code (from their help files) and if you put the exact same process in microsofts code (delete a toolbar and add a toolbar but with Temporary=False) the exact same thing happens...Two toolbars will appear if the code is tinkered with before Quitting - THE ACTUAL CODE USED IS TOTALLY AND COMPLETELY IRRELEVANT, IT'S THE PROCESS (delete a toolbar and add a toolbar with Temporary=False) THAT IS FLAWED AND CAUSING THE PROBLEM,...So,

3) As the actual code used is irrelevant, to simplify things, can we please stick with the original code and forget these extra examples?

Howard Kaikow
10-02-2004, 05:17 AM
The only way to reach a conclusion is for everybody to run the same code, and to comment on that code.

The revised version I posted is a much better candidate because it most clearly isolates a means to identify what is the likely problem area, not to mention that providing the toolbar "Test toolbar" makes it a lot easier to run the tests.

Howard Kaikow
10-02-2004, 05:48 AM
It was suggested in another posting in this thread that it is possible to delete all occurrences of the toolbar prior to rebuilding the toolbar. I investigated this several years ago, alas, it is not true.

Thus far, it seems that attempting to write the "Double Vision" toolbar in the Normal template always, eventually, causes both the multiple toolbar problem AND the travelling toolbar problem.

TestingHowardKaikowDoubleVision.zip now contains:

AttemptsToForcesDeleteTestingHowardKaikowDoubleVision.dot
DoesNotForceDeleteTestingHowardKaikowDoubleVision.dot

Clearly, there is at least a problem adding toolbars to the Normal template.

In order to wind down this thread, I suggest the following.

I will run both templates unchanged, using both MacroContainer and NormalTemplate, in Word 97, Word 2000, Word 2002, and Word 2003.

I am hoping to satisfy myself that there is not a problem using MacroContainer, and that there is a problem using NormalTemplate, and in which Word versions.

It would be useful if at least, say, 3 others ran the same tests with unchanged code, for each version of Word. And posted their findings here.

P.S. I pulled out the hard coded "Test toolbar" and added code (not tested very well) to dynamically add the toolbar. This might help eliminate the 5852 error somebody encountered.I have just finished downloading Johnske's latest code and I ran the code.

That code ALSO has the problem when the toolbar is written to the NormalTemplate. The easiest way to see this is to run the code writing to the Normal template, say 3 times, exiting from Word after each time. Exit from Word then start Word with the Normal template. You will see more than one toolbar and repeated executions will show the toolbar travelling.

We need to all be looking at the same code, and I will be looking at my latest posting as it more clearly isolates the problem and provides a toolbar to assist in running the tests.

johnske
10-02-2004, 06:28 AM
????? I've also tried it in the Normal template - as I said, it runs flawlessly ?????

johnske
10-02-2004, 07:31 AM
I have just finished downloading Johnske's latest code and I ran the code.

That code ALSO has the problem when the toolbar is written to the NormalTemplate. The easiest way to see this is to run the code writing to the Normal template, say 3 times, exiting from Word after each time. Exit from Word then start Word with the Normal template. You will see more than one toolbar and repeated executions will show the toolbar travelling.

We need to all be looking at the same code, and I will be looking at my latest posting as it more clearly isolates the problem and provides a toolbar to assist in running the tests.OH, by the way, when you say "writing to the Normal template, say 3 times..." I most certainly hope you dont mean writing code, running it then quitting do you?...

Because I can also get it to do EXACTLY the same thing that you just described (i.e. multiple toolbars and all moving to the right) if I do that too - in which case you have not read what I have written in the comments in the code and also in several of my previous posts. - It is by far THE most important part of all so I will repeat it once more...IF YOU WRITE VB CODE IN THE MODULE, YOU MUST NOT RUN THE CODE UNTIL AFTER YOU SAVE/QUIT AND RE-OPEN THE DOC!!.

Howard Kaikow
10-02-2004, 09:47 AM
Item #1 at:

http://www.standards.com/OhMyWord/VBABugsFeatures.html#DeleteToolbar

:)
I will shortly be posting a new link for this problem.

It will give explicit instructions on how to reproduce the problem.

Anne Troy
10-02-2004, 10:12 AM
Howard, I'm listening in still. Please let me know when/if you'd like me to test in any version (97 through 03) on my WinXP.

Howard Kaikow
10-02-2004, 11:17 AM
I will shortly be posting a new link for this problem.

It will give explicit instructions on how to reproduce the problem.
Done.

I think the bookmarks will still work.

I've restructured the entire link and added explicit instructions.

I likely should have been more explicit earlier.

Howard Kaikow
10-02-2004, 11:20 AM
Howard, I'm listening in still. Please let me know when/if you'd like me to test in any version (97 through 03) on my WinXP.
Great!

You can let us know whether my explicit instructions were explicit enough.

Howard Kaikow
10-03-2004, 06:20 AM
In order to reduce the chance of version incompatibilities, I rebuilt the templates using Word 97 and put the .zip file at http://www.standards.com/OhMyWord/VBABugsFeatures/FailureToDeleteToolbar.html.

I had to change AutoExit to AutoClose to make Word 97 happy.

I ran only the test that writes the toolbar in the Normal template and attempts to force deletion of all instances of the toolbar.

All worked correctly in Word 97.
In Word 2000, Word 2002, and Word 2003 all had the expected error, and at the expected time, i.e., after running only two iterations of the instructions in
http://www.standards.com/OhMyWord/VBABugsFeatures/FailureToDeleteToolbar.html.

There were some significant changes made to the CommandBar object for Word 2000. It could be that this resulted in a (mis)design change. Of course, this may make no sense, but unless we learn the secret, we may be stuck with duplicate toolbars in such apps.

Oh well, it's not a good idea to put unnecessary stuff in the Normal template.
Guess I'll move my toolbars out of Normal and see if that breaks anything.

Tommy
10-04-2004, 07:02 AM
I'll verify that the error still happens in Word 2000 SP3.

I am also still getting the 5850 error. It only happens with the downloaded versions, no other docs on "my" machine have this error. The error is thrown when I exit word.

I will test again with Word 2000 with no SP's later tonight.

Later

Howard Kaikow
10-04-2004, 07:30 AM
I'll verify that the error still happens in Word 2000 SP3.

I am also still getting the 5850 error. It only happens with the downloaded versions, no other docs on "my" machine have this error. The error is thrown when I exit word.

I will test again with Word 2000 with no SP's later tonight.

Later

If it is happening on exit, that's a sure sign of interference from some 3rd party macro or app.

The latest download was created fresh in Word 97 from a virgin template file, i.e., no extraneous project references.

Howard Kaikow
10-04-2004, 09:13 AM
I'll verify that the error still happens in Word 2000 SP3.

I am also still getting the 5850 error. It only happens with the downloaded versions, no other docs on "my" machine have this error. The error is thrown when I exit word.

I will test again with Word 2000 with no SP's later tonight.

Later
There's no point in testing with other than the latest SP/SR of each Word version.

This duplicate toolbar problem appears to have been caused by some design change made in Word 2000 that persists thru Word 2002 and Word 2003.

Indeed, the example I posted is very simple code. The only "complex" part is the passing of the template as an arg into the UseCustomizationContext sub. The code itself makes no distinction between MacroContainer and NormalTemplate.

Whatever is causing the duplicate toolbars is triggering something on your system to cause the error 5852.

My recollection is that you first encountered the error 5852 prior to my adding the "Test Toolbar". I just posted another .zip that removes the AutoClose, as it was not needed. You also could outright remove the "Test Toolbar" and run the code in the usual way.

Unexplained errors, such as the error 5852 you see, are usually the result of nasty interaction with add-ins such as PDFMaker, or whatever. They do not show up for all templates.

I ran into a similar problem with PDFMaker a few years ago, see http://www.standards.com/OhMyWord/VBABugsFeatures/PDFMakerandWordMacros.html.

Howard Kaikow
10-04-2004, 09:41 AM
I'll verify that the error still happens in Word 2000 SP3.

I am also still getting the 5850 error. It only happens with the downloaded versions, no other docs on "my" machine have this error. The error is thrown when I exit word.

I will test again with Word 2000 with no SP's later tonight.

Later
One thing to try.

1. Double-click on the template that appears to result in the 5852 error.
2. Immediately exit from Word. Does an error occur here?
3. If an error did occur in step 2:
a. Again, double click on the template.
b. Immediatelty, create a blank document based on the Normal template.
c. Do not exit Word, but close the document not based on the Normal template. Was there an error here?
d. Exit from Word, was there an error here.
4. If an error did not occur in step 2:
a. Again, double click the template.
b. Run one of the macros.
c. Immediately exit from Word. Does an error occur here?
d. If an error did occur:
e. Again, double click on the template.
f. Run one of the macros.
g. Immediately, create a blank document based on the Normal template.
h. Do not exit Word, but close the document not based on the Normal template. Was there an error here?
i. Exit from Word, was there an error here?

I hope the above is semi-clear.
The idea is to separate the closing of the template from the exiting from Word.

Wow! This was posting 100 in this thread!!

Tommy
10-04-2004, 10:13 AM
LOL I commented out the AutoClose macro because I saw one similar that PDF had installed. I also ran the test case for the PDFmaker and you are correct the error showed up.




Originally Posted by Howard Kaikow

This duplicate toolbar problem appears to have been caused by some design change made in Word 2000 that persists thru Word 2002 and Word 2003


As I posted earlier this may be MS's way of preventing the spread of viruses. I do know that in Excel you cannot add a macro to a newly created sheet (via a macro/code) until it is saved, as MD as suggested, and johnske has suggested it is the same for Word. The thing is this all can be done in the VBIDE with no problem by "hand", so I feel that, taking it a step further, the problems involed with the commandbars is an intentional henderace to convince coders to supply templates with the commandbars instead of changing the normal.dot.


Why? Because no good coder worth their salt will release something that they know is wrong.


The error occurs when Word is shutdown after all docs are closed.

Howard Kaikow
10-04-2004, 12:50 PM
LOL I commented out the AutoClose macro because I saw one similar that PDF had installed..

That was not a problem. Each and every template may have an AutoClose.
They do no harm by themselves.

A problem occurs if a sloppily written 3rd party critter such as PDFMaker lurks in the background and affects other things, sometimes in very subtle ways.

Another example. A few months ago, I decided to try a template from a well known organization. Each time, Word told me that I had changes to Normal.dot when I knew I did not. Normally, one can avoid such problems by using proper defenses in one's own Auto macros and document events. However, in that case, the template did something naughty in their document_close event which occurs AFTER my own stuff runs.

I was able to determine this because I knew how to look at the password protected code. As I am well connected with the owner of the code, they pointed me to the programmer and I pointed out the problem (and two alternative solutions). The programmer stated that he was aware of the problem and thought that he had prevented the problem. I pointed out to him WHY he missed it.

Many 3rd parties release Office code with just such problems.


I also ran the test case for the PDFmaker and you are correct the error showed up.
PDFMaker is to be polite @$$#@%$!!.



As I posted earlier this may be MS's way of preventing the spread of viruses. I do know that in Excel you cannot add a macro to a newly created sheet (via a macro/code) until it is saved, as MD as suggested, and johnske has suggested it is the same for Word. The thing is this all can be done in the VBIDE with no problem by "hand", so I feel that, taking it a step further, the problems involed with the commandbars is an intentional henderace to convince coders to supply templates with the commandbars instead of changing the normal.dot.
Not all true, but I'll not dwell on this now.



Why? Because no good coder worth their salt will release something that they know is wrong.
Sometimes the powers that be force code to be released even tho advised by the programmers or quality assurance folkes that the code is not ready. That's just unfortunately the way the world is (mis)run.


The error occurs when Word is shutdown after all docs are closed.
But not right after the template is closed?

Word is obviously confused as demonstrated by the duplicate toolbar issue. So whatever is causing that confusion is exacerbating some other problem with some other 3rd party app.

Tommy
10-04-2004, 01:26 PM
But not right after the template is closed?

Word is obviously confused as demonstrated by the duplicate toolbar issue. So whatever is causing that confusion is exacerbating some other problem with some other 3rd party app.

Just to present the steps:

I had the VBIDE open, I picked the X in the upper right hand corner, the template closed and normal was highlighed when the dialog box poped up. Also noted was the PDFmaker was still in the project which implies that it was not closed yet and normal was either in the process of closing and didn't due to error or the error occured before Normal was told to close.:dunno

I can open a document, open the template, run macros, close template, close doc, close Word, then get error.

On a another note, Word keeps track of the buttons that are added by using the .Tag property, even though when you loop through the "Standard" buttons the .Tag properties are blank. I read that somewhere so don't hold me to that. :)

Howard Kaikow
10-04-2004, 02:36 PM
Dag nab it!
I had just finished replying and lost my phone connection and lost what I typed. Oh well, maybe I'll get better words this time.



Just to present the steps:

I had the VBIDE open, I picked the X in the upper right hand corner, the template closed
There is no need to open the VBIDE. The macro should be run using the "Test Toolbar" or via the Tools |acros menu in Word.


and normal was highlighed when the dialog box poped up.
What dialog box?


Also noted was the PDFmaker was still in the project which implies that it was not closed yet and normal was either in the process of closing and didn't due to error or the error occured before Normal was told to close.
PDFMaker is not going to close until you tell Word to close and it will difficult, if not impossible, to see the sequence of closing.



I can open a document, open the template, run macros, close template, close doc, close Word, then get error.
Good, that confirms my assertion in my previous posting.


On a another note, Word keeps track of the buttons that are added by using the .Tag property, even though when you loop through the "Standard" buttons the .Tag properties are blank. I read that somewhere so don't hold me to that.
The ID property identifies the buttons. The Tag property is not used by Word, rather it is reserved for the app to use in any which way including loose.

Tommy
10-04-2004, 02:48 PM
What dialog box?
The one that displays the error. I had the VBIDE open to see if I could track the error down.

Howard Kaikow
10-04-2004, 03:05 PM
The one that displays the error. I had the VBIDE open to see if I could track the error down.
Such errors are, in effect, impossible/impractical to track.
They get buried very deeply in interactions among different pieces of software.

johnske
10-05-2004, 12:29 AM
As I posted earlier this may be MS's way of preventing the spread of viruses. I do know that in Excel you cannot add a macro to a newly created sheet (via a macro/code) until it is saved, as MD as suggested, and johnske has suggested it is the same for Word.....(etc)
Indeed tommy, if one plays around with the following subs you will see that once the VBE window is opened (state 2 as far as I'm aware), you can exit from the VBE window, run the macro "IsVBEWindowOpen" and find that it's still open....It remains open (though certainly not visible) until after you completely QUIT (not just save) the application. :bink:


Sub OpenVBEwindow_ByVisible()
Application.VBE.MainWindow.Visible = True
End Sub

Sub OpenVBEwindow_ByState()
Application.VBE.MainWindow.WindowState = 2
End Sub

Sub IsVBEwindowOpen()
If Application.VBE.MainWindow.WindowState = 2 Then MsgBox "VBE window is open (State 2)"
End Sub

Howard Kaikow
10-05-2004, 02:34 AM
Indeed tommy, if one plays around with the following subs you will see that once the VBE window is opened (state 2 as far as I'm aware), you can exit from the VBE window, run the macro "IsVBEWindowOpen" and find that it's still open....It remains open (though certainly not visible) until after you completely QUIT (not just save) the application. :bink:


Sub OpenVBEwindow_ByVisible()
Application.VBE.MainWindow.Visible = True
End Sub

Sub OpenVBEwindow_ByState()
Application.VBE.MainWindow.WindowState = 2
End Sub

Sub IsVBEwindowOpen()
If Application.VBE.MainWindow.WindowState = 2
Then MsgBox "VBE window is open (State 2)"
End Sub
See http://www.vbaexpress.com/forum/showthread.php?p=9046#post9046.

Howard Kaikow
10-05-2004, 02:44 AM
.

PDFMaker is to be polite @$$#@%$!!.

Hmmm, perhaps I should have used the real words to test the forum's censorship?

Oh, h,e, double hockey sticks!

Howard Kaikow
10-06-2004, 04:09 PM
The failure to delete toolbar problem is quite consistent.

I created a totally different template to create 2 identically named toolbars.
Again, they were not deleted, and after running the nacro twice, I ended up with 4 identically named toolbars.

At least the behaviors is consistent.

Tommy
10-07-2004, 05:58 AM
I stiil get the error 5852. I will look into further later today. I think I am going to code it from scratch to see if I can find a way around or through it. :)

Howard Kaikow
10-07-2004, 09:29 AM
I stiil get the error 5852. I will look into further later today. I think I am going to code it from scratch to see if I can find a way around or through it. :)
did you use the template I sent only to you?

I'll send you another one that was coded from scratch and does not have a toolbar.

Howard Kaikow
10-07-2004, 07:35 PM
Item #1 at:

http://www.standards.com/OhMyWord/VBABugsFeatures.html#DeleteToolbar

:)
Here's a simpler URL (requires Javascript be enabled).
http://www.standards.com/links.html?FailureToDeleteToolbar (http://www.standards.com/links.html?FailureToDeleteToolbar)

johnske
10-08-2004, 09:44 PM
Have you read this? > http://support.microsoft.com/default.aspx?scid=kb;en-us;241652 - seems a very similar problem...

As it appears the problem was discovered in Excel, the whole thing refers to Excel in particular. But I cant see the methods for working around it in Excel differing from those for Word by very much.

It not only discusses ways to work around the problem, it also has a link to a downloadable registry repair tool to fix the problem.

Note: I started to install the fix to test to see if this also applies to Word, but as the downloadable installation was about a three-hour one I simply couldn't be bothered - I'll work around it... :bink:

Howard Kaikow
10-09-2004, 07:44 AM
Have you read this? > http://support.microsoft.com/default.aspx?scid=kb;en-us;241652 - seems a very similar problem...

As it appears the problem was discovered in Excel, the whole thing refers to Excel in particular. But I cant see the methods for working around it in Excel differing from those for Word by very much.

It not only discusses ways to work around the problem, it also has a link to a downloadable registry repair tool to fix the problem.

Note: I started to install the fix to test to see if this also applies to Word, but as the downloadable installation was about a three-hour one I simply couldn't be bothered - I'll work around it... :bink:Yes, I saw that in May 2003, but had forgotten about it.

Seems like it may be more related to http://www.standards.com/links.html?SetReferenceInWordProject (http://www.standards.com/links.html?SetReferenceInWordProject). However, if discussed here, has to be a separate thread.

Howard Kaikow
10-10-2004, 08:57 AM
Have you read this? > http://support.microsoft.com/default.aspx?scid=kb;en-us;241652 - seems a very similar problem...

As it appears the problem was discovered in Excel, the whole thing refers to Excel in particular. But I cant see the methods for working around it in Excel differing from those for Word by very much.

It not only discusses ways to work around the problem, it also has a link to a downloadable registry repair tool to fix the problem.

Note: I started to install the fix to test to see if this also applies to Word, but as the downloadable installation was about a three-hour one I simply couldn't be bothered - I'll work around it... :bink:
First, you really do need to keep each Office version up tp date. Not only are there bugs fixed, but there are security issues. Just start the download and partake of you rfavorite hobby, or read, or which TV while the critter does its thing.

In any case, as I already had the patched Office 2000, I could not reproduce the problem in the KB article in Excel 2000, so, always looking for trouble, I booted to my system with Office 97, and was able to reproduce the problem.

Excel handles CommandBars in certain ways that are very different than Word. And Word 97 does have that problem anyway.

Applying the Excel workaround to Word to see whether it avoids the delete toolbar issue I raised would be a bit more complex than the way the technique is applied in Excel.

Actually, the technique might be more appropriate to the problem in http://www.standards.com/links.html?SetReferenceInWordProject (http://www.standards.com/links.html?SetReferenceInWordProject).
If only for the latter reason, I'll try to apply the technique, but not before tomorrow (hmmm, it's just about tomorrow down under, n'est-ce pas, so I mean tomorrow in USA Eastern time zone).

Howard Kaikow
10-11-2004, 07:47 AM
Excel handles CommandBars in certain ways that are very different than Word. And Word 97 does have that problem anyway.
I meant to say "Word 97 does NOT have that problem anyway".


Applying the Excel workaround to Word to see whether it avoids the delete toolbar issue I raised would be a bit more complex than the way the technique is applied in Excel.
I made a first attempt at applying the technique with Word.
The technique, as I applied it, just further exacerbates the delete toolbar issue in Word.


Actually, the technique might be more appropriate to the problem in http://www.standards.com/links.html?SetReferenceInWordProject. (http://www.standards.com/links.html?SetReferenceInWordProject.)
I've not yet tried this.