OK, I see how the PRIMARY_ROOT path option works now. Still, as I said my previous post, I'm lazy and just want to click yes/no, not have to set/unset a path each time.
extra checkbox noted down on wishlist
As for the sig ref, I think it will require trunk modification as I've outlined above.
don't think it's absolutely necessary ... i think i can do the following: check for presence of sig_ref_etc.bin files - if not
present: option disabled, if present: checkbox to select use / don't use. If user opts out of sig_reffing then rename *.bin -> *.bio or whatever. I agree it would be best to implement it in a similar way as PRIMARY_ROOT, it could then benefit all developers.
Is there a reason why the exe has to have the version number in it and not be generic? (D:\CHDK\CHDK-Shell.exe). I suppose the shell updater could toss the old .exe into a backup directory if it is intended to be kept and not merely overwritten for some reason.
yes there is: since auto-update that's impossible, an exe that's in use can't overwrite itself: there is no shell updater, the new version gets started by it's predecessor
How about an alternative: options to create shortcut at user specified location and to delete old versions ?
I realise versioned exe names can be a pain, but they sure make developing & archiving a lot less error prone for me - i regularly have 20 exe's + au3's in the same path, and my otherwise almost unlimited tolerance for chaos does not extend to my own source code folders
..which results in the following 'to do list':
- checkbox for primary use
- detect sig_ref bins and present on/off toggle if found
- options to create/maintain shortcut and delete exe's except last x version(s)
anything else ?
wim