Today’s post is about my continuing quest to learn Windows phone and the headaches that inevitably go with it. This weeks headache was building a EULA page for an application I was recently trying to prepare for the windows app store. You would think this would be pretty simple right? Throw a TextBlock inside a ScrollViewer and call it a day. Not so much. Apparently, any element that is displayed beyond the area of 2048 x 2048 pixels gets clipped by the platform. Supposedly there are hardware and performance limitations that dictate this “feature”.
I’m not quite sure why they wouldn’t provide something in the framework to allow a developer to override this. Its similar to Apple’s ingenious decision to make access to turning on and off Bluetooth inaccessible via public method. It really gets me going that Microsoft and Apple like to dictate what I want to do, but I digress.
How to fix this?
So how does one handle this conundrum? Well, there are several blogs out there on MSDN by developers that handle this building helpers that split the text. Here are two helpful blog posts that I found. It took a while to find them, so I thought it would be nice to share with everyone both so you could decide on your implementation.
Both options have their merits and it really depends on what you are trying to accomplish and how much you care about performance. The first technique splits each chunk of data into the maximum size of a TextBlock. The only problem is that he is making a text block for each “chunk” of text. He is then placing them in a stack panel. It sounds like a good idea, but there are a few problems I have with this. The first issue is that making UI objects like that can add up quick and to me wastes memory and can cause performance issues. This depends on your use case for this scenario and whether you really need or want to worry about performance. In my case, I did care about performance, so the second article by Denis Stankovski’s is what this blog will be about.
This option takes a single instance of a text block instead of multiple text blocks. It uses this text block to get the max length (height) that can be used. In this class, each “chuck” of characters are broken up into the max size and added to a list of strings. This is much more efficient because you are returning a list of strings (which is much smaller than a list of UI objects) to the caller. The other thing that I really like about this approach is the fact that it separates the helper from the actual UI. Although there is a Text Block being used, it is still not being returned as a list of them nor are they being created in code on the fly, so it ultimately stays separated from the view / UI. Also, the TextBlock that is created is only used temporarily and not used throughout the code. I am a big fan of separation of concerns, so obviously, this is more my type of option.
I was going to add the example in the blog, but Denis does a great job and his blog engine allows C# color coding, so it will be easier to read. At some point in the next week or so, I will update this post with a link to the code I used it in so you can see how I used it.
I hope this reaches some developers that run into similar issues and find this post quicker than it took me to find something on the webs.
Happy Coding 🙂