You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed the following while investigating structured storage and monikers and verifying with the Python wrapper module for msvidctl.dll, which defines those interfaces.
When retrieving the FUNCDESC that holds the information of vtbl-mapped methods from ITypeInfo, which contains the interface information, there are cases where the method has the call_as IDL attribute instead of the local IDL attribute.
The methods defined in the interface of the module generated by GetModule are based on the information from these FUNCDESCs.
However, the parameters of the methods defined for remote procedure calls with the call_as attribute may not match the parameters of the methods defined for local use with the local attribute.
As a result, attempting to call these methods from the client side may result in errors.
This issue is different from the one discussed in #474 and resolved by @jonschz in #578 for ISequentialStream.RemoteRead, where calling low-level functions with preallocation was the solution.
As seen in the IDL file, the methods RemoteRead and Read had the same parameters, differing only in name.
However, in cases like IStorage's RemoteOpenStream and OpenStream, where there are parameter differences, calling low-level functions won't resolve the problem.
Furthermore, since IEnumMoniker has RemoteNext defined as call_as(Next), RemoteNext is defined instead of Next. This results in the interface not meeting the conditions for defining __iter__, __next__, and __getitem__ by the codegenerator, making it unusable as an iterator.
To differentiate between local and call_as, using ITypeInfo2 in tlbparser or codegenerator might be a possible solution.
However, careful implementation is required to avoid losing backward compatibility or unnecessarily complicating the current codegenerator or tlbparser.
For individual interfaces, this issue could be resolved by statically defining the interface (and its dependent structures) with the local methods and adding them to __known_symbols__.
I think that specific issues should be submitted for each interface or framework.
The text was updated successfully, but these errors were encountered:
I noticed the following while investigating structured storage and monikers and verifying with the Python wrapper module for
msvidctl.dll
, which defines those interfaces.When retrieving the
FUNCDESC
that holds the information of vtbl-mapped methods fromITypeInfo
, which contains the interface information, there are cases where the method has thecall_as
IDL attribute instead of thelocal
IDL attribute.The methods defined in the interface of the module generated by
GetModule
are based on the information from theseFUNCDESC
s.However, the parameters of the methods defined for remote procedure calls with the
call_as
attribute may not match the parameters of the methods defined for local use with thelocal
attribute.As a result, attempting to call these methods from the client side may result in errors.
This issue is different from the one discussed in #474 and resolved by @jonschz in #578 for
ISequentialStream.RemoteRead
, where calling low-level functions with preallocation was the solution.RemoteRead
andRead
had the same parameters, differing only in name.However, in cases like
IStorage
'sRemoteOpenStream
andOpenStream
, where there are parameter differences, calling low-level functions won't resolve the problem.Furthermore, since
IEnumMoniker
hasRemoteNext
defined ascall_as(Next)
,RemoteNext
is defined instead ofNext
. This results in the interface not meeting the conditions for defining__iter__
,__next__
, and__getitem__
by thecodegenerator
, making it unusable as an iterator.To differentiate between
local
andcall_as
, usingITypeInfo2
intlbparser
orcodegenerator
might be a possible solution.However, careful implementation is required to avoid losing backward compatibility or unnecessarily complicating the current
codegenerator
ortlbparser
.For individual interfaces, this issue could be resolved by statically defining the interface (and its dependent structures) with the local methods and adding them to
__known_symbols__
.I think that specific issues should be submitted for each interface or framework.
The text was updated successfully, but these errors were encountered: