Interesting CODM error situation

[jrball]

I load my custom organ frequently during development so I am used to getting error messages and fixing them.
Yesterday I got an unusual and persistent error msg:
"Validation failed for the Stoprank object'' - the mandatory attribute 'Stopcode" is not specified." Code 0801.
Nothing could make it go away. There was no error in the stopcode code.
So I deleted selected sections of the code one by one to locate the error.
Finally with all stops, ranks, and stopcodes omitted the real error showed up.
I had placed two enclosures in the same division and the new, correct, HW error msg reported that.
So I replaced all omitted code, fixed the enclosure code and the above error disappeared. It is repeatable.
When the error occurred the "skip all organ validation" did not stop the error msg.

Not really a problem for me since I have seen the same type of error with other coding mistakes before and can fight through them. A few weeks ago a similar spurious HW CODM error was only fixed when I rebooted the PC.
Perhaps there is a subtle bug in the code that requires some thought.

In my distant past I got a contract to instrument a PC operating system looking for longstanding subtle bugs - found them!

[mdyde]

Thanks, John.

I've logged as a bug report that the CODM might give a misleading error message if you mistakenly have more than one enclosure specified as using the same enclosure code (division).

When the error occurred the "skip all organ validation" did not stop the error msg.

Not really a problem for me since I have seen the same type of error with other coding mistakes before and can fight through them. A few weeks ago a similar spurious HW CODM error was only fixed when I rebooted the PC.
Perhaps there is a subtle bug in the code that requires some thought.

You probably realise this anyway, but after making any changes to any ODFs (CODM or full-format), it's very important that you load/compile the ODF *without* having the 'Skip all organ definition validation for speed [caution]' design option ticked, otherwise any errors in your ODF may go unreported and risk crashing Hauptwerk or causing other unexpected behaviour.

[jrball]

Yes, I have never used the skip option until today.
Unfortunately the error came back and now won't go away.
Nothing I can remove helps.
Can I delete the internal caches?

[mdyde]

Hello John,

The sample set cache won't make any difference -- the error message you mentioned is an ODF-loading error, and the ODF is never cached.

Do you mean that the error came back, even in the situation in which it did *not* occur previously (i.e. after you had removed the other things from the CODM ODF to find the culprit enclosure entry)?

[jrball]

Yes, I can remove all of the stop related, etc. stuff and the error persists.
I've got another zoom mtg now so I'll work later and get back to you tomorrow.
Could be a typo in the code that has unwanted effects.

[mdyde]

Thanks, John.

Yes -- it's possible that there's some other mistake in the ODF which Hauptwerk isn't specifically finding and reporting. If after you've had a look for it tomorrow you still haven't been able to solve it and would like me to have a look at it, then please create a diagnostic file (so that we can see the exact error message text, etc.), and send that, along with your minimal CODM ODF, to Francois at support [at] hauptwerk.com . I'll then see whether I can reproduce the error with it, and hopefully pinpoint what's causing it. (Since that will probably take a few hours to look into, and since it's currently the weekend, it might have to wait until Monday.)

[jrball]

Martin, it's gone! Same as happened a few months ago with another spurious error msg.
I deleted a code section, started the load, got the error, restored code, and then moved on to another code section.
Along the way the error disappeared and loading returned to normal.
None of my backups fail now. So far as I know my XML code did not change.

If it happens again I'll archive the XML file send a diagnostic file.

[mdyde]

Thanks, John.