Hi Pablo, Before doing Invoke() in COMDispatchInstance>>#dispatch, the array of parameters for a COM method call is currently prepared under the assumption that the parameter types reported by COM for a particular method should be used directly, i. e. if a COM method reports VT_BSTR as its parameter type, then the parameter value is prepared as VT_BSTR. This is implemented in COMMethod>>#fillArguments:byTypeOn:. The fact is that this is not always a one-to-one association.
For instance, if a method reports VT_VARIANT as a parameter type, other variant types could also be send, not just VT_VARIANT, but VT_BSTR, VT_I4, ..., too. It's the responsibility of the server to do the conversion and report a problem if the conversion is not possible (for instance, converting a string '42' to integer 42 works). Many COM objects implementations report "vague" parameter types, like the VT_VARIANT that I mentioned, VT_USERDEFINED etc, and the fact is that the server on the other side is usually quite forgiving. So, the actual parameter value and its type that is prepared before the dispatch could depend also from the data on the client side - my point is that if the COM server is really expecting an integer number but is reporting VT_VARIANT, you can send to it the string '42' as VT_BSTR or integer 42 as VT_I4 or integer 42 as VT_I2 etc. My question is whether you had any plans to implement this behaviour, and if yes, how? Of course, one thing is sending parameter values as a client, but if we think about exposing Pharo classes through COM this should be carefully planned for. A mapping between Pharo variant type classes and VT classes is now prepared in TypeMapping class variable of Win32Variant. Maybe we also need a mapping between Pharo/ST types from Magnitude, String and other class families to COM VT types. Anyway, I'm progressing well and various calls to ADODB's objects are working - of course as a prototype :-) Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
