Getting Cello to open a file brought in a fair number of new files. Objects within the Cello file format are referenced by a unique identifier (actually a GUID) which are constructed from a factory. So adding the code to register the simplest object (a basic shape) with the factory had the effect of bringing in a reasonable number of new files - and once again working through the compile and link errors. The trick here was to be firm with the UI - unlike the underlying files the object files have UI references in them - so I added #if _NO_UI directives about these and their includes to stop any UI being sucked in.Once I had done this (a couple of days ago) Cello opened her first file without crashing. The question then was "well so the read seemed to work but what did it read?" How can I have any certainty (beyond the fact that it did not crash) that everything was read - the file format is complex. My initial solution was to write the file out again and check that the file could be opened with he PC version of Cello.
Getting the write to work took time - there was a problem in the file class for files with a joint read/write access (there was no unit test for this). Having identified the problem I added the unit test and fixed the code by getting the new unit test to work properly.
When the write worked I then checked the files in HexEdit and they where different - it seems that Cello stores the file path of the file at the point of saving in the file. From here came an idea - adding a way that a chosen file-path can be saved will allow some files to be written that will be 100% the same as the original which in turn will allow unit tests for this to be added. Basically I can create tests that will read and write files (the original being a part of in the test bundle) and assert that the two are equal. I very much want to do this so that I find out as soon as possible if something I do breaks Cello.
No comments:
Post a Comment