by Unknown user
When I sat down to write add all the new persistence code into my UI example program I realized that while I could load data from the persister into the ManyToManyLinks instance and have those checkboxes appear checked in my listbox, I had no way of communicating the user's selection of a record back to the ManyToManyLinks instance.
...
With these changes I could run my UITest program and have my checkbox settings loaded on startup and saved on exit with the Links.Load() and Links.Save() method calls.
Cleaning up the code
But there were still a few things that bothered me about the code. For one, while I'd created a class to maintain the queue of record associations, the class really didn't add any value. It was simply a container for the class. So I got rid of the class and declared the queue type in CML_Data_ManyToManyLinksDataQ.inc:
...
Everywhere I had previously used the class and the queue reference, I now used just the queue reference. That took a bit of searching and replacing, and when I was done I ran my unit tests again to make sure I hadn't messed anything up.
Storing data efficiently
Another thing I didn't like about the class was the brute force approach to saving data. If I had fifty linking records and I removed one of them, why not just remove that single record instead of wiping out all the records and recreating all but one?
...
That meant my ClearLinkBetween method could no longer assume the mere presence of a linking record. I changed the code to this:
| Code Block |
|---|
CML_Data_ManyToManyLinks.ClearLinkBetween procedure(long leftRecordID,long rightRecordID)
code
if self.GetLinkRecord(leftRecordID,rightRecordID)
self.LinksDataQ.IsLinked = FALSE
put(self.LinksDataQ)
end |
...
There's still work to be done here, not least of which is adding some measure of error handling. But this code does work. The unit tests pass, and in my UITest program my checkbox settings are preserved between runs.
Next time, a summary of the work done to date.