Please accept my apology for the delayed response. It took us a while to test the described scenario. We managed to reproduce the issue by creating a data-bound RadTileView
control and adding WindowsFormsControl
with a WindowsForms MaskedTextBox
component in the ContentTemplate
of the tiles. With this setup we noticed visual glitches during not only the scroll operation, but while loading the content as well.
We also tested the application on different machines and we realized that these issues depend on the performance of the machine - the better the performance, the smallest the issue. Our further investigation showed that the problem isn't directly caused by our RadTileView
control implementation. We can also reproduce it in a native ItemsControl
wrapped in a ScrollViewer
. And as our RadTileView
control derives from an ItemsControl
and it wraps its items in a ScrollViewer
, we believe that the cause for the issue is more generic.
What is more, after a further research on the net you can find many similar cases described. All such issues seem to come from the fact that the when you nest a WindowsForms
controls inside a WPF visual container, the WindowsForms
control actually sits on top of the WPF window and maintains its own HWND. And although the WindowsFormsHost
control acts as a placeholder for WindowsForms
content so that the WPF layout engine can treat it as a native control, it still has certain limitations when it comes to synchronizing layout changes within a WPF window.
This is why unfortunately we can't offer any workarounds in the RadTileView
TRY TELERIK'S NEWEST PRODUCT - EQATEC APPLICATION ANALYTICS for WPF.
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>