-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
Implement SAFEARRAY pointers and SAFEARRAYs as method parameters of a Dispatch Interface #569
Conversation
Thank you for contributing the new feature. I overlooked it because I had never implemented a COM server that defined a Dual interface. Before I review the codebase related to I would like you to submit another PR focused solely on the correction of the record parameter test, separate from this PR. Please divide the commits included in this patch into the following two, cherry-pick the former, and submit a new PR:
I believe that a PR that only makes corrections to the record parameter test can be merged without any problems before this PR. When you submit a new PR, you do NOT need to close this PR (#569). |
OK, I'll look into this week after next week. |
Thank you for considering splitting this PR. For the Python code part, I think I can do some reviews at this point. |
I've read through the C++ code again. As previously mentioned, it's likely changing such as Now that this COM library has multiple components, changes to |
I believe that submitting large PRs is not a problem. I NEVER say that "if it is not something that can be easily accepted by the reviewer at first glance, you should not PR". What's important is whether we can interact to make it easier to merge after submitting the PR. I think that I can interact with you in that way and I am looking forward to it. If you are unsure, please do not hesitate to consult. |
OK, I've separated the name changes for the record parameter testing component in #575. |
…face to get server side modifications of safearrays marshaled back to the client.
Added an interface to the C++ COM server for testing pointers to safearrays as method parameres of a Dispatch Interface. The implementation of the interface cannot share the IDispatch implementation with other interfaces and requires a separate component. (see https://learn.microsoft.com/en-us/cpp/atl/multiple-dual-interfaces) Therefore the naming scheme of the existing component that implements the test interface for record pointers was also changed.
Fixed changes that reverted PR#561 (fix import part in automation).
Rebased on main after #575 was merged. |
MemorandumAt the point of 850cedd Modules generated from the COM type library
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is no problem with the production codebase and the targets for assertions in tests.
What I would like to point out is about the naming parts.
For these tests, I would like to limit the ones named ...array...
to those that are SAFEARRAY
.
For concepts equivalent to "sequence"s or "collection"s other than that, I would like to use a name other than ...array...
.
Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com>
Those name changes are fine with me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I correct my mistakes and confusions.
So I think this should be ready to be merged now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution.
Following #535, being able to see the development process when adding a new COM component to the existing COM library was very educational for me.
Here are my notes on tagSAFEARRAY
and _midlSAFEARRAY
:
_midlSAFEARRAY
is a kind of factory function that returns a pointer to atagSAFEARRAY
subclass, so it's not a type.- Unlike in Implement record pointers as method parameters of a Dispatch Interface #535 where
test_in_record
was passing a record instance to the method instead of a record pointer, in Implement SAFEARRAY pointers and SAFEARRAYs as method parameters of a Dispatch Interface #569test_in_safearray
is not passing atagSAFEARRAY
instance as is, but a subclass pointer generated by_midlSAFEARRAY
.
However, since there aretest_inout_pointer
andtest_inout_byref
, I don't feel any discomfort with the nametest_in_safearray
.
With a COM Dual Interface it is possible to get server side changes to SAFEARRAYs marshaled back to the client.
However, for a pure IDispatch interface this is currently not implemented.
This pull request adds handling of SAFEARRAYs to the implementation of the automation interface.
A unittest and a new COM test interface for the C++ COM test server are also added.
I have to apologize for a mistake I made in #535.
Back at the time I did favor the implementation of several related interfaces in a single component.
Unfortunately I didn't realize that this is a problem when the interfaces inherit from the same interface but require different implementations for this interface as is the case for IDispatch (see Multiple Dual Interfaces).
While adding another component to the C++ COM test server was not a big deal, the component naming scheme for which I had advocated in #535 is inadequate for this setup.
So I was wrong and therefore have now also changed the name of the component that implements the interface for record parameter testing to reflect its limited scope.
In the future, adding additional interfaces and components implementing them will be more straight forward.