Monday, November 18, 2013

Sharing a resource with a TextBox.CaretBrush can cause some weird behaviour

I think I've found another bug in Windows Phone but it seems really odd.
I'm documenting it here before escalating to find out if it really is a bug but I can't believe its intended behaviour.
Maybe you have an idea or explanation as to why this is happening? If so, do please share.

Have a look at this code:

It creates a page that looks like this:


The thing to note is that the CaretBrush on the TextBox, the Foreground on the Button, the Foreground on the first TextBlock and the Fill of the Rectangle are all bound to the same resource.
This is exactly the sort of thing I'd expect to see when wanting to apply the same colour to multiple elements on a page (or app).
What's probably unusual, or somewhat of an edge-case, is setting a custom colour for the CaretBrush, although this is often necessary when using a heavily customised UI. (That's where I first discovered this. - The above is the simplest reproduction I could find.)

So what's special, well, the caret (if you're unfamiliar) is the little line in the TextBox that flashes to show you the edit point when the control has focus.
The odd thing here is that rather than just the caret flashing, in the above example everything with the "colour" bound to the same resource as the CaretBrush flashes too. That what the right hand image shows.

This can be quite an odd experience when you see seemingly random elements on a page start to flash while typing into a TextBox.

Fortunately the fix is easy. It's just to not bind the CaretBrush to the same resource as anything else.
Of course this means you will have some otherwise unnecessary duplication in your XAML though.


My guess is that there's something odd internally with the way the TextBox finds the caret so that it can cause it to flash. If not that the the Brush is remembering the items that reference it in an incorrect way. Either of which are very odd.
I'd love to hear any thoughts on this and will report anything I hear back from official channels.


*** UPDATE ***
I've had it confirmed that this is a very old (over 5 years) known bug with the Silverlight TextBox control. One to be aware of if heavily styling a TextBox and easy to work around.



0 comments:

Post a comment