After eighteen months, I got a weekend free to write my own code, and hence continues my series on avoiding some major gottcha’s in WM coding.
One of the major frustrations you would hit is the webbrowser control. There are many scenarios when you want a formatted text based UX, or a flow-style UX where the WebBrowser control comes in pretty handy. However, here are a few things you should know before you start coding – lest you end up investing months of effort and finding out you won’t get the “exact” same effect as you hoped for.
All in all, it’s an amazing component that at times you will be very very thankful they included.
1. Most of the COM Interfaces that allow extensibility on the desktop aren’t supported on the phone (duh!). Most specifically the ones you’ll miss are the IDocHostUIHandler (preventing you from overloading the context menu), and IInternetSecurityManager (preventing you from implementing your own security zone/settings).
2. The DOM elements are specially made-for-mobile COM classes which are named IPIEHTML* instead of the IHTML*. Your Anchor would be IPIEHTMLAnchorElement (or somethign like that). There isn’t any documentation on these so don’t waste time hunting. Instead open up webvw.idl found in one of the sdk include paths and you’ll be able to figure out what does what.
3. DHTML is *NOT* supported. Many people repeatedly try to modify formatting/style of elements in a generated page. The precise and unambigious answer is “it cannot be done”. Don’t waste time trying. Having said that, the IPIEHTMLControlElement derivatives support some on-the-fly modification such as setting/modifing text in text boxes, or editing of lists, and disabling/enabling controls.
4. Some features not supported on desktop are actually supported on the mobile control. Some esoteric CSS pseudoclasses such as :focus which don’t work on desktop IE, work perfectly on pocket IE. You can make some really cool effects by changing formatting when a control is focussed – especially on smartphones where the dotted-line focus highlight can be too thin to notice and you might want to add a little more jazz to your links. In this case, there’s an undocumented CSS extension called x-focus-border which when set to none will get rid of the focus rectangle (found this in the comments section of the IE Mobile Blog).
5. If you’re using Document->Write to insert HTML into the control from your app, then note that the DocumentComplete event is not guaranteed to be fired. I found no documentation on this yet, but I’ve seen the symptom a few times. I admit that I may be doing something wrong here, but it’s something worth keeping in mind if you’re going to rely on that. Ensure you test this out with your pages first. To be more specific, when I didn’t put a background picture for the page, I didn’t get this event. When I did put a background picture, the event fires consistently as expected. The workaround, of course, is to put a dummy one-pixel white image as background.
That’s all I can think of for now. Will post more regularly on avoiding various gottchas that can end up saving a lot of time when developing for WM, if you know what to look out for.
