LOL. Before this thing is closed up and neatly put away, I'll knock out some of the off-topic comments.
LOL. Before this thing is closed up and neatly put away, I'll knock out some of the off-topic comments.
~Anne Troy
I forgot to mention that I added a toolbar to the template to make it easier to run the code.Originally Posted by Howard Kaikow
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
Thanx for verifying the error that I had described.I note you have not bothered to download my last attachment
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...
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
John
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
[VBA]
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
[/VBA]
Regards,
John
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?
I believe this is addressing a different problem than the one I posed.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
[VBA]
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
[/VBA]
Regards,
John
Which Sub are you running, there are two?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 version of Word?
Which OS?
IGNORE THIS POST!!!
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.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
[VBA]
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
[/VBA]
Regards,
John
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
Which Sub are you running, there are two? <- TestCustomizationContextMacroContainerOriginally Posted by Howard Kaikow
Which Sub are you running, there are two?
Which version of Word?
Which OS?
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
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
It's my fault for not being clearer.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
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.
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'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.
- 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"
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.
Enjoy,
Tony
---------------------------------------------------------------
Give a man a fish and he'll eat for a day.
Teach him how to fish and he'll sit in a boat and drink beer all day.
I'm (slowly) building my own site: www.WordArticles.com
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.
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 ...!
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?
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.
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?
There's nothing in the code itself that should be interacting with anything outside of Word/Office.
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".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?
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.
Posting Permissions
Reply With Quote
