Wx.lib.iewin LoadString() peculiarities

Created a window in a UI that is an instance of wx.lib.iewin.IEHtmlWindow

class editor(iewin.IEHtmlWindow):
    def __init__(self, parent):
        iewin.IEHtmlWindow.__init__(self, parent, name=cfg.editorName)
        self.LoadString("<html>Hello World</html>")

Looks pretty harmless but what we end up with is:

OSError: exception: access violation reading 0x00000000C01ED5B0

Must be something obvious, but I’m drawing a blank.

Version info:


Note: obviously, Windows, but in case you ask: windows 10.

Try making this change and see if that breaks anything:

diff --git a/wx/lib/activex.py b/wx/lib/activex.py
index 0a426e28..e503772e 100644
--- a/wx/lib/activex.py
+++ b/wx/lib/activex.py
@@ -151,11 +151,13 @@ class ActiveXCtrl(wx.msw.PyAxBaseWindow):
         # accelerators can be dealt with the way that the AXControl
         # wants them to be done. MSWTranslateMessage is called before
         # wxWidgets handles and eats the navigation keys itself.
-        res = self.ipao.TranslateAccelerator(msg)
-        if res == hr.S_OK:
-            return True
-        else:
-            return super(ActiveXCtrl, self).MSWTranslateMessage(msg)
+        try:
+            res = self.ipao.TranslateAccelerator(msg)
+            if res == hr.S_OK:
+                return True
+        except OSError:
+            pass
+        return super(ActiveXCtrl, self).MSWTranslateMessage(msg)


Okay, that helped. The sample HTML now renders correctly.

However, it takes from 5 to 10 seconds to bring up the app. If I comment out the sample HTML, it loads instantly.

Every time or just the first time? Loading an ActiveX control requires a lot of work to locate and load the various binaries that implement the control, as well as the others that the control loads for itself. But once those are in the system’s cache they load quickly the next time. (As long as they are still in the cache.)

That’s the way the sample works for me. It takes a few seconds to launch the first time, and the almost instantly if I run it again within several minutes of the previous run then it loads almost instantaneously.


Confirmed. I changed things up so that it doesn’t load anything at startup, added a button that triggers LoadString() manually, along with some print()s to bracket it and give me a sense of what I am seeing.

First time, hit the button, and it takes a bit for the string to be loaded. Hit it a second time, and it’s instant.

Is there a way to pre-load things when bringing this window up, or am I going to have to live with it?

I don’t know if Windows has a way to do that generally, but you might be able to do something with the comtypes package to load the needed COM modules. (See the clsID and progID variables in wx.lib.iewin for the COM IDs.)

Are you doing anything special for the demo that isn’t in the demo file? It doesn’t seem to display any of this behavior that I can tell.

It does for me, although not as obviously since Python, wxPython and wxWIdgets are already in memory and not also contributing to the perceived startup delay. Or perhaps it’s just that the COM components were still in memory from the last time you tried your code?

That leads me to wonder if my debugger is the cause. Wait right here.

:: thingy thingy ::

Well whaddya know. I do most of my code testing in my IDE’s debug mode (PyCharm) and it OBVIOUSLY has problems with iewin. When I run from a shell (py -3 proggy.py) things are a lot zippier.

I suspect this was all a big fat red herring. Sorry bout that, Chief.

No problem, thanks for the update.