Appendix A: Differences Between Versions, and Other Guidelines

This section details the known differences in control hosting between Internet Explorer 3.0 and Internet Explorer 4.0, and presents other guidelines for creating controls. Internet Explorer 3.0 hosted controls in a slightly more relaxed fashion than Internet Explorer 4.0; for Internet Explorer 4.0 the specifications for controls and COM interfaces have been followed more stringently. This allows Internet Explorer 4.0 to host a greater variety of controls; however, it does mean that some controls that functioned correctly in Internet Explorer 3.0 may no longer have identical functionality in Internet Explorer 3.0. Wherever possible, these differences have been minimized.

If a control fires an event from a thread that it creates, rather than from the thread in which it was created, the event will never make it. All calls from the control must be made on the creation thread.
Internet Explorer 4.0 calls FindConectionPoint on a control to hook up events even if the control exposes no events. A control should be written to expect this call.
As previously mentioned, non-apartment-model-aware controls might not function properly.
The VBScript engine no longer passes parameters to controls ByVal; they are now usually passed ByRef. Standard practice when passing a variant is to check how it is being passed before retrieving the value. If a control relies on a parameter being passed ByVal, it might not work.
Internet Explorer 3.0 sent DoVerb Show and Hide to controls in addition to InPlaceActivate and InPlaceDeactivate. Internet Explorer 4.0 no longer sends the verbs.
A control should use the WM_CONTEXTMENU message to hook in for context menus and not trigger the right-mouse-up message.
A control should not forcefully UIActivate itself, or assume itself to be UIActive. A control that needs the focus should have it set by the script of the document on which it is hosted. This is an area that the page author is in control of. In the case of multiple controls on a page, a UIActivate battle could cause strange results, and in the case of a control that is instantiated at the bottom of a large page, an ugly user experience might result as the control is forcefully scrolled into view.
It is not good practice for a control to bring up modal dialog boxes unless in immediate response to some user interaction. For example, if a control is asynchronously downloading data in the background and the link fails, a control should fire an Error event for the script to be able to react to and/or show the error in its own rendering. Bringing up a dialog box under such circumstances creates a poor user experience and might upset applications hosting the Internet Explorer 4.0 components.