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

"cheesey_toastie" wrote:

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

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.

Steve
son wrote:
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

"cheesey_toastie" wrote:

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

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

cheesey_toastie wrote:
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.

Steve
son wrote:
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

"cheesey_toastie" wrote:

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

Well, it's obvious: look at today's date -- Excel has become possessed!

"cheesey_toastie" wrote:

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

cheesey_toastie wrote:
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.

Steve
son wrote:
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

"cheesey_toastie" wrote:

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

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!


son wrote:
Well, it's obvious: look at today's date -- Excel has become possessed!

"cheesey_toastie" wrote:

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

cheesey_toastie wrote:
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.

Steve
son wrote:
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

"cheesey_toastie" wrote:

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

Well, that must have been a pretty tricky one to track down... :-)

/MP

"cheesey_toastie" wrote:

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!


son wrote:
Well, it's obvious: look at today's date -- Excel has become possessed!

"cheesey_toastie" wrote:

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

cheesey_toastie wrote:
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.

Steve
son wrote:
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

"cheesey_toastie" wrote:

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

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.

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!


Ken McLennan wrote:
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.

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