in reply to show/hide an Entry field

We make up an excel spreadsheet (password protected) to create the new passwords, then copy/paste them into the script.

No doubt you have an excellent reason for doing it in this horribly inefficient manner but for the life of me I cannot imagine what that might be. Care to share?

I would forget all about Tk for this and just export the data to a temporary CSV, slurp it in and change them all automatically. If (unlike me) you like working with MS Excel directly you can probably even omit the CSV step.

Replies are listed 'Best First'.
Re^2: show/hide an Entry field
by dadenn (Initiate) on Jun 29, 2016 at 23:10 UTC
    Would you care to come up with 300+ passwords every 6 months that are a minimum of 12 characters, 2 uppercase, 2 lowercase, 2 special characters, 2 numeric with no more than three of any type together? And remember them? And never repeat any password for 24 months? I already created an LDAP GUI to assist in running commands in four domains and using the Perl-Tk GUI to change those 300+ passwords in 4 LDAP domains saves A LOT of time. If I can verify that the copy/paste is correct, that would also save a lot of time.
[reply]

      Would you care to come up with 300+ passwords every 6 months that are a minimum of 12 characters, 2 uppercase, 2 lowercase, 2 special characters, 2 numeric with no more than three of any type together? And remember them? And never repeat any password for 24 months? I already created an LDAP GUI to assist in running commands in four domains and using the Perl-Tk GUI to change those 300+ passwords in 4 LDAP domains saves A LOT of time. If I can verify that the copy/paste is correct, that would also save a lot of time.

      One person with 300+ passwords?

      If that is the case, why hide the passwords at all?

      Why wouldn't the passwords be identical ? If copy/paste can fail, how can you trust Tk to hide/show without corrupting... how can you trust any part of the program?

[reply]

In Section Seekers of Perl Wisdom