|Subject:||Re: [wxpython-users] 126.96.36.199 needs extra dependencies for wx.lib.iewin?|
|From:||Tim van der Leeuw ("tnl...@gmail.com)|
|Date:||Aug 13, 2008 11:31:14 pm|
First off, thanks for the answers and hard work. It is appreciated. Even when I'm complaining on something ;-)
On Wed, Aug 13, 2008 at 11:46 PM, Robin Dunn <ro....@alldunn.com> 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.
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! :-)
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 ;-) )
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 188.8.131.52 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,