Addresses #63 by unpacking VT_ARRAYs of VT_RECORDs

[mementum]

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]

This is for issue #63

[cfarrow]

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]

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]

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]

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]

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]

@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.