Monday, April 14, 2014

All that glitters is not gold

I have to say, over the past few weeks I quite fell in love with WPF. It's like WinForms, that has all it's things sorted out, kinda grown up. All those class names make sense and are consistent throughout the framework (I'm talking especially about controls).

Until I came across WebBrowser customizations. In WinForms it was simple and straightforward, so I assumed this will be the same, but better. Well, I was wrong. When I tried to assign any kind of event in mshtml/DOM, the WebBrowser froze. Yes, the event has been processed, but I was unable to select text or scroll the page. Useless! I didn't find anything, that helps - not even in solution, that described exactly my problem about mouse lockups.

I started research to replace default IE WebBrowser with e.g. WebKit. There are some nice stuff, like WebKit.NET, Awesomium or GeckoFX. I understand that browser is a big deal, but I don't want to ship my tiny app with at least 30 MB in browser DLLs.

I had a strange feeling about the solution mentioned before, because I noticed in the HUGE discussion below the article that people thanks the author, so it should work. But it didn't. This time I was more stubborn and kept on reading posts.

Finally I reached one post, that points out the author forgot to put "[ComVisible(true)]" above one class, which solved my problem and it started to work. Phew!

In many, many solutions I found, that this is not expected behavior, it's in the WPF framework since the dawn of time, but Microsoft apparently don't care. Sucks!

No comments:

Post a Comment