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 B) > accept the overhead of regenerating the generated modules
Anthony, sorry that I didn't understand completely the first time what you were trying to say. The intent was that the import of the generated module was meant to instruct the freezer to include the imported module into the exe, independend from where this import statement occurs. This does indeed work. What does not work and you have discovered is that the import statement must be executed BEFORE the generated module is needed by a call to GetActiveObject() or CreateObject() - in a frozen script! > [...] I tracked it down to the fact that imp.find_module() is being > used which doesn't understand zip files and 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. [from your other post] > 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. > (2a) put the timestamp of the type library file itself in the generated code? > 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. Well, I see the problem *now*. On first thought the first option looks more attractive to me but I have to think about that - which option would you prefer? >>> 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. My own recent impression on this new stuff (caching code generated from *frozen* scripts in the file system) isn't so good. The code generation is probably not robust enough for that - for example if the code generation is interrupted it may leave incomplete, broken stuff in the cache directory and the exe will fail miserably each time it is started. -- 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
