Okay, so, I commented out the try/catch block in main() and suddenly it aborts when I try to run it! What confuses me is that it wasn't throwing any sort of exceptions before that I did not expect, but the fact that it's aborting implies that there were exceptions being thrown while the try/catch was in operation, but it was somehow continuing silently, without even printing the e.what(). I'm thoroughly confused at the moment.
Right. I found the error - currentElement was never initialized to -1, so it would get to commitText() and then fail miserably. But - no exception was thrown, as far as I can tell, since the try/catch block never fired! So apparently the try/catch block does no work, but if you remove it, it breaks? What the hell is going on? Research that when you get Internet connectivity back!
Right. Fixed and squared.
Intensity links now add properly. Moved the checking logic for intensity links into Outline::canLinkIntensity. Also created a Outline::canLinkExclusive, but the checking logic is still currently duplicated in the main window. Furthermore, added seperate options lists for stricter and looser into the IntensityLinkDialog class. Also put a warning sign up. The dialog could obviously be prettier, but for the moment it works. WIP, and all.
CHRIST. I am livid with myself right now; I just spend half an hour messing around, flailing while trying to debug the simplest problem - the function was removing elements from THE WRONG SET - because I assumed that the function removeExclusiveLink(int i){assertions_for.erase(i);} was so simple that I didn't even check to see if it was doing what I thought it was. That's a) fatal carelessness and b) a sign that I'm, obviously, not coding properly. First off, I've got no tests. Further features will now be put on hold while I go find a tutorial on how to properly write unit tests.
Writing unit tests for the Assertion class. Is this going overboard? Also! decrementReferencedIn() throws an exception if you try to decrement from a Reference whose value is already zero - do we want to keep this behaviour, or should it just floor it at 0?
Found a bug in decrementReferencedIn() - it was actually incrementing it. I feel accomplished.
Done with the tests for Assertion.
Added a new test class for Argument.
Wrote tests for Argument. However, in doing so, I wondered if the current method for adding Intensity Links is sane - it's possible to add to Argument 3 the intensity link (4, 7), which is nonsensical. Two options - change the definition to make it impossible (much like, addIntensityLink(bool _this_is_stricter_than_the_new_one, int _link)) or simply throw a horrible, nasty exception when it's done? Uh, on reflection, let's go with making it impossible.
Finished with writing Argument tests. Changed addIntensityLink() and removeIntensityLink() to saner definitions and changed the implementations to match. Moved Argument implementation into its own .cpp file.
Added a test class for date8601. Changed intended behaviour to throw an exception on invalid date assignment.
Wrote tests for Date8601 for the new behaviour. They fail, of course - will next rewrite the implementation of the functions.
Well that was an easy fix. Done with the Date8601 tests.
Ate the .pro.user files, because I kept accidentally adding them.
Citation tests written, ran.
Wrote, tested Evidence.
Added, tested IntensityLink. Also - having it be a struct with a get() was somewhat silly - it should be either a struct, or a class with proper data hiding. So I eliminated the get() functions and changed all the calls into direct accesses.
Okay, made the decision to rewrite it to place the logic into the data classes instead of Outline. Commiting before beginning.