Macro launches VB IDE window

  • Thread starter Thread starter cheesey_toastie
  • Start date Start date
C

cheesey_toastie

A long established spreadsheet is now loading the VB IDE for some
reason. As the project is password protected this causes the user to
have to enter the VBA password which is not ideal.

Anyone know why Excel does this?? I'm assuming its a bug, is there is
a workaround?

Steve
 
Without knowing anything about the actual error message (please, provide it)
I can only guess: it's likely that you've got a broken reference in the
workbook.

I recommend that you work together with the user to establish what's going
wrong with your VBA code on their machine(s): enter the VBA project, and
check the references. What is the exact set of dependencies? Are all those
files really present on the target machine? Make sure that all those are
deployed together with your project.

Cheers,
/MP
 
Sorry I didn't explain myself very well. The macro runs successfully
without error (except where the IDE has a password), its more that the
IDE becomes visible, and if it has password protection will not allow
the user to continue unless the VBA IDE password is provided.

I have tried exporting and re-importing the modules but no success.
 
It was due to an application.goto("ANAME") where ANAME is a named cell
that didnt exist.

I can't understand why it didnt produce an error but there we are!

steve
 
Well, it's obvious: look at today's date -- Excel has become possessed!
 
I found out why...

Application.Goto("ANAME") where the intended named cell didnt exist
ANAME
so instead of erroring it found a function which the orignal developer
had named the same as one of their named cells. Hence the VBA IDE
being launched.

So no 06062006 nonsense!
 
G'day there Cheesey_toastie,
Application.Goto("ANAME") where the intended named cell didnt exist
ANAME
so instead of erroring it found a function which the orignal developer
had named the same as one of their named cells. Hence the VBA IDE
being launched.
Click to expand...

But would't it have gone to the VBE anyway? If there was no
password it would have halted in the VBE with the offending instuction
highlighted and an error message showing there. If the client had filled
in the password, that's what they would have been presented with.

I just tried it myself by using a named range and sub with the
same name. After deleting the name I simply got a Method "Range" of
object "_Global" error message. After clicking 'debug' on the dialog the
line was highlighted awaiting correction.

I think you'll find it had bugger all to do with the function name
coinciding with the range name.

See ya
Ken
 
The offending goto would have opened the VBE at the function then then
next Goto statement, of which there were many (again remember this
wasn't my coding!) masked the problem!

So stepping through the code I should have noticed the cursor jump BUT
I didnt know where to start looking as when I entered the VBE password
to debug it worked normally!!! This is why I immediately thought it
was an Excel bug.

A total bugger to track down!
 
G'day there Cheesey_toastie,

[This followup was posted to microsoft.public.excel.programming and a
copy was sent to the cited author.]

The offending goto would have opened the VBE at the function then then
next Goto statement, of which there were many (again remember this
wasn't my coding!) masked the problem!
Click to expand...

...what? And you didn't know instinctively what the programmer was
doing? <g>. I see what you're getting at. You'd have been in the
offending function without knowing from where it would have been called.
Couldn't you just guess, write some arbitrary lines of code and hope
like shit that it worked? =)
So stepping through the code I should have noticed the cursor jump BUT
I didnt know where to start looking as when I entered the VBE password
to debug it worked normally!!! This is why I immediately thought it
was an Excel bug.
Click to expand...

Aaahhhh... what a pain that would be!!

Mind you, nearly all of the difficult to track problems that I've
had were of my own making. Now that is a REAL pain, because you can't
blame anybody else. I usually try to blame Microsoft and many would like
to believe me. However those that know the extent of my programming
skills just laugh and walk away. You can never get any sympathy when you
stuff it up yourself.
A total bugger to track down!
Click to expand...

I can see why. I'm glad that you found it eventually. Lots of
coffee consumed in the process I'd imagine.

See ya
Ken McLennan
Qld Australia
 
Mind you, nearly all of the difficult to track problems that I've
had were of my own making. Now that is a REAL pain, because you can't
blame anybody else. I usually try to blame Microsoft and many would like
to believe me. However those that know the extent of my programming
skills just laugh and walk away. You can never get any sympathy when you
stuff it up yourself.
Click to expand...

You mean all the other problems in this organisation are not the fault
of Microsoft? Well sod it, they are getting blamed during my
appraisal!!

Ken, thanks for injecting some humour!

Steve
Stockport, England

Ken said:
G'day there Cheesey_toastie,

[This followup was posted to microsoft.public.excel.programming and a
copy was sent to the cited author.]

The offending goto would have opened the VBE at the function then then
next Goto statement, of which there were many (again remember this
wasn't my coding!) masked the problem!
Click to expand...

...what? And you didn't know instinctively what the programmer was
doing? <g>. I see what you're getting at. You'd have been in the
offending function without knowing from where it would have been called.
Couldn't you just guess, write some arbitrary lines of code and hope
like shit that it worked? =)
So stepping through the code I should have noticed the cursor jump BUT
I didnt know where to start looking as when I entered the VBE password
to debug it worked normally!!! This is why I immediately thought it
was an Excel bug.
Click to expand...

Aaahhhh... what a pain that would be!!

Mind you, nearly all of the difficult to track problems that I've
had were of my own making. Now that is a REAL pain, because you can't
blame anybody else. I usually try to blame Microsoft and many would like
to believe me. However those that know the extent of my programming
skills just laugh and walk away. You can never get any sympathy when you
stuff it up yourself.
A total bugger to track down!
Click to expand...

I can see why. I'm glad that you found it eventually. Lots of
coffee consumed in the process I'd imagine.

See ya
Ken McLennan
Qld Australia
Click to expand...
 
You must log in or register to reply here.

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

Similar Threads

excel 97, VB project unable to view in another comp 2
VBA - Launch VBA Macro From VB 2
can't see VBA code, although it's working 0
VB Excel Macro 5
VB password lost 3
Hide VB Scripts & macro from user 1
Protect Excel VB macro 2
VBA code line to ascertain if VBAProject(Test) in the IDE is open 3

Back
Top