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)
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.)
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.