2.8.8.1 needs extra dependencies for wx.lib.iewin?

Hi,

My application broke when I tried upgrading to wxPython 2.8.8.1 (from 2.8.7.1) b/c of the changes to COM - use.

I did read in the release-notes about these changes, so I held off on upgrading for a while, but yesterday I found out that extra dependencies are required – and I can’t see which ones.

I did install comtypes, but only to get another exception:

Traceback (most recent call last):
File “main.py”, line 1, in
File “zipextimporter.pyo”, line 82, in load_module

File “wxgui\IBISLogExtractorApp.pyo”, line 235, in
File “zipextimporter.pyo”, line 82, in load_module
File “wxgui\WxGUIBase.pyo”, line 8, in
File “zipextimporter.pyo”, line 82, in load_module

File “wx\lib\iewin.pyo”, line 15, in
File “zipextimporter.pyo”, line 82, in load_module
File “wx\lib\activex.pyo”, line 44, in
ImportError: cannot import name myole4ax

What is this ‘myole4ax’ module? Where / how do I get it?

Thanks for pointers,

–Tim

Actually, I should nuance a bit my trouble-report.

Tim N. van der Leeuw wrote:

Hi,

My application broke when I tried upgrading to wxPython 2.8.8.1 (from
2.8.7.1) b/c of the changes to COM - use.

I did read in the release-notes about these changes, so I held off on
upgrading for a while, but yesterday I found out that extra dependencies
are
required -- and I can't see which ones.

I did install comtypes, but only to get another exception:

Traceback (most recent call last):
  File "main.py", line 1, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wxgui\IBISLogExtractorApp.pyo", line 235, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wxgui\WxGUIBase.pyo", line 8, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wx\lib\iewin.pyo", line 15, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wx\lib\activex.pyo", line 44, in <module>
ImportError: cannot import name myole4ax

What is this 'myole4ax' module? Where / how do I get it?

Thanks for pointers,

It seems that the app only breaks after creating an executable with py2exe.

When running it using the normal Python interpreter, the missing module is
being generated.

(The app then still needs an upgraded wxPropGrid to function, so it still
bombs out, and I cannot yet get that new propgrid onto that dev. PC, but
hey, it's a progress compared to what it did in executable form!)

Unfortunately I do need to release executable files to my users, so I would
really like to know how to restore functionality, otherwise I'll have to
downgrade to 2.8.7.1 again!

Regards,

--Tim

···

--
View this message in context: http://www.nabble.com/2.8.8.1-needs-extra-dependencies-for-wx.lib.iewin--tp18957413p18959423.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Tim N. van der Leeuw wrote:

Actually, I should nuance a bit my trouble-report.

Tim N. van der Leeuw wrote:
  

Hi,

My application broke when I tried upgrading to wxPython 2.8.8.1 (from
2.8.7.1) b/c of the changes to COM - use.

I did read in the release-notes about these changes, so I held off on
upgrading for a while, but yesterday I found out that extra dependencies
are
required -- and I can't see which ones.

I did install comtypes, but only to get another exception:

Traceback (most recent call last):
  File "main.py", line 1, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wxgui\IBISLogExtractorApp.pyo", line 235, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wxgui\WxGUIBase.pyo", line 8, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wx\lib\iewin.pyo", line 15, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "wx\lib\activex.pyo", line 44, in <module>
ImportError: cannot import name myole4ax

What is this 'myole4ax' module? Where / how do I get it?

Thanks for pointers,

It seems that the app only breaks after creating an executable with py2exe.

When running it using the normal Python interpreter, the missing module is
being generated.

(The app then still needs an upgraded wxPropGrid to function, so it still
bombs out, and I cannot yet get that new propgrid onto that dev. PC, but
hey, it's a progress compared to what it did in executable form!)

Unfortunately I do need to release executable files to my users, so I would
really like to know how to restore functionality, otherwise I'll have to
downgrade to 2.8.7.1 again!

Regards,

--Tim

What bundle option are you using for py2exe? I was told by the py2exe group to use option 3. I wonder if you need to include the comtypes module explicitly. If you decide to post to the py2exe group, remember that they also like small runnable examples of the issue:

···

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org
Python Extension Building Network: http://www.pythonlibrary.org

Hi Mike,

Tim N. van der Leeuw wrote:

Actually, I should nuance a bit my trouble-report.

Tim N. van der Leeuw wrote:

Hi,

My application broke when I tried upgrading to wxPython 2.8.8.1 (from

2.8.7.1) b/c of the changes to COM - use.

What bundle option are you using for py2exe? I was told by the py2exe group to use option 3. I wonder if you need to include the comtypes module explicitly. If you decide to post to the py2exe group, remember that they also like small runnable examples of the issue:

I use bundle-option ‘1’, because it gives me all the output in 1 file. Using ‘3’ gives me lots of small files, and they’re not even put in the destination-directory too (they just stay in dist).

Actually the odd thing is, that by now I’ve realized that the application does work as an executable if only I run the app and the IEWin bits first from the interpreter! Then it dynamically generates all it wants and needs, and those things will be included in the EXE too.

I find that rather annoying. I need to run the application before I can build it?

Also, it seems that opening windows containing an embedded IEHTML component is now a lot slower than before, when you open them the first time.

And searching for modules seems slower, but that could potentially have other causes.

The final executable also grew by about 2 Mb. So I don’t see the claim about ‘reduced external dependencies’ having any effect on my project.

So altogether this is not a change that I’m happy about: I need to install extra things, I need to do extra things, and there’s a definite slowdown.

Can someone please explain to me the benefits of this change? Or if there’s a way to not have this change but do things ‘the old way’?

Regards,

–Tim

https://lists.sourceforge.net/lists/listinfo/py2exe-users

Thanks for the pointer – I’m a member on the list :wink: but I’m not sure that this problem is very much py2exe related. It has more to do with the dynamically-generated modules which can not be found before running the app generates them, and which can not be dynamically generated anymore once running as executable.

That does kind of ring bells but I can’t remember where I read what about it.

···

On Wed, Aug 13, 2008 at 3:44 PM, Mike Driscoll mike@pythonlibrary.org wrote:


Mike Driscoll

Blog: http://blog.pythonlibrary.org

Python Extension Building Network: http://www.pythonlibrary.org

Tim van der Leeuw wrote:

Hi Mike,

    Tim N. van der Leeuw wrote:

        Actually, I should nuance a bit my trouble-report.

        Tim N. van der Leeuw wrote:
         
            Hi,

            My application broke when I tried upgrading to wxPython
            2.8.8.1 <http://2.8.8.1> (from
            2.8.7.1 <http://2.8.7.1>) b/c of the changes to COM - use.

    What bundle option are you using for py2exe? I was told by the
    py2exe group to use option 3. I wonder if you need to include the
    comtypes module explicitly. If you decide to post to the py2exe
    group, remember that they also like small runnable examples of the
    issue:

I use bundle-option '1', because it gives me all the output in 1 file. Using '3' gives me lots of small files, and they're not even put in the destination-directory too (they just stay in dist).

Actually the odd thing is, that by now I've realized that the application *does* work as an executable if only I run the app and the IEWin bits first from the interpreter! Then it dynamically generates all it wants and needs, and those things will be included in the EXE too.

I find that rather annoying. I need to run the application before I can build it?

Also, it seems that opening windows containing an embedded IEHTML component is now a lot slower than before, when you open them the first time.
And searching for modules seems slower, but that could potentially have other causes.

The final executable also grew by about 2 Mb. So I don't see the claim about 'reduced external dependencies' having any effect on my project.

So altogether this is not a change that I'm happy about: I need to install extra things, I need to do extra things, and there's a definite slowdown.

Can someone please explain to me the benefits of this change? Or if there's a way to not have this change but do things 'the old way'?

Regards,

--Tim

    py2exe-users List Signup and Options

Thanks for the pointer -- I'm a member on the list :wink: but I'm not sure that this problem is very much py2exe related. It has more to do with the dynamically-generated modules which can not be found before running the app generates them, and which can not be dynamically generated anymore once running as executable.
That does kind of ring bells but I can't remember where I read what about it.

I'm no py2exe expert, but I had a similar problem except that it had to do with a dll supposedly missing. I asked here and at the py2exe group and the guys at the py2exe group recommended using bundle option 3 as option 1 seems to be somewhat problematic. I use Andrea's GUI2Exe to do this sort of thing and I tell it to put all the files in the dist directory. Yes, I would like one file too, but since I can use Inno Setup to bundle as many files as I want, this isn't a problem. I think you should try it and see if it works at least.

Just an FYI: I use option 1 most of the time, but I've been finding that the resulting exe ends up working on 90% of my user's PCs and failing on the other 10%, which is pretty annoying. Changing the option to 3 seems to take care of that.

As for why it grew by 2 MB, I think this happens because it's including all the modules it thinks you'll need, which is kind of a hack. As far as I can tell, it does a good job at guessing, but you might benefit from explicitly excluding some things if size really is an issue.

Since I haven't messed much with the iewin part of wx, I don't have any awesome pointers as to why it might be slower as an exe versus pure code. That just sounds weird. I usually notice a slight speedup, but that's probably because most of my scripts are run from a server, but my exes usually get run locally.

Sorry I wasn't of more help. Also I apologize for not getting back to you quicker. Our mail server is undergoing some restructuring and I'm getting email out of order at the moment.

Mike

···

On Wed, Aug 13, 2008 at 3:44 PM, Mike Driscoll <mike@pythonlibrary.org > <mailto:mike@pythonlibrary.org>> wrote:

Tim van der Leeuw wrote:

Actually the odd thing is, that by now I've realized that the application *does* work as an executable if only I run the app and the IEWin bits first from the interpreter! Then it dynamically generates all it wants and needs, and those things will be included in the EXE too.

That's simply because of code like this in the modules that use comtypes:

if not hasattr(sys, 'frozen'):
     f = os.path.join(os.path.dirname(__file__), 'myole4ax.tlb')
     cc.GetModule(f)
from comtypes.gen import myole4ax

The assumption is that Python developers would run their apps at least once while developing them without py2exe (or other freezing tool) before actually distributing them with py2exe.

If you want to work around that then you can do the GetModule calls yourself before the activex modules are imported. However, if you don't distribute the generated modules as part of your app bundle, then they will get regenerated every time the .exe runs.

I find that rather annoying. I need to run the application before I can build it?

This is Python... What's so hard about running "python myapp.py" while in development mode? Or you could even do "python -c 'import wx.lib.iewin'" before running py2exe to make sure the modules are generated (or just put an import statement in your setup.py.)

Also, it seems that opening windows containing an embedded IEHTML component is now a lot slower than before, when you open them the first time.
And searching for modules seems slower, but that could potentially have other causes.

The final executable also grew by about 2 Mb. So I don't see the claim about 'reduced external dependencies' having any effect on my project.

Unfortunately the microsoft type library that contains the IHTMLDocument type and all the related types has *a lot* of crap in it, so it generates a very large python module. Large enough that it takes a small but noticeable amount of time to import it. There has been some discussion in the comtypes project about making the generation of python modules optional and falling back to a pure dynamic interface to the COM objects that don't have a generated module available.

So altogether this is not a change that I'm happy about: I need to install extra things, I need to do extra things, and there's a definite slowdown.

Can someone please explain to me the benefits of this change?

Comtypes allows us to have full dynamic-dispatch abilities to the COM objects, as well as support for any COM data type and object, including all methods and properties. In other words all the limitations of the old approach are gone.

One example of something that was not possible before but now is, is full access to the Document object in the embedded IE, including manipulating document fragments, etc.

Or if there's a way to not have this change but do things 'the old way'?

As mentioned in the CHANGES doc the old modules are still there in wx.lib, with a "_old" appended to the name. So look for wx.lib.iewin_old.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi,

First off, thanks for the answers and hard work. It is appreciated. Even when I’m complaining on something :wink:

Tim van der Leeuw wrote:

Actually the odd thing is, that by now I’ve realized that the application does work as an executable if only I run the app and the IEWin bits first from the interpreter! Then it dynamically generates all it wants and needs, and those things will be included in the EXE too.

That’s simply because of code like this in the modules that use comtypes:

if not hasattr(sys, ‘frozen’):

f = os.path.join(os.path.dirname(__file__), 'myole4ax.tlb')

cc.GetModule(f)

from comtypes.gen import myole4ax

The assumption is that Python developers would run their apps at least once while developing them without py2exe (or other freezing tool) before actually distributing them with py2exe.

Well, most of the time that assumption will be valid of course. But I’d like to be able to create the executable ‘from scratch’ on a clean install. I will also have to hand over development to somebody else soon, and I will need to come up with a recipe of what needs to be done and installed etc. in order to have a running version of the application.

For that, I’d like to have as few surprises as possible. This certainly is a surprise that could give very puzzling results.
I noticed also that just starting to app. is not enough for all modules to be generated: it seems that when I actually open that window containing the IE control for the first time, it generates some more code that wasn’t yet generated when importing the module. This complicates the sequence of what needs to be done before a fully functioning EXE can be generated.

I was thinking to put the required import - statements in setup.py, same as you suggested, but I think that I’ll also need to create an App() instance, a Frame(), and the IEHtml window instance from the setup.py to be certain that all code is properly generated.

If you want to work around that then you can do the GetModule calls yourself before the activex modules are imported. However, if you don’t distribute the generated modules as part of your app bundle, then they will get regenerated every time the .exe runs.

Given the time it takes to generate them, I think that’s rather unacceptable too. I’ll rather generate them in advance! :slight_smile:

I find that rather annoying. I need to run the application before I can build it?

This is Python… What’s so hard about running “python myapp.py” while in development mode? Or you could even do “python -c ‘import wx.lib.iewin’” before running py2exe to make sure the modules are generated (or just put an import statement in your setup.py.)

Also, it seems that opening windows containing an embedded IEHTML component is now a lot slower than before, when you open them the first time.

And searching for modules seems slower, but that could potentially have other causes.

The final executable also grew by about 2 Mb. So I don’t see the claim about ‘reduced external dependencies’ having any effect on my project.

Unfortunately the microsoft type library that contains the IHTMLDocument type and all the related types has a lot of crap in it, so it generates a very large python module. Large enough that it takes a small but noticeable amount of time to import it. There has been some discussion in the comtypes project about making the generation of python modules optional and falling back to a pure dynamic interface to the COM objects that don’t have a generated module available.

I think I would like to have such a fallback. I think that it would save me hassle.

So altogether this is not a change that I’m happy about: I need to install extra things, I need to do extra things, and there’s a definite slowdown.

Can someone please explain to me the benefits of this change?

Comtypes allows us to have full dynamic-dispatch abilities to the COM objects, as well as support for any COM data type and object, including all methods and properties. In other words all the limitations of the old approach are gone.

One example of something that was not possible before but now is, is full access to the Document object in the embedded IE, including manipulating document fragments, etc.

I’ve never tried accessing IE components using win32com. I do use it rather often for accessing MS-Word and Excel and I always get to access all the properties of all the classes, and in PythonWin they show up in the code-completions too.

I’m surprised to hear that for (embedded) IE, such things wouldn’t work when using win32com.

(OR there are things that I’ve been missing out on all along that I never even knew about, even when working with MS-Word or Excel :wink: )

Or if there’s a way to not have this change but do things ‘the old way’?

As mentioned in the CHANGES doc the old modules are still there in wx.lib, with a “_old” appended to the name. So look for wx.lib.iewin_old.

I remember now that I read about this when 2.8.8.0 first came out. Sorry for not remembering about it when I first started to try it out yesterday.

Robin Dunn

Software Craftsman

http://wxPython.org Java give you jitters? Relax with wxPython!

Thanks for your help and time,

–Tim

···

On Wed, Aug 13, 2008 at 11:46 PM, Robin Dunn robin@alldunn.com wrote:

To generate a release, I run a Python script that:
* builds my help file
* runs pyinstaller
* runs INNOsetup to package the frozen app
* uploads the packaged app
* gets the version and:
   * changes the PAD file
   * changes the version on a web page
   * uploads those files to the web site
* inserts my change list into a web page and uploads it

Automating all this ensures that I don't overlook anything.
Perhaps you could do the equivalent for your successor.

Phil

···

At 11:31 PM 8/13/2008, Tim van derLeeur wrote:

[discussion about packaging activeX snipped]
Well, most of the time that assumption will be valid of course. But I'd like to be able to create the executable 'from scratch' on a clean install. I will also have to hand over development to somebody else soon, and I will need to come up with a recipe of what needs to be done and installed etc. in order to have a running version of the application.

For that, I'd like to have as few surprises as possible. This certainly is a surprise that could give very puzzling results.
I noticed also that just starting to app. is not enough for all modules to be generated: it seems that when I actually open that window containing the IE control for the first time, it generates some more code that wasn't yet generated when importing the module. This complicates the sequence of what needs to be done before a fully functioning EXE can be generated.

Tim van der Leeuw wrote:

I've never tried accessing IE components using win32com. I do use it rather often for accessing MS-Word and Excel and I always get to access all the properties of all the classes, and in PythonWin they show up in the code-completions too.
I'm surprised to hear that for (embedded) IE, such things wouldn't work when using win32com.

(OR there are things that I've been missing out on all along that I never even knew about, even when working with MS-Word or Excel :wink: )

The prior version is not using PyWin32, but a wx ActiveX wrapper instead. It's much lighter weight than PyWin32, but has lots of limitations. The version using comtypes gives us almost everything that PyWin32 can do but with no extra binary extension modules. It's all done via ctypes instead.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Tim van der Leeuw wrote:

I’ve never tried accessing IE components using win32com. I do use it rather often for accessing MS-Word and Excel and I always get to access all the properties of all the classes, and in PythonWin they show up in the code-completions too.

I’m surprised to hear that for (embedded) IE, such things wouldn’t work when using win32com.

(OR there are things that I’ve been missing out on all along that I never even knew about, even when working with MS-Word or Excel :wink: )

The prior version is not using PyWin32, but a wx ActiveX wrapper instead. It’s much lighter weight than PyWin32, but has lots of limitations. The version using comtypes gives us almost everything that PyWin32 can do but with no extra binary extension modules. It’s all done via ctypes instead.

Aha, I see. Interesting! :slight_smile:

(Since PyWin32 is installed for me anyways, b/c I use it for numerous other things, I never even noticed if it was a requirement for the IEHtml component or not).

I’m still undecided whether to go with the old way or the new way; mainly I tend to favour the old way b/c of the load-time issue I see.

Robin Dunn

Software Craftsman

http://wxPython.org Java give you jitters? Relax with wxPython!

Regards,

–Tim

···

On Thu, Aug 14, 2008 at 9:39 PM, Robin Dunn robin@alldunn.com wrote: