I tested and confirmed that the suspected problem was indeed a problem and fixed it. In the process I discovered that I had neglected to set up a relationship in the schema between the Solidity table and the SolidityShape table. This was the cause of a problem I ran into a couple days ago that forced me to manually specify the value of the "SolidityName" column in the Solidity table when the grid added a new row. It was really bugging me that it wasn't doing that automatically and I couldn't figure out why so I finally gave up and did it manually when a new row was added. I'm so glad I found the right/easy way to make this work. I like deleting unnecessary code. Of course it's always preferrable to get it right in the first place, but at least when you're deleting code, you know you're headed toward more simplicity and in the right direction. The good news is, there's a whole lot of "simplicity" going on in this project so far. A lot of it just feels right.
For those who may be interested, the thing I have discovered about Microsoft's XML schema generator and the way that Visual Studio generates code from it, there are interesting ways that nested parent-child relationships need to be set up. I tried a number of things and finally finally found the "simple" solution there too a while back:
1. If you create a parent table and a child table without making the child table an element in the parent (without nesting them) you can set up a relationship in the schema between the tables, and you will get nice functions for retrieving related records generated for you. However, when the XML data is written to a file, the data is not nested. It comes out just as two flat lists of data, and every child item has to include and repeat all the parent value keys in each record in order to maintain the relationship.
2. If you nest one table as an element in the other, then you can get the nice relationships in the XML -- it's all hierarchical like XML should be and the child elements don't have to explicitly show the values of the parent keys because they are implied by the nesting. However, then you run into a problem in the generated code where there's an implicit relatipnship that is maintained entirely separately from the explicitly listed columns. So, for example, my "Solidity" table has a "Name" column, and my SolidityShape child table has a "SolidityName" column that related each child record to the parent Solidity record. But now the code generator will generate an implicit "Name" column on the SolidityShape table to relate it to the parent Solidity records (when it sees that it is a nested element)... Agh!
3. Finally I discovered that if you nest the child table as an element in the parent table and also set up a relationship based on the parent table's primary key (and set the relationship's "nested" property to true), then the code generator appears to utilize this relationship to consolidate it's understanding of the relationship into a simpler entity... so that both the XML generation and the generated columns and methods all come out just like you want them. You have generated methods that will return a child record's parent, to return the parent record's children, and all the columns are set up just once and, apparently, the framework code that wants to use the schema to create new rows now knows how to automatically relate child records to their proper parents.
Whew! And so I forgot this one relationship and I didn't notice that it was missing when I started seeing these problems until I was testing this other problem. But I'm glad it made itself noticed to I could delete some unnecessary code! It looks like the Solidity definition UI is working nicely now. It's not very keyboard accessible yet (almost have to use the mouse), but I'll leave that for another day... it's late.