Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Bug: [uwp] RectHelper is the opposite of helping (RPC_E_WRONG_THREAD)
See original GitHub issueTrust me, this is not the first title I came up with.
RectHelper.Intersect throws an exception: The application called an interface that was marshalled for a different thread.
My take is that this is because I’m not calling RectHelper.Intersect on the UI thread (I can’t think of any other possibilities).
However, how can this happen, for something that should be so simple?
It’s like forcing us to use Math.Sin only on the UI thread. Who in their right mind would do such a thing?
Please, either fix it, or just throw away the whole RectHelper class.
Issue Analytics
- State:
- Created 3 years ago
- Comments:13 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Sorry you ran into this issue. I moved this to the Xaml repo because that’s where this is implemented, and it’s something we could address in WinUI3. Much of Xaml depends on running on the UI thread and performs runtime validation checks, but these static members shouldn’t need to be restricted.
@Scottj1s Thanks! As I said, I would never have originally used this, if Rect.Intersect would have returned a copy, instead of being in-place.