Re-inventing the wheel...
Well, tonight has been fun. My laptop randomly decided that the license was no longer genuine. This being the laptop I have painstakingly gone to the efforts to pirate nothing on. I don't even have office on this machine because I don't own a legit copy. Anyway, re-inputting the serial from the bottom of my laptop seemed to make it happy. Why I don't know... I would assume the key on the bottom was the same one it shipped with that it randomly decided was now illegal. Anyway, got passed that.
Onto the fun. So I sat around in my wonderful illusion that everything would be 100 times better than last time when I finally got to the task of printing reports. I was wrong. It has been terrible. I first looked at Code Reasons open source reporting software long before I had even looked at WPF. They touted being a WPF printing solution that did documents in WPF. Well they were part right... I suppose I would even say 75% correct. Where I'm going with this is, having spent some time with XAML, WPF and Silverlight I wanted to create much richer reports with all of the new skills I had acquired. However, the FlowDocument control being utilized doesn't support data binding, in fact the reporting library really only officially supports using their home brew elements for getting data into the reports in a consistent manner. This is no fault of the developers I suppose, I did some research and people had found ways to hack data binding into FlowDocuments, but none were elegant or simple.
So, I spent the night contriving much more complicated solutions only to arrive at one so stupidly simple I feel I should flog myself for having not tried it earlier. There is part of what I have that I arrived at via my long and convoluted approach at least. Basically, I can create an XPS document from any control. So I simply create my report as a custom control. I pass the relevant ViewModel object in as the data context and everything looks grand.
Now, the silly thing about XPS documents. They are rather dim. You see, they don't how to paginate what is on the screen. I DO suppose there are some potential intricacies, but there are also probably only 2 methods for determining how to use pagination that would be used in general, namely, just cutting the visual element at the page boundaries (plus some room for margins) or, if a control doesn't fit on the page, move the whole damn thing onto the next page.
This is problematic and was one of the reasons for wanting to stick with Code Reasons. If I go my own way, I need to paginate my own data.
Back to the endeavour. I had started building an overly complicated engine with 3 basic components, a header, footer and details control. Basic idea is that I can use a microsoft dialog to procure the printer settings including the page size. I can then resize my control to fit on the page. Then I can check the height of the header and footer, and with my custom details, control how many rows to display based on the size remaining. In the end, what I produced with this method didn't work.
A few more hours digging through the internet and I had come full circle to simply using a custom control. But, I kept the details template control. By including a data grid which knows how to resize itself and limit its content based on things like page number and page size I can properly paginate my results in theory. At the moment I can create a report and display it and/or print it. I can work out the details of pagination once I have some working templates to test with.
Anyway, that's all for now.
Onto the fun. So I sat around in my wonderful illusion that everything would be 100 times better than last time when I finally got to the task of printing reports. I was wrong. It has been terrible. I first looked at Code Reasons open source reporting software long before I had even looked at WPF. They touted being a WPF printing solution that did documents in WPF. Well they were part right... I suppose I would even say 75% correct. Where I'm going with this is, having spent some time with XAML, WPF and Silverlight I wanted to create much richer reports with all of the new skills I had acquired. However, the FlowDocument control being utilized doesn't support data binding, in fact the reporting library really only officially supports using their home brew elements for getting data into the reports in a consistent manner. This is no fault of the developers I suppose, I did some research and people had found ways to hack data binding into FlowDocuments, but none were elegant or simple.
So, I spent the night contriving much more complicated solutions only to arrive at one so stupidly simple I feel I should flog myself for having not tried it earlier. There is part of what I have that I arrived at via my long and convoluted approach at least. Basically, I can create an XPS document from any control. So I simply create my report as a custom control. I pass the relevant ViewModel object in as the data context and everything looks grand.
Now, the silly thing about XPS documents. They are rather dim. You see, they don't how to paginate what is on the screen. I DO suppose there are some potential intricacies, but there are also probably only 2 methods for determining how to use pagination that would be used in general, namely, just cutting the visual element at the page boundaries (plus some room for margins) or, if a control doesn't fit on the page, move the whole damn thing onto the next page.
This is problematic and was one of the reasons for wanting to stick with Code Reasons. If I go my own way, I need to paginate my own data.
Back to the endeavour. I had started building an overly complicated engine with 3 basic components, a header, footer and details control. Basic idea is that I can use a microsoft dialog to procure the printer settings including the page size. I can then resize my control to fit on the page. Then I can check the height of the header and footer, and with my custom details, control how many rows to display based on the size remaining. In the end, what I produced with this method didn't work.
A few more hours digging through the internet and I had come full circle to simply using a custom control. But, I kept the details template control. By including a data grid which knows how to resize itself and limit its content based on things like page number and page size I can properly paginate my results in theory. At the moment I can create a report and display it and/or print it. I can work out the details of pagination once I have some working templates to test with.
Anyway, that's all for now.
Comments
Post a Comment