Challenge!! Can you solve this problem?

Quote:

---

Originally Posted by Dreamboat

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.

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:

Code:

---

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

---

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:

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...

Code:

---

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:

Quote:

---

Originally Posted by johnske

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...

[VBA]
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
[/VBA]

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.

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

Quote:

---

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.

[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:

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:

Quote:

---

Originally Posted by TonyJollans

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.

Can I suggest

5.1 Large glass of Lagavulin malt whisky

6.1 Even larger glass of Lagavulin malt whisky

MD: Do you think Howard should INSERT those steps? Or REPLACE them?

To carry out steps 6 and 7, I consider 5.1 and 6.1 a prerequisite!

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!!

Maybe limits are required, after all, there may be some testing and analysing to be done. Wouldn't want him ROF :drunkard:

Quote:

---

Originally Posted by mdmackillop

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.

Quote:

---

Originally Posted by Dreamboat

Item #1 at:

http://www.standards.com/OhMyWord/VB...#DeleteToolbar

:)

---

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

I sympathise; I don't think politicians should be taken without one, but maybe a large pinch of salt would do.

Quote:

---

Originally Posted by Howard Kaikow

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.

Quote:

---

Originally Posted by mdmackillop

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 ...

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:

LOL. Before this thing is closed up and neatly put away, I'll knock out some of the off-topic comments. :)

Quote:

---

Originally Posted by Howard Kaikow

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.

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:

Quote:

---

Originally Posted by johnske

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.

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

Code:

---

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 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?

Quote:

---

Originally Posted by johnske

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

Code:

---

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.

Quote:

---

Originally Posted by Tommy

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?

IGNORE THIS POST!!!

Quote:

---

Originally Posted by johnske

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

Code:

---

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

Quote:

---

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

Quote:

---

Originally Posted by Howard Kaikow

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:

Quote:

---

Originally Posted by johnske

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.

Quote:

---

Originally Posted by Tommy

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

---

I 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.

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.

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.

Quote:

---

Originally Posted by TonyJollans

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 ...!

Quote:

---

Originally Posted by Howard Kaikow

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?

Quote:

---

Originally Posted by Tommy

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.

Quote:

---

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? :)

Quote:

---

Originally Posted by Tommy

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.