Macro now opens up VBA editor - not intended

  • Thread starter Thread starter excelnut1954
  • Start date Start date
E

excelnut1954

This is very strange. I ran a macro in a worksheet that does quite of
few routines, and has worked good up until now. Today, I ran it, and at
the end of it all, it now opens up the VBA Editor, and shows all the
UserForms, and Modules.

I have never had it do this. I don't even know how to write the code
for that.

I noticed all this when I ran the macro today, and at the very end of
all the routines, it asked for the PW to open up the editor. (I've had
a PW on it since I started building macros in it.)
I removed the PW, opened the workbook up again, and ran the macro. It
still went to the editor, and opened up all the forms, modules, etc.

Any ideas why this is happening?
Thanks,
J.O.
 
My guess is that you are hitting an error and the program is breaking on the
error. Does an error message pop up or not. Check your VBA editor Under tools
-> Options -> General it should be set to Break on Unhandled Errors. The
other thing to do is to open the Project and make sure the code compiles
Debug -> Compile
 
Well, I checked, and the settings in Tools are ok.
I run the Compile Worksheet, and it gives errors in modules that I'm
working on. There are lots of code in here that doesn't work right.
But, I'm not using these subs. There just there to work on (saving the
file to another name when testing).

So, the Compile thing doesn't do much good for me.
Also, there is no error message. All the routines seem to work ok.
Everything does what its suppose to.

I'll have to go back and find the last file that worked ok. These are
renamed each day.

If you have other ideas, I would appreciate it.
Thanks,
J.O.
 
-> Options -> General it should be set to Break on Unhandled
Errors.

Actually, it is better to set the Error Trapping option to 'Break
in Class Module', so that if there is an error in a class module
(or ThisWorkbook or a sheet module or form), you'll break in the
class module itself, rather than the call to the class module's
methods.

To illustrate, just put

Public Sub X()
Debug.Print 1 / 0
End Sub

in ThisWorkbook. Then, from a general module, run

Sub AAA()
ThisWorkbook.X
End Sub

Change the Error Trapping options between 'Break On Handled
Errors' and 'Break In Class Module' to see where the code breaks.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com





"Jim Thomlinson" <[email protected]>
wrote in message
 
Thanks Chip. I see what you mean... I think I learn more answering questions
than I ever did asking them...
 
Clean up the syntax errors. If the problem still exists after you have
cleaned up all of the errors (and your code successfully compiles) I will be
quite surpirsed. Weird things happen when you execute code that does not
compile, even if that code is never called.

If you want you can just comment out the sections of the code that you are
working on. Make sure you have option explicit at the top of each module to
ensure that your variables are properly declared.
 
Thanks Chip and Jim. I was trying to plug in a new module before it was
actually ready. I was missing some range names in the 'live" worksheet
that I had created in my WIP file that I run side-by-side with new
development. Anyway, cleaned it up, and all works well. However, still
learned something about the error trapping. I still need to learn more
about the debugging features. I still rely on tracking errors by
reviewing line by line.

Thanks again
J.O.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top