ObjectDock Docklets are DLL programmed in C or C++ that exports a few callbacks functions. These functions are called when a user manipulate the docklet. Building a docklet in .Net directly is impossible as ObjectDock doesn’t support managed code docklets. Thus, you need some kind of “proxy” that knows about .Net docklets and will be able to interact with them, relaying info to ObjectDock as needed.

Here is a picture that summarize the interactions between the different parts (I know, I could have made an UML Class diagram, but hey, it’s Christmas and I wanted a nice looking picture )

The Interop Docklet is just a normal docklet that exports all of the possible callbacks functions. Whenever a callback function is called by ObjectDock, the Interop Docklet transmits it to the currently loaded .Net Docklet. The only problem is that you cannot call managed code from unmanaged code directly, you have to use COM to access managed dlls.

Each .Net Docklet should implement the interface IDockletInterface (basically identical to the native docklet callbacks). The Interop docklet knows the GUID of the interface and can create an instance of the .Net Docklet using CoCreateInstance. However, for the call to succeed, the .net docklets have to be registered as COM objects. Asking the user to manually register each plugin with regasm was obviously not an option.

As there is no way (AFAIK) to programmatically register managed COM objects from unmanaged code, the Interop Docklet contains hardcoded info about the DotNetHelper DLL. When the docklet is called for the first time, it write that info in the registry. Then, when a CoCreateInstance call fails, it calls the RegisterDocklets function in DotNetHelper DLL that will walks through the different .Net docklets and try to register them. Problem solved (well almost, but I’ll keep that for another article )

The NetDockletHelper DLL also provides the Docklet class that encapsulate SDK functions and keeps the static data associated with each docklet (such as the docklet handle and the different folder paths). Docklet programmer can also use the LOG function from the Util class for debugging purposes.

I’m looking for people to help me test .Net Support for ObjectDock.

What you will have to do is simply try to build a docklet using the sdk and send me suggestions & bug reports (or not, if you feel evil :)). The more of the SDK you use, the better, of course, but building a simple docklet will work too.

Here is an explanation of the way I build it and how it works:

Last week, I started working on a way to build ObjectDock docklets in C#. Currently ObjectDock only allows you to build docklet using C/C++. As I have no access to ObjectDock internals, the only way to have docklets using managed code is to build a “proxy” docklet and call into managed code using COM.

The following picture shows the interaction between the different parts. When building a .Net Docklet, the only thing you have to care about is the docklet code itself (the Interop & helper dll are supplied and do not need to be modified).

The API is similar to the native SDK API. Each .Net Docklet has to implement the IDockletInterface interface (basically, the exportable functions from the native API). The native SDK functions are provided through the docklet class found in the DotNetSDK dll (the docklet handle & private data are encapsulated, so it’s somewhat cleaner than the native API).

The interop docklet can be used in two different way: in standalone mode or in multi-docklet mode. In standalone mode, the programmer distributes the interop & helper dlls along with it’s .Net docklet and set the interop to autoload it’s plugin. It’s completely transparent to the user. In multi-docklet mode, you only distribute the .net docklet part (users should have the “runtime”) and users could choose from a selection of docklets the one to load.

If you want to help me test it, drop me a mail.

Merry Christmas everybody