Is it just me, or is it an incredible shortcoming that you cannot
programmicly remove a VB Project password?

If you need to change any of your code, which happens, what, all the time?
your out of luck, period. Send the user a new sheet. What if the user
can't get the new sheet? oh well, more out of luck then. Distributing a
workbook with unlocked VB Projects is completely out of the question, so
where does that leave you?


I have a 8meg excel doc that i need to make code changes to, 500 miles away,
but oh well. I can't. The VB Project is locked. And I can't distribute a
new Excel workbook, they are on dial up. What can be done in a situation
like this?

Mail them a CD via the Postal Service.
Media rates are very reasonable.
-or-
Supply the password to the user.

Jim Cone
San Francisco, USA


"Kaisies" wrote in message
...
Is it just me, or is it an incredible shortcoming that you cannot
programmicly remove a VB Project password?
If you need to change any of your code, which happens, what, all the time?
your out of luck, period. Send the user a new sheet. What if the user
can't get the new sheet? oh well, more out of luck then. Distributing a
workbook with unlocked VB Projects is completely out of the question, so
where does that leave you?
I have a 8meg excel doc that i need to make code changes to, 500 miles away,
but oh well. I can't. The VB Project is locked. And I can't distribute a
new Excel workbook, they are on dial up. What can be done in a situation
like this?

Shortcoming???? What't the point of a password if another person can remove
it. Wouldn't the virus writers just love that? If you don't want a password,
don't apply one in the first place.


On Fri, 25 Mar 2005 17:05:06 -0800, "Jim Cone" wrote:

Is it just me, or is it an incredible shortcoming that you cannot
programmicly remove a VB Project password?

"Jim Cone" wrote:

Mail them a CD via the Postal Service.
Media rates are very reasonable.

And how do you get end-user supplied data from the old sheet to the new one?
Copy it all over, in a macro of course, but for all intensive purposes, by
hand... since you have to program the macro to do the copying. So instead of
just changing your VB code, you have to change your VB code AND write a
function to copy end-user supplied data from the old workbook to the new one,
not only once, but many times over if the location of that data changes.

Is that time investment really THAT worth it?

I can't be the only one that thinks the esiest solution would be to allow
VBProject.unprotect , but then simply have a checkbox in the same Dialog box
as your VBProject protection information that dissalows VBProject.unprotect
from executing, thus negating and "brute force" attacks that cannot already
occur with SendKeys?


-or-
Supply the password to the user.


Whats the point of passwording a sheet so the end user cannot make changes
(integrity of your formulae) only to supply that same user the password?
Jim Cone
San Francisco, USA

Whats the point of a password if YOU cannot remove it?

"Myrna Larson" wrote:

Shortcoming???? What't the point of a password if another person can remove
it. Wouldn't the virus writers just love that? If you don't want a password,
don't apply one in the first place.


On Fri, 25 Mar 2005 17:05:06 -0800, "Jim Cone" wrote:

Is it just me, or is it an incredible shortcoming that you cannot
programmicly remove a VB Project password?

YOU can. In fact anybody who knows the password can remove it, including your
users. The point is not WHO can remove the password, but that this step must
be done manually. It can't be done through code.

Perhaps your real problem is faulty design of your project. Have you
considered separating the user's data (presumably this huge workbook) from
your code, which should be in a (presumably much smaller) add-in? Then you can
modify the code and distribute a new add-in when needed, and the issues of
passwords and file size are moot.


On Fri, 25 Mar 2005 17:43:02 -0800, "Kaisies"
wrote:

Whats the point of a password if YOU cannot remove it?

"Myrna Larson" wrote:

Shortcoming???? What't the point of a password if another person can remove
it. Wouldn't the virus writers just love that? If you don't want a
password,
don't apply one in the first place.


On Fri, 25 Mar 2005 17:05:06 -0800, "Jim Cone"
wrote:

Is it just me, or is it an incredible shortcoming that you cannot
programmicly remove a VB Project password?

Separate the code from the data. Every professional developer from the
one-person shop to the largest software company in the world does that.

To get started, see http://groups-
beta.google.com/group/microsoft.public.excel.programming/msg/7fcd7a49ca
8efc52?
safe=off&as_umsgid=MPG.185a8ddd52ccd5ce98a88c@msne ws.microsoft.com&lr=&
num=100&hl=en


--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article ,
says...


"Jim Cone" wrote:

Mail them a CD via the Postal Service.
Media rates are very reasonable.

And how do you get end-user supplied data from the old sheet to the new one?
Copy it all over, in a macro of course, but for all intensive purposes, by
hand... since you have to program the macro to do the copying. So instead of
just changing your VB code, you have to change your VB code AND write a
function to copy end-user supplied data from the old workbook to the new one,
not only once, but many times over if the location of that data changes.

Is that time investment really THAT worth it?

I can't be the only one that thinks the esiest solution would be to allow
VBProject.unprotect , but then simply have a checkbox in the same Dialog box
as your VBProject protection information that dissalows VBProject.unprotect
from executing, thus negating and "brute force" attacks that cannot already
occur with SendKeys?


-or-
Supply the password to the user.


Whats the point of passwording a sheet so the end user cannot make changes
(integrity of your formulae) only to supply that same user the password?
Jim Cone
San Francisco, USA