[RoaldLarsen]

Originally Posted by JScones

Erm, I tested the same condition as you stated in your earlier post. Specific data is irrelevent when one is testing underlying logic.

[and]

Originally Posted by JScones

So, now looking beyond mere data, look at my test code again and you will see that it writes to the same file multiple times in non-sequential order. Is that (logically) what you were trying to do? Yes, it is.

You tested the logic in the code that processes a different file. There is nothing in the user documentation that says you use common processes to process all the files. I cannot assume that you necessarily wrote your code to use one standard routine to process all your files. Therefore I cannot assume that when you test the same sort of condition in a different file that you are testing the same code.

Originally Posted by JScones

I mean, you can test your data all day long, but put simply, garbage in equals garbage out. And from looking at your code snippet it's obvious that you never validated your input data structure. Fail to you.

My input data was consistent with the instructions actually written in Static settings.cfg, just not consistent with what you meant. If you write poorly worded instructions - if you assign multiple meanings to the same or very similar terms without alerting your readers to the fact that you are doing this - you cannot expect people to understand what you mean. They will do what you say, not what you meant to say.

Originally Posted by JScones

Heck, I didn't even need to run a specific test - all one needs to do is look at the "fuller" Randomised events.cfg file to see the same condition in action (it does exactly what you are trying to do, so is even further evidence that your problem must be user - so I'm not sure what further evidence I would need in order for it to be considered "sufficient"? Ironically, my evidence is much greater than your simple and repetitive data test).

When I encountered the failure to write all the changes I wanted to make to Basic.cfg, I was attempting to make those changes by using Static settings.cfg, not Randomized events.cfg. I had no reason to read Randomized events.cfg. I had not read Randomized events.cfg. One shouldn't have to read a different file to understand that the wording in the header of Static settings.cfg is misleading, and that one shouldn't follow its directions literally if one wishes to be successful (unless, OFC, that 'other file' is a manual, errata list, or similar publication).

Originally Posted by JScones

So...why then would my code work and yours not?

Because you knew what you meant when you used two very similar terms to mean two very different things in the same file header.

Originally Posted by JScones

Look at my sample again and compare to yours. You will notice a very fundamental difference. Why? Because I FOLLOWED THE INSTRUCTIONS IN THE FILE HEADER!
...
Heck, the instructions even tell you what to do...

;*Prefix each repeated section name with #: to ensure that the name is unique.

No you followed the instructions you meant to give, but not the instructions you actually gave.

To quote more completely from the comments in the file:

;USAGE:
;[Name of the file including the full path from the "data\" level]*
;ApplyToPeriod=<Start date as YYYYMMDD>|<End date as YYYYMMDD>**
;<SectionName>|<KeyName>=<Setting> for text files OR
;<Offset value>=<Setting> for binary files (do not include comments)
;
;*Prefix each repeated section name with #: to ensure that the name is unique.

According to your syntax guide, SectionName is the thing that goes before the vertical bar on the same line as the KeyName. I don't have any repeats of these. I have repeats of file names. When I see an instruction about repeated section names, I can quite easily conceive that one might want to use a given value of SectionName repeatedly. I didn't need to refer to the same section more than once, so I assumed that this instruction did not apply to me. I have no good reason when I read this instruction to infer that "section name" refers to something other than SectionName.

And yes, I see the little asterisk at the end of the line and at the beginning of the instruction about using prefixes. That does not make it clear that use of the term "section name" in the instruction refers to Name of the file including the full path from the "data\" level rather than SectionName, because a user could just as well conclude that you are referring to repeated reference to a section within a file.

And yes, I understand how the use of file names in square brackets divides the Static settings.cfg into parts that one could call "sections", and that therefore one could say that the file names become "section names"[1], just as SectionNames [2] are section names[3], except that filenames that become "section names" are not SectionNames because they are section names in a different type of file. One could say that, but you don't actually say that anywhere do you? And you know what? That's just shoddy use of terminology. Its the sort of thing that leads to people not understanding what you intend. Its the sort of thing that a proper documentation review would catch and send back for a rewrite. It's a common practice in good user documentation to avoid using the same term in multiple ways, or using two very similar terms with widely variant meanings, and when one is doing something that could be at all ambiguous to provide very clear explanations.

Originally Posted by JScones

Now, if you really understood file I/O you would understand why this requirement is necessary.

I know enough about file I/O to know that there are more robust and elegant approaches to dealing with multiple references to the same file. And I know that with these approaches, requiring the user to prefix repeated references with unique numeric tags is not necessary.

So put it down to user error if you like. Now that we know what is going on I can confidently say that where I worked before comfortably retiring from the software industry in my 40s, we'd file it under "product defect". We'd also probably send the prefixing requirement back for a redesign. Neither of these would reflect very badly in the performance review of a junior programmer, but treating users (dumb or otherwise) the way you do would get you one warning before costing you your job.

I really like SH3 Commander. It is generally a very useful utility, and reasonably stable. I use version 2.7 a lot, and will soon upgrade to version 3.x. I am truly greatful that you spent the time and effort to create and upgrade it. If 2.7 has a weakness, it is in its user interface. Sort of like its programmer.

Grow some skin.


--------------------------------------------------------------------

[1]"Section names" = the things referred to in the asterisked instruction about using numeric prefixes - the names of sections in the Static settings.cfg file. These names will have as values the pathnames of the SH3 configuration files you wish to modify by using Static settings.cfg. A "Section name"[1] is a section name[3] but not a SectionName[2]

[2]SectionNames = syntax element of a command in the Static settings.cfg file. This element specifies the section name[3] in the sh3 configuration file which you wish to modify.

[3]Section name = (used without quotation marks or colour), refers generically to the name of a section in a file, or more particularly to the name appearing in square brackets at the start of a section of a file which is composed of sections delimited by section names[3] appearing in square brackets at the beginning of the section.