Safety net: two configs?

[j_c_hallgren]

Yes, that would be a bummer. Only other way i can think of is, if the contents of the ini is not changed then don't overwrite last config.

Or, don't overwrite if is the same day (modified date), resp. < 24 hours? That way you would always have "Yesterday's INI".

Same day (if strictly defined) could be an issue for someone like me who might be working around midnight and thus have a different result as to how long the prior vers was good for...but the other issue is that if I've intentionally made a series of changes and saved each time over the course of a few hours, this wouldn't allow me to get back to last "good" one but rather maybe the 5th prior one which wouldn't be a help.

Another similar case would be where I've made some intentional config changes and explicitly saved them (pushing old INI to BAK), and then much later that day, did some more undesired/test ones and then exited XY which in my case, does a save (good INI then NOT pushed to BAK)...the first intended set of changes wouldn't then be able to be recovered from BAK, right?

So...I most DEFINTELY think that not overwriting unless chgs have occured is the preferable way to do it...that would allow for multiple start/exit cycles but still keep the BAK intact.

[admin]

Yes, that would be a bummer. Only other way i can think of is, if the contents of the ini is not changed then don't overwrite last config.

Or, don't overwrite if is the same day (modified date), resp. < 24 hours? That way you would always have "Yesterday's INI".

Same day (if strictly defined) could be an issue for someone like me who might be working around midnight and thus have a different result as to how long the prior vers was good for...but the other issue is that if I've intentionally made a series of changes and saved each time over the course of a few hours, this wouldn't allow me to get back to last "good" one but rather maybe the 5th prior one which wouldn't be a help.

Another similar case would be where I've made some intentional config changes and explicitly saved them (pushing old INI to BAK), and then much later that day, did some more undesired/test ones and then exited XY which in my case, does a save (good INI then NOT pushed to BAK)...the first intended set of changes wouldn't then be able to be recovered from BAK, right?

So...I most DEFINTELY think that not overwriting unless chgs have occured is the preferable way to do it...that would allow for multiple start/exit cycles but still keep the BAK intact.

But changes can be a very minor thing, like opening a tab, moving the window, changing a folder... a user who thinks things are not as they should usually tries something before he gives up.

[j_c_hallgren]

But changes can be a very minor thing, like opening a tab, moving the window, changing a folder... a user who thinks things are not as they should usually tries something before he gives up.

Ok...yes....agree...I guess I was thinking mostly about those changes that are only done by using "Config" dialog (and maybe ticking/unticking on menu?) as those are types of chgs that I think of as more permanant and likely not to be remembered whereas opening tab or such as you listed is a temporary thing in that it can more easily be noticed visually and redone if needed.

[admin]

But changes can be a very minor thing, like opening a tab, moving the window, changing a folder... a user who thinks things are not as they should usually tries something before he gives up.

Ok...yes....agree...I guess I was thinking mostly about those changes that are only done by using "Config" dialog (and maybe ticking/unticking on menu?) as those are types of chgs that I think of as more permanant and likely not to be remembered whereas opening tab or such as you listed is a temporary thing in that it can more easily be noticed visually and redone if needed.

It would be extremely cumbersome to determine programmatically whether a relevant change was made or not. I don't think there is a solution here.

I still think that making an automatic backup of the INI if the last backup is older than 24 hours would give at least a little comfort for a sufficient number of users. One could even make the number of days configurable (0 = no auto-backup; 1 = 24 hours, 2 = 48 hours, etc.).

[j_c_hallgren]

Ok...yes....agree...I guess I was thinking mostly about those changes that are only done by using "Config" dialog (and maybe ticking/unticking on menu?) as those are types of chgs that I think of as more permanant and likely not to be remembered whereas opening tab or such as you listed is a temporary thing in that it can more easily be noticed visually and redone if needed.

It would be extremely cumbersome to determine programmatically whether a relevant change was made or not. I don't think there is a solution here.

I still think that making an automatic backup of the INI if the last backup is older than 24 hours would give at least a little comfort for a sufficient number of users. One could even make the number of days configurable (0 = no auto-backup; 1 = 24 hours, 2 = 48 hours, etc.).

Understand the challenge...so then as long as there also was some option for users like myself who'd like to have the INI pushed to BAK on each/every save no matter the time since last, because we'd like to not lose a series of updates if we wanted to just go back one step.

[serendipity]

Ok...yes....agree...I guess I was thinking mostly about those changes that are only done by using "Config" dialog (and maybe ticking/unticking on menu?) as those are types of chgs that I think of as more permanant and likely not to be remembered whereas opening tab or such as you listed is a temporary thing in that it can more easily be noticed visually and redone if needed.

It would be extremely cumbersome to determine programmatically whether a relevant change was made or not. I don't think there is a solution here.

I still think that making an automatic backup of the INI if the last backup is older than 24 hours would give at least a little comfort for a sufficient number of users. One could even make the number of days configurable (0 = no auto-backup; 1 = 24 hours, 2 = 48 hours, etc.).

Understand the challenge...so then as long as there also was some option for users like myself who'd like to have the INI pushed to BAK on each/every save no matter the time since last, because we'd like to not lose a series of updates if we wanted to just go back one step.

I see both points. How about a default value of 24 hours which is automatic and a value to turn on manual mode?
If i save my config when manual mode tweak in ON, unsaved config is backed up to BAK and saved config is saved to current config.

[admin]

Ok...yes....agree...I guess I was thinking mostly about those changes that are only done by using "Config" dialog (and maybe ticking/unticking on menu?) as those are types of chgs that I think of as more permanant and likely not to be remembered whereas opening tab or such as you listed is a temporary thing in that it can more easily be noticed visually and redone if needed.

It would be extremely cumbersome to determine programmatically whether a relevant change was made or not. I don't think there is a solution here.

I still think that making an automatic backup of the INI if the last backup is older than 24 hours would give at least a little comfort for a sufficient number of users. One could even make the number of days configurable (0 = no auto-backup; 1 = 24 hours, 2 = 48 hours, etc.).

Understand the challenge...so then as long as there also was some option for users like myself who'd like to have the INI pushed to BAK on each/every save no matter the time since last, because we'd like to not lose a series of updates if we wanted to just go back one step.

I see both points. How about a default value of 24 hours which is automatic and a value to turn on manual mode?
If i save my config when manual mode tweak in ON, unsaved config is backed up to BAK and saved config is saved to current config.

Feels too complex. For me this is a feature mainly for users that are unfamiliar with the idea of backups and how and when you should do them. The feature must be very simple or it will fail its purpose.

BTW, and I think zer0 already said it, it's quite easy to write a user button that will make an unconditional backup of the current INI file before saving to it.

[serendipity]

Feels too complex. For me this is a feature mainly for users that are unfamiliar with the idea of backups and how and when you should do them. The feature must be very simple or it will fail its purpose.

BTW, and I think zer0 already said it, it's quite easy to write a user button that will make an unconditional backup of the current INI file before saving to it.

Yes, you are right. Backup every 24 or 48 hrs would work well for most users who don't want to deal with scripting.

[rhoelzl]

I would suggest placing the config files in your Dropbox. Instant versioning.

Alternatively, you can use the Windows Shadow Copy feature.

[serendipity]

I would suggest placing the config files in your Dropbox. Instant versioning.

Alternatively, you can use the Windows Shadow Copy feature.

Oh no! i do regularly backup my config. I am suggesting this as i've seen many posts where someone loses his/her config and has to start from scratch.

@Don: I was wondering about another way of autobackup. Instead of every 24hrs etc is it possible for XY to know how many changes have been made?
For example can XY save my config automatically after say 10 or 20 changes made to my config? Every checkbox, field is a change. This way might be better as i could make significant changes in one 24hr period compared to another 24hr period and losing one over other makes a huge difference.
I don't want to suggest something that would take up too much of your time or is resource a hog. Just throwing out ideas there.

[j_c_hallgren]

I see both points. How about a default value of 24 hours which is automatic and a value to turn on manual mode?
If i save my config when manual mode tweak in ON, unsaved config is backed up to BAK and saved config is saved to current config.

I agree that this would likely handle most all cases and compared to having various values for nbr of days, this could be a simple switch/on-off...cause having it in manual mode is just an enhanced setup compared to now and would allow users like me to have a backup all the time (knowing that it's going to be overwritten on very next save) and would help the others to at least not lose more than to prior day.

[admin]

I would suggest placing the config files in your Dropbox. Instant versioning.

Alternatively, you can use the Windows Shadow Copy feature.

Oh no! i do regularly backup my config. I am suggesting this as i've seen many posts where someone loses his/her config and has to start from scratch.

@Don: I was wondering about another way of autobackup. Instead of every 24hrs etc is it possible for XY to know how many changes have been made?
For example can XY save my config automatically after say 10 or 20 changes made to my config? Every checkbox, field is a change. This way might be better as i could make significant changes in one 24hr period compared to another 24hr period and losing one over other makes a huge difference.
I don't want to suggest something that would take up too much of your time or is resource a hog. Just throwing out ideas there.

No, that's almost impossible.

Generally, I will wait a little before I do anything into that direction. It's not ripe yet.

[serendipity]

I would suggest placing the config files in your Dropbox. Instant versioning.

Alternatively, you can use the Windows Shadow Copy feature.

Oh no! i do regularly backup my config. I am suggesting this as i've seen many posts where someone loses his/her config and has to start from scratch.

@Don: I was wondering about another way of autobackup. Instead of every 24hrs etc is it possible for XY to know how many changes have been made?
For example can XY save my config automatically after say 10 or 20 changes made to my config? Every checkbox, field is a change. This way might be better as i could make significant changes in one 24hr period compared to another 24hr period and losing one over other makes a huge difference.
I don't want to suggest something that would take up too much of your time or is resource a hog. Just throwing out ideas there.

No, that's almost impossible.

Generally, I will wait a little before I do anything into that direction. It's not ripe yet.

Although i suggested this, only you can determine if this is truly necessary depending on how often you receive complaints about lost settings (which do happen in event of crash or unexpected shutdown). Meanwhile maybe one of us can put out a script for those in need.
PS: Is it possible to trigger a script just before exiting XY?

[admin]

Generally, I will wait a little before I do anything into that direction. It's not ripe yet.

Although i suggested this, only you can determine if this is truly necessary depending on how often you receive complaints about lost settings (which do happen in event of crash or unexpected shutdown). Meanwhile maybe one of us can put out a script for those in need.
PS: Is it possible to trigger a script just before exiting XY?[/quote]
Well, not so often actually.

No, not possible. CEA will cover this in future.