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
Support customizing COM behaviors #35
Comments
When tB supports #9 (unsigned datatypes) then we have full control of stdole.IUnknown. :) |
Yes but if tB generates code for handling the |
Sure. I meant it's then easier to "interact", not to replace the "implementation".
Though one obstacle would remain. stdole.IUnknown::QueryInterface returns HRESULT, thus a sub in tB. |
Btw, IUnknown and IDispatch cannot be overriden or "reimplemented" in classes. Even by custom interfaces as of twinbasic/twinbasic#388 are not allowed to match VBx behavior. |
The procedure that returns a I have yet to have a need to implement the |
How/where could we define (once implemented) a [PreserveSig] attribute on stdole.IUnknown::QueryInterface ? |
The redefinition of an existing interface would look something like this:
With the redefined interfaces, you can then cast an object into As you can see, this wouldn't require you to write a IDL file; you'd be able to do it all in the tB source. .NET COM interop is pretty powerful because of capabilities like those. |
Ben, Also, was there anything like this sort of "extending the COM interface" thinking that led MS into the infamous "Great ADO library f*ck-up"? |
As I mentioned, Automation is a pretty narrow subset of COM and that limits the potential of VBx a lot. There are far more COM stuff out there that aren't Automation-compatible. To provide an example, a large majority of them implements only the Another example of non-Automation-compatible interface would be those that exposes a C-style array in the definition. That's a big No-No in VBlandia - they must be all Then sometimes there are private/undocumented COM interfaces that is known and you want to use it instead. Finally, sometime, it's just more convenient to redefine the interface with compatible data types for ease of use within your code. For some examples, take look at Rubberduck's TypeLib API which was helpfully developed by Wayne. This class is particularly a good example where we can work around buggy implementations and make it work for our purposes. Take particular note of this line:
If you follow the definition of the Could it have had helped with ADO fiasco? Maybe, but it's only to work for your own codebase, not for the other guy's codebase using the provided ADO type library. |
One major issue I have had with VBx was that Microsoft simply tried too hard to make it hard to customize the behavior of the COM objects. As a consequence, the VBx is pretty much limited to Automation specifications, which is a pretty narrow subset of COM ecosystem. In fact, .NET COM interop is considerably more powerful compared to what can be achieved in VBx and that is in spite of the interop layer that is required to work between COM and .NET. In the thread about inheritance, I commented:
Originally posted by @bclothier in https://github.com/WaynePhillipsEA/twinbasic/issues/73#issuecomment-826012467
I'm splitting this out to its own issue so that it can be considered as I think that is something that doesn't require inheritance but would go a long way toward making tB more powerful and capable of working with non-Automation COM objects. The interface approach that .NET uses for customizing the COM behavior seems to be a good way of enabling higher degree of control without having to wade into the level of C plumbing.
References:
ICustomQueryInterface
IReflect
ICustomMarshaler
The text was updated successfully, but these errors were encountered: