- Joined
- Nov 22, 2003
- Location
- New York City
My concern with hard-coding "c:\mksig" in mksig is that if they change it to "F:\mksig" but also choose to autoupdate, it'll write over with $dir="c:/mksig" everytime there's a new mksig update. I can have gui.pl modify the $dir in mksig before running, but I really don't want to touch your code 
So far the relative paths work, just like how your original sig_gen stored stfd.html in the mksig directory without directing a absolute path. So if mksig doesn't detect sig, sig_gen, or mksig.conf, wouldn't it create it in the same directory that mksig lives too (just like stfd.html)? Wouldn't this be the way to go, so that we could place mksig.pl in any directory we'd like, without altering the mksig code? Plus, it shouldn't hurt the current users because everyone has installed mksig and sig_gen into the same directory. C'mon you know you like this way better
But I"ll see if I can work Win32::TieRegistry to let mksig know the full address of where it lives in the computer (is that what you're asking?)
As for the auto_update, thanks boss.
That's a great idea you came up with, I was looking though the code and thought, "wow, that's a great application of how Perl thinks." I was going to put a checkbox saying "check for updates at startup". I think I understand what you said in the comments, Perl compiles once and that's it until it's run again?

So far the relative paths work, just like how your original sig_gen stored stfd.html in the mksig directory without directing a absolute path. So if mksig doesn't detect sig, sig_gen, or mksig.conf, wouldn't it create it in the same directory that mksig lives too (just like stfd.html)? Wouldn't this be the way to go, so that we could place mksig.pl in any directory we'd like, without altering the mksig code? Plus, it shouldn't hurt the current users because everyone has installed mksig and sig_gen into the same directory. C'mon you know you like this way better
As for the auto_update, thanks boss.