Unprotecting the VBProject

[Guest]

I'm trying to set the .CodeName property of a worksheet, and I do it this way

Dim wks as Workshee
Dim sCodeName as Strin

Thisworkbook.VBProject.VBComponents(wks.CodeName).Name = sCodeNam

This works, unless the VBProject is password protected. Now the code knows its own password, so to speak. It's declared in a module as a public constant. But the VBProject.Protection property appears to be read-only. I can't get this to work from inside VBA. Note: I'm doing this in Excel '97, I hope that's not my problem. There has to be a way to do this, doesn't there

James

 

[Chip Pearson]

There is no programmatic way to unprotect a VBProject. The only
way is via the dialog box.


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

I'm trying to set the .CodeName property of a worksheet, and I do it this way:

Dim wks as Worksheet
Dim sCodeName as String

Thisworkbook.VBProject.VBComponents(wks.CodeName).Name = sCodeName

This works, unless the VBProject is password protected. Now

the code knows its own password, so to speak. It's declared in
a module as a public constant. But the VBProject.Protection
property appears to be read-only. I can't get this to work from
inside VBA. Note: I'm doing this in Excel '97, I hope that's not
my problem. There has to be a way to do this, doesn't there?

 

[Guest]

Thanks for the prompt, definitive response

That really sucks. Do you know what the rationale is for that rule

This is a bummer because I'm required to protect the project with a password, but I have been relying on the .CodeName property of the sheets in various places (I create a kind of custom sheet property with a prefix in the .CodeName). I suppose I could come up with another mechanism for storing that custom sheet property, like a name. And then let the .CodeName be however it defaults. It's still a bummer that I can't control the .CodeName, I like to have everything neat and organized. Oh well

Thanks again

James

 

[Jon Peltier]

James -

Do you know what the rationale is for that rule?

Macro virus protection.

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Peltier Technical Services
Tutorials and Custom Solutions
http://PeltierTech.com/
_______

 

[Guest]

I can see how unprotecting other projects creates virus vulnerability, but unprotecting Me, Myself, whatever you want to call the project that's running the unprotect code, when I have a the password available, that seems like overkill or a shotgun approach to virus protection that closes one too many doors.

Oh well, thanks for the info. I figured it was probably protection against malice of some sort.