New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect error handling in codegenerator.py
file, calc_packing
function if packing of a structure is failed
#332
Comments
codegenerator.py
file, calc_packing function
if structure packing is failed
codegenerator.py
file, calc_packing function
if structure packing is failedcodegenerator.py
file, calc_packing
function if packing of a structure is failed
Is this error thrown by calling If so, please write down the code and/or traceback so that I may be able to assist you in resolving this issue. |
Error is thrown in both cases ( Traceback for
Result of calling
The interface of the application 'SomeApp.Application' has some unnecessary functions with SAFEARRAY of structures containing double fields as arguments. This error is thrown only when python is x86 and the application 'SomeApp.Application' is x64. Some problems with alignment in 'SomeApp.Application'. |
From your comment, I'm guessing that 'SomeApp.Application' is specific to your environment and is a class that can be called from its I have been a contributor to this repository recently, but mostly working about the Python API, not so much about the c-FFI. I would like to hear the opinion from @vasily-v-ryabov, who is leading the maintenance of this repository. |
@junkmd Yes, 'SomeApp.Application' is specific to my environment and has its VersionIndependentProgID ('SomeApp.Application') used to call the application |
I also find it strange that such a thing would occur. I assume that the module generated by Please try executing the code below to see whether an instance can be created. SomeApp = GetModule("full/path/to/someapp/*tlb")
# `CreateObject` can take CoClass type which has `_reg_clsid_` attribute.
# see definition of `client.CreateObject`, `client._manage`, and `GUID.from_progid`
CreateObject(SomeApp.Application)
# or `comtypes.CoCreateInstance(SomeApp.Application().IPersist_GetClassID())` |
This code works as intended, instance is created (the use of I have found through pdb.pm() that difference between
Maybe, comtypes is confused with x64 and x86 platforms when |
Thank you for your investigation. It seems to me that it would be reasonable to ensure that Do you know where need to be corrected in the code? |
@junkmd |
Oh, I have encountered similar problems. There is two Similarly, there may be multiple DLLs in the environment and the DLL referenced by To check, once you have to delete |
@junkmd I'm mostly reviewing and publishing releases of I remember some cases in pywinauto that don't work with 64-bit |
Thanks for your response. I am not very familiar with c-ffi or the c language itself. I'm trying to learn, but for me, adding type hints to this package and refactoring old code in preparation for that is a high priority. My hope is that as more developers use |
ok with respect to this error. I want to clear a few things up so everyone is on the same page. Typelibs do not live in the registry. they get registered and that registration is stored in the registry and the file that the typelib is stored in also gets stored with the type lib GUID and name but other than that it's a file. The only reason why you would have different output when using the generator and passing a dll vs using a registered name is they are not using the same file. There is another one wandering around on your system somewhere that has different typelib information. Since the files are getting made in your case if you go to comntypes/gen you will see the generated files... If you move or delete everything except for
it will be right at the top of the file. This tells you exactly where the file is located that the type lib information is being read from. Lets see if the path and file is the same as the one you are manually passing in, I am willing to bet they aren't and there could be some difference between them. |
These 2 commands function very close to being the same. The GetModule function Loads the typelib using the Windows API while CreateObject collects the typelib GUID that is registered to the name that is passed to it. From that GUID the location the typelib is stored in is able to be collected and then the code generator would get run. The GetModule since it was passed the location doesn't need the first bunch of steps but once CreateObject collects the path the mechanics are identical after that. So the ONLY way to end up with 2 completely different generated code files is because there are 2 completely different typelibs that are being used.
|
Now I have a question. Is the file being passed to GetModule the path to a .tlb file? If it is then whatever you used to generate the .tlb may not have generated it properly. More than likely a missed compiler option, when a typelib gets compiled into a dll the compiler arguments used are what determine how the typelib resource gets added to the dll. if generating the type lib outside of the normal compilation process for the dll then you need to ensure the proper compiler arguments are being used to generate the tlb file. |
If structure packing is failed, then function calc_packing is failed too due to incorrect error handing ("local variable 'details' referenced before assignment" in line 137).
Here is proposed patch to fix (can't create branch for merge request). Last proposed change in line 552 is needed to skip failed structure, otherwise type library wouldn't loaded even after fixing "details" variable (oading would fail in generated code from gen directory in line like
assert sizeof(SomeStructure) == 24, sizeof(SomeStructure)
).The text was updated successfully, but these errors were encountered: