[tlbimpd] handling of noncreatable CoClasses used as parameters

[Numpsy]

As mentioned at http://www.dsource.org/forums/viewtopic.php?p=22966#22966, tlbimpd will suppress the output of CoClasses which are marked as non-creatable, and this can cause problems if those classes are used as parameters to other functions in the type library.

Making it output the non-creatable types avoids the issue, but i'm not certain if that's the best approach. Looking at the C++ files generated from the VC++ #import command, that both outputs the non-creatable coclasses, and outputs fnction definitons that reference the primary interface of the CoClass, rather than the CoClass itself.

[JesseKPhillips]

I'm not sure if I fully understand these types, but how does this sound. Output the type definition with a (at)disable this() {} which I believe will prevent being able to create the object in D.

[JesseKPhillips]

Oh, that would only be for D v2, for D1 it would probably work with private this().

[Numpsy]

/tries to remember how stuff works (i'm too used to visual studio and ATL doing everything for me).

tlbimpd marks the classes as abstract, so creating them isn't the issue.

However, you can't be passing D classes into COM functions as out parameters (the layout is wrong etc). What visual studio is basically doing when it generates the c++ wrapper functions is to replace pointers to the coclass with pointers to that classes base interface, and manually making that change to the generated .d file does allow the functions to be used successfully.

[JesseKPhillips]

You say that you don't know if outputing the type is the right appoarch, VC++ outputs a reference to the interface rather than the whole type. So what is the issue with just outputing the whole type, if the whole type isn't creatable (btw abstract doesn't stop the creating of the type, final abstract maybe)?

[Numpsy]

I've created a branch @ https://github.com/Numpsy/Juno-Windows-Class-Library/tree/tlbimpcoclass which outputs interface parameter types isntead of coclass parameter types.

This means that non-creatable classes aren't referenced anywhere, and methods that return them give you an interface that can then be used.

Seems to work on the Outlook typelibrary, though i haven't plugged it into a test addin yet.