READIN

Thursday, October 9th, 2003

🦋 IDispatch

My policy of reading COM and .NET Interoperability straight through from the beginning, rather than skipping the stuff I am familiar with, paid off yesterday when I found out something about programming the IDispatch half of dual interfaces, which had eluded me until now.

IDispatch is an interface which allows you to support method and property calls on arbitrarily named members, meaning the client does not have to load type info. A common use for it is the "dual interface", in which type info is exposed but clients are given a choice whether to call methods directly or through IDispatch::Invoke. I always have supported it (in situations where I needed it and was not using a tool like ATL for the implementation) by hand-coding a lookup table in Invoke and GetIDsOfNames, and putting no code in the other two member functions. This is a big pain, primarily because of all the parameter translation you have to do in Invoke; and not supporting GetTypeInfo is a problem too, though it never made a difference in the situations where I did this. (Also I only support GetIDsOfNames halfway.)

But it turns out COM exports three functions which you can use to implement IDispatch using the type library generated by the compiler from your IDL code. They are LoadRegTypeLib, DispGetIDsOfNames, and DispInvoke. I have never done any work really with type libraries but it is nice to know I could. Chapter 4, which I am starting today, is all about COM Type Information.

posted morning of October 9th, 2003: Respond
➳ More posts about Readings

Tuesday, October 7th, 2003

🦋 COM Memories

Reading COM and .NET Interoperability -- the initial chapters are all stuff I'm pretty familiar with but I am reading it anyway, to make sure I'm on Troelsen's wavelength when it gets interesting. A note at the beginning of Chapter 2, that the COM specification was released in '93, made me realize my programming career has progressed in lock step with Microsoft's Visual Basic API. Well I was a little late coming on board... I wasn't programming when VB was introduced... What I am thinking of when I talk about the Visual Basic API is something that really starts with COM.*

My first project when I came to Xyris was to make some improvements to their RTList VBX control. (A VBX is a DLL which specifies a custom control for VB 3.x, and maybe VB 1 and 2 as well -- I don't know anything about versions prior to 3.x. VBX is the predecessor to OCX, the OLE Custom Control, which is what COM controls used to be called.) I worked on RTList throughout my years at Xyris, moving it from VBX to OCX and then rewriting the OCX control in ATL (enough acronyms yet?)

* On rereading I see that this is quite vague. What I am trying to get at is the notion of programming windows applications with Microsoft's suite of GUI development tools, of which VB is the original one. Visual Studio .NET is the current incarnation of this suite.

posted morning of October 7th, 2003: Respond

Friday, October third, 2003

My current reading (starting today) is Andrew Troelsen's COM and .NET Interoperability -- I expect it to be dry reading material compared to The Corrections and The Life of Pi; but I have kind of high hopes for it to be more engaging and better written than any of the other API documentation I have read recently. I just read the introduction and Troelsen seems prepared to get to the point clearly and without the annoying cuteness you see in many of these books. I also like that the book has only one author; many of these books are written by two or more people and do not have a clear authorial voice.

Anyways -- COM is what I work in by and large; and .NET is where I am headed; I have written one project in .NET so far and it was a pretty enjoyable experience. So I think this will be a useful book. I don't know how much I am going to blog about it -- depends on how useful it ends up being I guess.

posted morning of October third, 2003: Respond