Skip to content
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

Addresses #63 by unpacking VT_ARRAYs of VT_RECORDs #104

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mementum
Copy link

@mementum mementum commented Apr 9, 2016

  1. If regular array unpacking fails (item not present in vartype_to_ctype, it is checked if the array is a an array of records
  2. The record information is extracted (with the new SafeArrayGetRecordInfo) and used to cast the array to the proper type (from the containing tlib)
  3. Unpacking needs to copy the bytes, because if the record contains items like BSTR, the addresses of the 1st BSTRs will be overwritten during the generation of the subsequent items). See: https://codebright.wordpress.com/2010/06/20/ctypes-and-addressof/

@mementum
Copy link
Author

mementum commented Apr 9, 2016

This is for issue #63

@cfarrow
Copy link
Contributor

cfarrow commented Apr 12, 2016

This looks good, but I haven't tested it. Do you know of any readily available typelibs that we can use to test this?

@mementum
Copy link
Author

mementum commented Apr 12, 2016

The changes were tested against VisualChart (www.visualchart.com) which is freely available for EndOfDay data. The events take arrays of records and I decided to undertake it once I saw it was still unsupported. The source code produced by the generator is very good for the typelib.

@TNick
Copy link

TNick commented May 26, 2016

These changes alone are not enough to solve the issue reported in pyautocad with GetAttributes where the type of object is VT_DISPATCH | VT_ARRAY.

However, taking inspiration from here I un-commented lines 896 and 897 and I have access to the attributes as follows:

        for att in blk.GetAttributes():
            att = comtypes.client.GetBestInterface(att)
            att_name = att.TagString
            if att_name == "ATT_1":
                att.TextString = "att_1_value"
            else:
                LOGGER.debug('Unknown attribute %s', att_name)

@mementum
Copy link
Author

The commit above and uncommenting VT_DISPATCH and VT_UNKNOWN do not travel togeher.

The commit above addresses a case in which even having VT_RECORD in the cvar_to_type dictionary doesn't help, because extra processing is needed to map the objects in the array to the right type, which has to be sought in the array itself.

Uncommenting those 2 lines adds 2 types to the aforementioned dictionary and according to the referenced mail exchange (from 2008) it works (like if it were a bool type for example), but "Thomas" didn't know if the references were being properly managed in those cases. Which I guess it is why the lines were left as comments.

Back to 2016 I guess if the references are really not properly managed, someone using the new enabled functionality can report a bug.

But if those 2 lines are left as comments, the functionality cannot even be used.

@TNick
Copy link

TNick commented May 27, 2016

Right, my bad. I can see that commenting out the changes made by this commit has no effect on the result.
As a first time user I feel shy about reporting a bug; my understanding about what the code does or should do is minimal.

@junkmd
Copy link
Collaborator

junkmd commented Nov 27, 2022

@mementum

This is a PR that has been posted for a long time, but no conflicts have occurred and it still appears to be useful.

However, same as @cfarrow, I am concerned about the testing method.

If you are still interested in anything related to this, please let us know what your opinions are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants