All of the file & related classes in Cello now compile. So I have a folder full of files 'ticked off'. This part of the project took longer and was more painful than I had imagined - simply because structured storage was an unexpected wrinkle.
POLE, the structured storage library I have deployed will only read structured storage files and won't write them. Looking at the code there seems to have been a reasonable start in getting the writing part of POLE completed but it is not close to being finished. It is something that I am reluctant to undertake. POLE amongst other things was the only non-GPL C/C++ library that I found.
The initial part of the Cello port is to get enough together to open files generated on the PC version and for the code to run to generate the output. So to deal with the issue of writing I have
'stubbed-out' all of Cello that butts onto the structured storage writing and to defer the issue. Though it would be nice to be able to write file in the existing format it is not essential.
Showing posts with label POLE. Show all posts
Showing posts with label POLE. Show all posts
Thursday, May 15, 2008
Friday, May 9, 2008
Testing and POLE Dancing
Pressing on with deploying POLE I am starting to look at Unit testing. The idea is to be able to test the new iterator before deploying it. Ideas like this are nothing new in the programing world - but coming from a project that is old, a little out of control and never had any unit testing it is good to deploy a little rigor. What I am hoping to gain from this is to eliminate unknowns and upfront and remove some of the uncertainties with POLE.
XCode comes with two built in unit test frameworks CPlusTest for C & C++, and OCUnit for Objective-C. There are other unit test frameworks around, and I note a particularly good post in Dave Dribin's Blog. I have elected to go with the CPlusTest despite Dave Dribin's reservations - the integration with XCode is good and I also plan use OCUnit when I come to start work on the UI.
CPlusTest is horribly easy to use - you set up a new target in your XCode project just choose Unit test Bundle from the list of possible targets, and then choose the C++ Test Case when you add a new file. XCode drops in a stub class to fill in. You have to register our test cases in the file - it is basic boiler plate stuff and Apple's documentation is quite clear. I only mention these steps to give an idea of how simple it is.
With CPlusTest you choose when you want the test cases to be run - they will either run every time you build your main target or just as a part of the building the test target. Test failures are logged as errors in your test file as were they compiler errors. This struck me as a little odd but it is quite convenient as you are reasonably close to the problem area when you get a test failure - you can command-double-click through the identifiers to where you need to be quite quickly.
The last unit testing I did was many years ago with a particularly grim piece of code called The Test Harness back in the days where real men spat Fortran - the ease with which unit testing can be deployed deployed now really is a pleasure.
XCode comes with two built in unit test frameworks CPlusTest for C & C++, and OCUnit for Objective-C. There are other unit test frameworks around, and I note a particularly good post in Dave Dribin's Blog. I have elected to go with the CPlusTest despite Dave Dribin's reservations - the integration with XCode is good and I also plan use OCUnit when I come to start work on the UI.
CPlusTest is horribly easy to use - you set up a new target in your XCode project just choose Unit test Bundle from the list of possible targets, and then choose the C++ Test Case when you add a new file. XCode drops in a stub class to fill in. You have to register our test cases in the file - it is basic boiler plate stuff and Apple's documentation is quite clear. I only mention these steps to give an idea of how simple it is.
With CPlusTest you choose when you want the test cases to be run - they will either run every time you build your main target or just as a part of the building the test target. Test failures are logged as errors in your test file as were they compiler errors. This struck me as a little odd but it is quite convenient as you are reasonably close to the problem area when you get a test failure - you can command-double-click through the identifiers to where you need to be quite quickly.
The last unit testing I did was many years ago with a particularly grim piece of code called The Test Harness back in the days where real men spat Fortran - the ease with which unit testing can be deployed deployed now really is a pleasure.
Tuesday, May 6, 2008
Structured Storage
I have got through the first set of utilities and have started on the nitty-gritty of the file operations. A first look at a file called DWEditFile it seems like Cello uses Structured Storage. Coming from OSX this was the first time I have come across this technology, which is proprietary to Microsoft, and not available under OSX.
Usefull Liks:
There are a couple of open source projects that will read and write Structured Storage documents.
POLE seems to very lightweight, and straight forward. Looking through the code, on the surface, it lacks:
The final thing that is different is that the way of accessing different parts of the document (structured documents are hierarchical) using POLE is very different to the windows. MFC seems to have iterators that will iterate through a given part of the document structure. I wonder if the best way to deal with this would to build an iterator like the MFC one on top of POLE - which minimizes the changes that will need to be made to to Cello. Also I can write a separate test code for this.
After doing the easy part of deploying POLE I had some problems understanding how the existing code worked and how to port it onto POLE. Strangely the DWEditFile is not the main document file (a bad assumption on my part) - the thing now is to figure out where it is used. It could be a skeleton.
Usefull Liks:
There are a couple of open source projects that will read and write Structured Storage documents.
POLE seems to very lightweight, and straight forward. Looking through the code, on the surface, it lacks:
- Some exception handling.
- A copy operation - for copying bits of one document into another. This is something that Cello uses.
The final thing that is different is that the way of accessing different parts of the document (structured documents are hierarchical) using POLE is very different to the windows. MFC seems to have iterators that will iterate through a given part of the document structure. I wonder if the best way to deal with this would to build an iterator like the MFC one on top of POLE - which minimizes the changes that will need to be made to to Cello. Also I can write a separate test code for this.
After doing the easy part of deploying POLE I had some problems understanding how the existing code worked and how to port it onto POLE. Strangely the DWEditFile is not the main document file (a bad assumption on my part) - the thing now is to figure out where it is used. It could be a skeleton.
Subscribe to:
Posts (Atom)
