On Fri, Aug 22, 2008 at 1:58 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: > Anthony Tuininga schrieb: >> Hi, >> >> In relation to the problem I have been experiencing I froze the script >> I wrote (that accesses AutoCAD) and attempted to run that on the >> machine that is not working properly. It still doesn't work but I >> discovered something in doing so that may be of interest to this >> group. >> >> It seems that if an application is frozen you have one of two choices: >> >> A) import the generated module yourself sometime before calling >> something like GetActiveObject() that will generate it for you > > This is the approach that I would recommend. Normally my scripts > contain code snippets like this one: > > """ > if not hasattr(sys, "frozen"): > from comtypes.client import GetModule > GetModule(r"../../../include/SomeLib.tlb") > GetModule(r"../../../include/SomeOtherLib.tlb") > > from comtypes.gen import SomeLibLib > from comtypes.gen import SomeOtherLib > """ > > which will generate the code when I start the script with Python, > and which lets py2exe include the generated code into the exe.
Well, I don't like it much as it distracts from the program logic -- but it IS a solution and it has some merits. >> B) accept the overhead of regenerating the generated modules >> >> Neither of those seems ideal. I tracked it down to the fact that >> imp.find_module() is being used which doesn't understand zip files and > > AFAIK imp.find_module() DOES find modules in zipfiles. Definitely not. :-) I've just confirmed that again. Its annoying that imp.find_module() doesn't work for modules in zip files and I'm not sure if there is a good reason for that. I believe that imp is considered a deprecated module or at least devalued module and so no effort is put into enhancing it. The general suggestion is to use __import__(name) which works great for everything except when you want to know the location of the module without actually importing it, of course! >> the reason imp.find_module() is being used is because an attempt is >> being made to find the file in which the module is located and >> performing a "stat" on the file to determine if it is newer than the >> type library in question. The assumption is that if the module is >> older than the type library it must be up to date. Could someone >> explain why the version alone is not sufficient to distinguish type >> libraries? Are there vendors that ship type libraries with the same >> major __AND__ minor version but the contents are different? On the >> fact of it that would seem ludicrous but perhaps I am simply betraying >> my ignorance here? Please advise. Thanks. > > Well, it may not be the recommended approach to develop but we (in our > company) > do not increment the typelib version numbers on each change we make to our > idl files. OTOH, why do you care about the stat call? Well, its kind of hard to stat a module inside a zip file. :-) I can think of a few options to get around this. (1) attempt the import and if successful, use the module.__file__ attribute to determine the location. At that point you can check to see if the module exists in the filesystem and do the stat then; if it doesn't (its in a zip file) you can assume that its the one you want or perform a stat on the zip file itself (2) put the timestamp of the type library file itself in the generated file name. Do either of those options sound reasonable to you? I recognize you don't see any problem so I would be willing to develop the patch for whichever option you prefer it you wish. > BTW: comtypes in SVN contains an important improvement: Code generated by a > frozen > script will be cached in the filesystem, so if the generated modules are not > inside the frozen exe they will only have to be generated when the application > is run for the first time. Yes, I noticed that. That will be helpful for the situation where such generation is indeed necessary. In general a frozen application should have all of this taken care of beforehand if it at all possible, IMHO -- but if you forget or are performing dynamic COM stuff this will be very helpful. Anthony > -- > Thanks, > Thomas > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > comtypes-users mailing list > comtypes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/comtypes-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
