XYplorer Beta Club

...or similar. We already have "Save Settings On Exit" (which I have ticked), but the following happened:
a) Edited some scripts, saved, applied, tried to use them and they worked.
b) XYplorer crashed
c) XYplorer restarted, script changes in a) have not been saved.

Yes, there is a manual way of saving settings, but just in case XY misbehaves itself the settings should are saved nonetheless. After all, crash is a form of exiting

P.S. With Firefox, the session is saved in an event of a crash so stuff like settings/tabs etc are preserved.

Stop wasting my time.

admin wrote:Stop wasting my time.

That's always nice to hear!
It's a fact that XYplorer doesn't proactively save user's settings. If you make some changes, don't save them manually or by restarting, and then XYplorer crashes then those changes wouldn't have been preserved. Not particularly useful if you spend a lot of time manually editing a script so it conforms to new standards. All I'm saying is that if you have made changes in, for example, your UDC window and then click OK to close it then it should be the equivalent of going to File --> Settings --> Save UDC Commands. In my opinion, doing so is very logical...

ivan wrote:Yes, there is a manual way of saving settings, but just in case XY misbehaves itself the settings should are saved nonetheless. After all, crash is a form of exiting

Don has already given his opinion, but I just had to reply...

When a app crashes, it's closer to a BSOD (IMO), so you will lose something! If you've done something that you don't want to lose, it's up to you to save along the way when the app doesn't have an auto-save feature (and...NO, I don't want that!) so that if either the app or your OS fails, you don't lose more than you're willing to redo.

I'd suggest you configure a KS to do the needed saves more easily, and maybe when onEvent is added to scripting, this might assist in this also.

j_c_hallgren wrote:I'd suggest you configure a KS to do the needed saves more easily, and maybe when onEvent is added to scripting, this might assist in this also.

Thank you. I was able to configure a KS to do the job. Now that I got used to Firefox doing it, I was half-hoping it would be a good idea that every app that I use that saves data of some kind preserves it in an event of a crash automatically.

ivan wrote:Now that I got used to Firefox doing it, I was half-hoping it would be a good idea that every app that I use that saves data of some kind preserves it in an event of a crash automatically.

Glad that the KS helped! And it would appear that FF is doing a variant of auto-save because once the app crashes (in many cases), there is NO way to continue doing anything else...it's like a car running into a wall...items that aren't tied down or put away will go flying.

j_c_hallgren wrote:And it would appear that FF is doing a variant of auto-save because once the app crashes (in many cases)...

I think that implementing auto-save would be a good idea. After all, once I do the necessary editing, click Apply and then OK, I was fully confident and assumed that settings would be saved. It seems I have some broken logic...

ivan wrote:I was fully confident and assumed that settings would be saved.

No, with some rare exceptions, XY relies on the user to decide if/when settings are saved, which I think is satisfactory at this time...yes, there are a large number of apps that have auto-save and if you are used to that style, then XY takes a bit of getting used to...and I've lost a couple of settings myself over time in XY, so I can relate.

Maybe at some point, some auto-save ability would make it better for those who prefer it, but I think there are other things that are more important first...and...as stated, there just might be some ability via OnEvent that could help...so let's explore that option first when Don gets to that.

j_c_hallgren wrote:No, with some rare exceptions, XY relies on the user to decide if/when settings are saved, which I think is satisfactory at this time...yes, there are a large number of apps that have auto-save and if you are used to that style, then XY takes a bit of getting used to...and I've lost a couple of settings myself over time in XY, so I can relate.

Maybe at some point, some auto-save ability would make it better for those who prefer it, but I think there are other things that are more important first...and...as stated, there just might be some ability via OnEvent that could help...so let's explore that option first when Don gets to that.

Sure, for now a KS will do the job providing I readjust I hope some (optional) auto-save ability would be possible in the future.

Just another quick thought and opinion about this topic:
I'm with JC on this one, how should an app do a "save settings" just before it crashes, without doing an autosave all the time? If the crash would announce itself beforehand with a msg like "will crash in 2 mins..." I would still prefer some action to be taken to prevent that crash, instead of saving settings I'm not even sure I want to save. Which leads to the second point: If an app crashes, how am I to know it didn't change some settings just before the crash? And I definitely don't wanna take that risk, I rather start again with settings, I know worked before.

Tip: To save your work on scripts independent of XY's settings and out of harms way in case of a crash, organise them in script files, since you have to save those before testing anyway, so all you might loose is your catalog entry or UDC to start it.

Well when we get onEvent actions, you can write a script to save all settings and hopefully Don can provide an "On Unexpected Crash" action that you can assign it to.


On a more serious note, with onEvent scripting Don should be able to provide some Timer events, so you could have a script that gets triggered every five minutes that just executes Save All Settings, which will get everything but the Try Script dialog and current Quick Script.

In the meantime if you think the script you're writing may crash XY and you want to save both the script and the settings just start it with: Though you might want to change the <date yyyymmddhhnnss> to something else (like your own unique script identifier) so that it doesn't create a new key every second you run the script.

RalphM wrote:Just another quick thought and opinion about this topic:
I'm with JC on this one, how should an app do a "save settings" just before it crashes, without doing an autosave all the time? If the crash would announce itself beforehand with a msg like "will crash in 2 mins..." I would still prefer some action to be taken to prevent that crash, instead of saving settings I'm not even sure I want to save. Which leads to the second point: If an app crashes, how am I to know it didn't change some settings just before the crash? And I definitely don't wanna take that risk, I rather start again with settings, I know worked before.

While perhaps "just before crash" kind of save is a little over the top, since I can think of no other way apart from an app doing auto-save all the time. However, there are some distinct hoops through which one jumps to give him/her an impression that settings are saved. For example, I create a UDC. I set everything as I want, I click Apply in Command Properties box and the click OK in the main UDC box and even after doing those 2 bold actions that UDC is still isn't safe in case of an app crash. Why clicking Apply and then OK in UDC window cannot be equivalent to #187? Similar would apply to other parts of "Settings". The extra hoop to jump through seems to escape conventional wisdom

ivan wrote:Why clicking Apply and then OK in UDC window cannot be equivalent to #187? Similar would apply to other parts of "Settings". The extra hoop to jump through seems to escape conventional wisdom

Not wanting to drag this out, but as I had written before

XY relies on the user to decide if/when settings are saved
...yes, there are a large number of apps that have auto-save and if you are used to that style, then XY takes a bit of getting used to

I have seen a large nbr of app's and they generally fall into either the auto or manual save mode. XY is in the manual catagory and you may have had more experience with the auto style...so while it may have disadvantages to you, it has advantages to some of us, ok?

j_c_hallgren wrote:I have seen a large nbr of app's and they generally fall into either the auto or manual save mode. XY is in the manual catagory and you may have had more experience with the auto style...so while it may have disadvantages to you, it has advantages to some of us, ok?

However, the "Apply & OK" method that I have described is not the same as auto-save. Auto-save, in my mind, is a process that runs within XY and periodically executes #182. There clearly seems to be a distinction between an applied setting and a saved setting, because a setting can be in effect but it doesn't mean it's saved. I'm struggling why someone would want a setting to be applied but wouldn't want it to be saved. Testing can be one situation, but then if a setting messes things up then go back, change it, apply it (which saves) and try again.

ivan wrote:However, the "Apply & OK" method that I have described is not the same as auto-save. Auto-save, in my mind, is a process that runs within XY and periodically executes #182.

Agreed! My terminology maybe wasn't the ideal as what I meant by auto vs auto-save was the saving when changed vs saving every x interval.

It may be a struggle for you, but I've run into other apps that work the same way, so it's just a matter of knowing which app does what method.