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