Via @include.Yincognito wrote: ↑January 17th, 2021, 7:33 pm Just curious, when you say "import", what do you mean by it? Copying the contents of the backed-up file to the new file, reading it with WebParser, @Include it, or some other technique I'm not aware of?
Since we're at it, this is a good idea, cause I'm thinking one doesn't even need a command to run on the first skin activation - it can be done much easier (not that the already available soutions are complicated, of course), by simply @Including both the "new" (presumably, empty) variables file AND the "old" (i.e. backed-up) variables file in the skin ... but in this order, so that the backed-up variable values would overwrite the possible values in the new file. Like:Obviously, #ROOTCONFIG#\@Resources can be replaced by, say, #CURRENTCONFIG#\@Resources, or whatever your actual relative path to the variables file is. So, in the above code, the "old" variables file's values would overwrite similar values from the "new" variables file since the former's inclusion comes after the latter's one, in effect preserving old existing variable values. Unless there is some same section name conflict (since all section names must be unique in the INI format, and I didn't test the approach to see if it works) that would prevent this from happening, this could be enough...Code: Select all
[Variables] @IncludeVariables=#@#Variables.inc @IncludeBackedUpVariables=#SKINSPATH#@Backup\#ROOTCONFIG#\@Resources\Variables.inc
P.S. I'm not sure whether the backed-up file's inclusion would fail silently if that file doesn't exist or would generate a Log error, but in any case, I believe this wouldn't prevent the functionality. The only question is regarding same section name, but even that can probably be easily avoided.
In fact I had the exact same question raised as balala's in my mind before. And I decided that I would try including a file with variables from @backup folder and then with bunch of !WriteKeyValues write the values back.
But this implies you know which keys you are "importing". This depends on your case as you can change the key names overtime after several updates. It would be easier for anyone just to keep your variable names same as before. Or prepare some "legacy" keys to import if you completely overhaul your skin and change all the key names. So you need to be careful about your scenarios and keep in mind peculiarities about your skin and how the "import" works for you.
For myself I wanted to make sort of a "module" (separate .inc file) which would:
1. Run once after my skin is installed.
2. @include the file(s) in question from @backup.
3. !WriteKeyValue your keys into my main place with variables.
4. Remove itself with !WriteKeyValue from loading itself (@include=import_module.inc –> @include=).