SimpleUpdater — Rev. 10.69 / 2016/06/19

[bdeshi]

Hey, what do you think of this idea?

If currently selected item looks like a XYplorer archive (by name-scheme), then SUpdater menu shows a new option "Update from selected archive"

Why? I sometimes find myself going the long way around, and end up downloading the zips from beta topic. Now when I go back to XYplorer, and see the downloaded file, I'm torn between closing XY >> unzipping it manually or deleting it >> running SU, only to end up redownloading it again. Oh, the torment!

[Marco]

Oh, the torment!

I'll think about it. It's not that straightforward as you may think because
-translations should be updated
-the code should still connect to the internet to get the current etag, and in addition something like filesize to ensure that the selected zip is truly the latest one available on the beta forum.
Mmh, doable...

[bdeshi]

-the code should still connect to the internet to get the current etag, and in addition something like filesize to ensure that the selected zip is truly the latest one available on the beta forum.

You might skip that, when user has a file selected, and chooses that option, then user must be sure the selected file is indeed an update.

[oblivion]

I discovered something.

Afterwards, I took a photo of it and... oops, sorry, wrong forum.

If you run the SimpleUpdater script with XYplorer's current focus being somewhere that's not currently available / writable, the script crashes.

You might think this is obvious... but I have a nasty habit of running SU with the current focus being on a bit of network that's not presently available. Now I know, of course, I can deal with it...

So is there a bug, or is it something weird about my setup that nobody else suffers from?

[Marco]

So is there a bug, or is it something weird about my setup that nobody else suffers from?

Confirmed and fixed, as Don would say
Try the attached build.
Basically, I used the run command with no directory specified. As per Help,

Code: Select all

directory:The working directory, allows you to skip the path in command; defaults to current path.

If the current path is non existent, you get an error.

[Marco]

Does it work?

[bdeshi]

yep.

[oblivion]

Does it work?

Yes.

Sorry, Marco, I've been away from my computer for a couple of days, only just had a chance to test it. Works perfectly!

Many thanks, and sorry again for not getting to it sooner.

[bdeshi]

Would you like to add an option to show the changelog AFTER XYplorer has restarted with update?

[Marco]

Like, showing the CL either before (like now) or after the whole update process?

[bdeshi]

yes, after the update process -- the complete update process, after XYplorer has restarted. Some additions to the ~restartcommandline option.

[bdeshi]

Would you like to add an option to show the changelog AFTER XYplorer has restarted with update?

I tacked on this cmd to RestartCommandLine /script=

Code: Select all

html('http://www.xyplorer.com/xyfc/viewtopic.php?f=1&t=4&sd=d',,,'beta changelog');

meanwhile, there's a bug that if the download fails, the script still continues, and restarts XYplorer for no reason.

[Marco]

Ouch, sorry for the silence, I'm terribly busy with university!

Concerning the bug, I should ask Don to turn SC download into a function so that I can get an errorcode or similar. I can't possibly see any way to control whether a download has failed or not...

[TheQwerty]

Ouch, sorry for the silence, I'm terribly busy with university!

Concerning the bug, I should ask Don to turn SC download into a function so that I can get an errorcode or similar. I can't possibly see any way to control whether a download has failed or not...

You could probably convert the download to a readurl and write the data out yourself. It's not as nice, but it does give you some error checking abilities.

It's also possible to use exists to check URLs, but that might not be too useful depending on how it is failing.

[oblivion]

Silence for ages, then all he does is complain...

First, there's a massive bit of mea culpa here because I wasn't sure where the problem was and was always in too much of a hurry to note the error messages properly.

So SimpleUpdater was working everywhere I used it except for my main desktop PC.

It took me a while to work out why it didn't work. No, that's overstating it. I still don't know exactly why it didn't work, I just know for sure what was causing the problem.

Teracopy.

I use Teracopy occasionally but on my main desktop machine I do a lot of the sort of huge copies that Teracopy handles well, and I had it set to be Windows' default copy handler.

That's the bit I'd forgotten about. I knew Teracopy didn't seem to want to do the SimpleUpdater copy (after extraction of downloaded zipfile) but SU still didn't work properly after I'd told XY just to use its own copy routines. I thought I'd broken something and was ashamed...

Then I accidentally started an instance of TC I could interact with and it occurred to me to look at its options before I closed it again. And there it was. "Use Teracopy as default copy handler." I unchecked it. Since then, SU has worked exactly as it should. (Which is to say, I didn't need to install the last update manually!)

Next time I see an XY update I'll try to replicate the problem and post some more detail or some screenshots or something, but I thought I'd let you know that there's some sort of issue here. I don't know if it might be worth calling xycopy directly to avoid issues with things like teracopy or fastcopy or whatever else a user might want to use for most things...?