Clean up/check vba code created from merging existing code

  • Sorry if this sounds silly, and I know it's not a lot of code, but I wanted to see if I could create a macro that would, based on a specified date, effectively lock a workbook with a random password. I've pieced together the parts to do it, and it works. What I want to know is, does it look ok/efficient and if not what changes could be made to clean it up. The random password part came from Dave Hawley's reply to someone's post about generating random numbers/strings here on Ozgrid, so I'm pretty sure that code is fine. If I should link to what I found of his, I can certainly add that and I apologize for not doing so already,would just have to find it again. Just curious about how I merged everything.

    Few points:
    1) I know that this would never keep someone that knew anything about vba or was persistent enough out of a worksheet...
    2) I know the end throws out a msgbox with the password, would obviously take it out if I ever wanted to use it.
    3) This was more for me to learn how to 'nest' functions and work to an end than what the result is.

    Thanks in advance for any help.

  • Re: Clean up/check vba code created from merging existing code

    It's virtually impossible to protect an Excel workbook.

    Your code will be time consuming - it has a fixed date.

    It can be overcome by re-setting the PC's time.

    Even VBA passwords can be bypassed so your code will not be secure

  • Re: Clean up/check vba code created from merging existing code


    First, thanks for the reply.
    I realize (and mentioned) that I know this isn't going to keep people out. It was more for me to see if it could be done and what I did correctly or incorrectly making it. Very new to vba, so this was my first attempt to create something semi-independently, with the assistance of what I found on the forums. I'm learning a ton by reading all the posts here and searching how to do new things. Really just want to know what's wrong or should be tweaked with it.

    If I ever did use it, the users I'm dealing with wouldn't even realize it was a date issue, let alone think about changing the computer's clock, but you are very correct, that would be one work around. As for the fixed date, why would that make the code time consuming? The reason it is there is just to cause a trigger that would start the event. Say the sheet expires at the end of a fiscal year where new data will be, so the old one can't be used and they are forced to use a new one.

    THanks again for the earlier reply.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!