Hi Mark,
CircleDock wrote:From my perspective, as Circle Dock's principal developer, I am quite happy to have any interaction between Circle Dock and Dexpot in the form of Windows messages.
are you sure you didn't just let the Sarge talk you into it?
No, we would of course appreciate a collaboration between our two project, and we'd be happy to provide all the assistance needed to make this work.
Let's take a simple example, switching Dexpot's active desktop. The Sarge envisages a Dock Item whose target would be the Dexpot executable with the command line parameter "-w 1" (in the case of switching to the first desktop). This actually gives Circle Dock - and Windows - quite some processing to do as Circle Dock has to create and fill a new process structure and then tell Windows to start the process.
While I think that in the case of switching desktops, creating a new process is an acceptable overhead, in general your are right, of course. Which is why we also have a window message based interface for communicating with third-party applications. In fact, it seems that nearly everything required for the interaction you've described is already in place. Let's see...
Circle Dock would check for a Registry entry (that Dexpot sets when it is loaded and running)
FindWindow("ThunderRT6FormDC", "Dexpot - Main Menu")
When our user clicks on a Dock Item, to switch Dexpot's active Desktop, Circle Dock simply does a SendMessage(DexpotMainHandle, DEXPOT_SWITCHDESKTOP, 1)
SendNotifyMessage(DexpotMainHandle, DEX_SWITCHDESKTOP, 0, 1) where 1 is the number of the desktop to switch to.
By the same token, Circle Dock will need to be informed of certain Dexpot changes and these include: when Dexpot's active desktop changes (preferably with the new Desktop number) and also when Dexpot is about to close and has started. I suggest that in such cases, Dexpot broadcasts messages
We do not currently broadcast messages, but you can pass in a window handle and Dexpot will send event notifications to this window: SendMessage(DexpotMainHandle, DEX_REGISTERPLUGIN, 0, YourWindowHandle)
"YourWindow" will then receive the following messages:
- DEX_SWITCHREQUEST, DEX_SWITCHING, DEX_SWITCHED
For all three, the low-word of the LPARAM value is the number of the desktop being left and the high-word is the number of the desktop being switched to. DEX_SWITCHREQUEST is sent before the switch starts. Have your WindowProc return DEX_SWITCH_DONTSWITCH in order to cancel the switch. But please only do this when it's really necessary and obvious to the user. DEX_SWITCHING is sent before the switch starts, but when it can no longer be blocked. DEX_SWITCHED is sent after the switch has finished.
- DEX_SHUTDOWN
This message is sent when Dexpot is closing.
- DEX_DESKTOPCOUNTCHANGED
This message is sent when the number of virtual desktops has changed. The WPARAM value contains the new number of desktops. To get the number of desktops at any time, use SendMessage(DexpotMainHandle, DEX_GETDESKTOPCOUNT, 0, 0).
The various DEX_* values are defined in the constants.h header of our
plugin SDK.
The last of these messages (DEXPOT_ACTIVE) would be very useful in cases where Dexpot is loaded after Circle Dock.
This one is currently missing. But I agree, it would be really useful to have this as a broadcast. We'll definitely implement it.
If this schema is accepted and codified, I can then add an additional field to the Dock Items' records whereby the user can specify whether individual Dock Items should be visible for all Dexpot desktops or only certain desktops (by number). This would permit the user to categorize his desktops by task-type and only see those Dock Items that relate directly to the task-type: eg Internet, Office tasks, development, etc., etc.
Awesome. Let me know if the stuff detailed above works for you, and if you need access to any other information/features from Dexpot.
Now off to get some actual food...