Trapping what triggered AutoOpen (Word97/NT)

Topic

New Reply

Hi

I run a macro in a project containing many subs and functions, including an AutoOpen. The AutoOpen triggers unexpectedly. I try to track down the line of code that caused it to trigger:

• I look in the stack, but it only goes back to AutoOpen.
• I try disabling auto macros by putting “Wordbasic.DisableAutoMacros 1/0” at the beginning and end of the subroutine containing the MsgBox. No joy.
• I progressively move a Stop statement around until I find the apparent trigger. It’s a simple MsgBox statement.
• If I put the Stop statement one line before the MsgBox, the macros stop at that point, as expected. If I put it one line after, I get “cannot execute in break mode” (presumably because the AutoOpen tried to execute).[/list]Any ideas?
  Dale

Reply | Quote

Replies

Not without seeing the document or template.

Reply | Quote

Hans
Please comment on post 537,562.

Reply | Quote

Don,

It’s an interesting idea, but I don’t know whether it’s correct or how I would be able to check that. Sorry!

Reply | Quote

Thanks Hans

Reply | Quote

My recollection is that WordBasic.DisableAutoMacros gets reset by Word under certain circumstances.
I think that I test this once, I’ll try to find the test, or create a new test.

Reply | Quote

Hi Howard
Some further testing that I have done, convinces me that the creation of an HTML file requires that AutoMacros not be reset.; and if the HTML file is created through a macro, the AutoMacros will not be fired until the code which is currently running has finished. To demonstrate this, I suggest that you:

1. UnComment the two WordBasic.DisableAutoMacros 1/0 commands in WordDocToHTMLCode_Part1
2. Add more code after the MsgBox in the current code. On running WordDocToHTMLCode_Part1, you will see that the new code executes and on completion of the WordDocToHTMLCode_Part1 procedure the AutoOpen procedure will fire.
3. Comment out WordBasic.DisableAutoMacros 0. You will see that on completion of the WordDocToHTMLCode_Part1 procedure, nothing further happens.

Reply | Quote

autoopen will run only when a doc is opened or if it is explicitly called.

try putting a STOP statement in AutoOpen itself, thn step thru the code to find the point AFTER which the AutoOPen was called.
Should be some statement that opens a doc or explicitly calls autoopen.

Reply | Quote

Howard
That’s why I’m confused. AutoOpen appears to be being triggered by a MsgBox statement.

• If I put Stop before the MsgBox, it stops gracefully.
• If it goes after the MsgBox, I get “cannot execute in break mode”.
• If I don’t have any Stop statement in that macro, the AutoOpen gets executed.
• If I comment out the MsgBox statement, the AutoOpen gets executed.[/list]Maybe I need to “clean” the project.

  Hans
  It’s a bit of a brute, but here are the two key macros.

  Yours in bewilderment
  Dale

Reply | Quote

Dale, are you sure the MsgBox is causing the AutoOpen when you state “If I comment out the MsgBox statement, the AutoOpen gets executed”

Why have you disabled the DisableAutoMacro lines in the code you are using? Did that not work?

Looking at the code it appears there is a bit of opening and closing of files going on – Documents.Add for instance and the user is prompted to potentially perform another in the View HTML message box. Any file opening is potentially going to kick off the autoopen macro.

Reply | Quote

Hi Andrew

I tried disabling auto macros, but that didn’t work. I’ve just retested it (with the disable statement right at the very start of the macro), and it still doesn’t stop AutoOpen from being triggered.

And no, like you I can’t imagine how the MsgBox would cause the problem.

To summarise, there are four situations:

1. If I disable auto macros AND don’t have a Stop in the macro THEN I reach the Stop I’ve put into AutoOpen.
2. If I disable auto macros AND put a Stop immediately before the MsgBox THEN the macros stop gracefully at the Stop.
3. If I disable auto macros AND put a Stop immediately after the MsgBox THEN I get “cannot execute in break mode”.
4. If I disable auto macros AND don’t have a Stop in the macro AND comment out the MsgBox THEN I reach the Stop I put into AutoOpen.

NOTE: Facts 2 and 3 [i]edited later[/i] seems to imply that MsgBox is the problem, fact 4 seems to imply it’s not.
PS: I’m running the macro directly, so it’s not possible that control is being passed to another macro after the MsgBox statement.

Confusing, eh
Dale

Reply | Quote

I think that (4) rules out the Message Box as the culprit. What happens if you do (2) to pause the macro and then step through one line at a time from that point. Which line causes the AutoOpen macro to be called?

Reply | Quote

Put the Stop in the AutoOpen, otherwise you will not be able to deternine from whence it is invoked.

Reply | Quote

Hi Howard

I should have made it clearer. In all four testing scenarios there was a Stop at the start of AutoOpen,

Dale

Reply | Quote

Hi Dale
Where is the module stored which contains the macros you forwarded?

• Normal?
• An Add-In template?
• An attached template other than Normal?
• Other? (Please specify)
  [/list]

Reply | Quote

Hi Don

The macro project is in the attached template (not Normal). And it’s the AutoOpen in the attached template that’s being triggered.

Dale

Reply | Quote

Dale
Your problem can be overcome by replacing the Stop command in the AutoOpen procedure with

If ActiveDocument.Name = "^CAN BE DELETED.htm" Then Exit Sub

For the rationale, please see post 537,623

Reply | Quote

That’ll do me, Don. Very pragmatic solution. And thanks to everyone else who contributed.

By the way, I probably should have given a bit more context when I started this off.

Reply | Quote

> which forced me to split the process into Part 1 and 2.)

Rob Bovey’s Code Cleaner has something like this. I’ve not looked at the code in ages. Since the Code Cleaner is, effectively, translating documents, he might have run into a similar problem.

Reply | Quote

Hello again Dale
It appears to me that your problem is that you SaveAs an HTML file. The problem disappears when saving as a Word document.
I speculate–and here I seek the confirmation of more knowledgeable minds than mine–that saving to HTML requires the use of code, and in order for the process to proceed the DisableAutoMacros command is overridden.

Reply | Quote