Guess what! Back doing side projects...
Coding at work has been exciting lately. And now that things on that front are getting a little less pressing, I'm finding myself once again enjoying the prospect of coding in my spare time.
So, I've gotten Visual Studio 2012 for Windows Desktop installed on my Windows 8 laptop. Grabbed my projects off my external hard drive. Connected to Team Foundation Service Preview and have been dabbling for a few days now.
Back to working on the next version of Veronica's application. Handling printing yourself, pagination and all... is a pain in the butt it turns out. I had built out a library some number of months ago which worked fine with the XPS Document Writer. Things in general resized nicely and behaved well. I then dumped the application on Veronica's work machine and resizing went all to hell to when using the dinky paper rolls in her printer. I think I spent somewhere in the vicinity of 6 hours trying to fix both the printing library and the control that I was printing itself.
The first problem stemmed from the code the library was based off of. Someone had provided some code for handling the printing of a framework element to a printer. His code, mostly handled pagination and handled some of the scenarios but not all of them. I ended up writing much of my code from scratch, except for 2 lines of code where the control was resized based on the page. That code originally tells the object it has infinite width and height, and resizes it back to the desired width and height. Well, the height isn't a problem as we are paginating the data. But the width is. The first thing I needed to do was on that initial resizing only allow it to resize with a max width equal to the width of the image-able area.
Then the next problem was Auto sized columns. They don't like being told how wide they can be it seems. I need to go back over the invoice tickets and swap it so that the elements that could be large were using * based widths and the smaller items were using Auto.
Neither of these were a problem, because I never had data too wide for the page when sizing for a full page in the XPS document writer.
Anyway... something to keep in mind for anyone else ever writing their own library (or working with someone else's) for printing XAML based controls to a printer.
So, I've gotten Visual Studio 2012 for Windows Desktop installed on my Windows 8 laptop. Grabbed my projects off my external hard drive. Connected to Team Foundation Service Preview and have been dabbling for a few days now.
Back to working on the next version of Veronica's application. Handling printing yourself, pagination and all... is a pain in the butt it turns out. I had built out a library some number of months ago which worked fine with the XPS Document Writer. Things in general resized nicely and behaved well. I then dumped the application on Veronica's work machine and resizing went all to hell to when using the dinky paper rolls in her printer. I think I spent somewhere in the vicinity of 6 hours trying to fix both the printing library and the control that I was printing itself.
The first problem stemmed from the code the library was based off of. Someone had provided some code for handling the printing of a framework element to a printer. His code, mostly handled pagination and handled some of the scenarios but not all of them. I ended up writing much of my code from scratch, except for 2 lines of code where the control was resized based on the page. That code originally tells the object it has infinite width and height, and resizes it back to the desired width and height. Well, the height isn't a problem as we are paginating the data. But the width is. The first thing I needed to do was on that initial resizing only allow it to resize with a max width equal to the width of the image-able area.
Then the next problem was Auto sized columns. They don't like being told how wide they can be it seems. I need to go back over the invoice tickets and swap it so that the elements that could be large were using * based widths and the smaller items were using Auto.
Neither of these were a problem, because I never had data too wide for the page when sizing for a full page in the XPS document writer.
Anyway... something to keep in mind for anyone else ever writing their own library (or working with someone else's) for printing XAML based controls to a printer.
Comments
Post a Comment