OnAcceptDropFiles?OnDropFiles

I'm facing the same issue... did you find any way to solve this?

You might want to PM the OP to get the answer, Apparently this is a month old thread and no one answered lostfly, so he might have figured it out ages ago on his own

Pixeleo,

Thanks for the suggestion... just did.

Can't hurt to email [email protected] too

Thanks Zubaz,

Already did... waiting for a response.

Well... today I received the response from Stardock Support:



I would say no more until I get a response to my reply...

Hum, I don't quite understand the support response here. This problem has been reported to the dev (Jeff) multiple times from as far back as 2004. Surely, there is a bug open in the bug database now and making a quick search for "OnAcceptDropFiles" would have given them at least something.

I'm curious to know what exactly was the content of your message. If you were simply asking for help, maybe that's the reason they responded like that. A quick google search gives you this link saying it's broken. So it's more like a bug report than a request for documentation.

Anyway, clearly the documentation is outdated and ObjectDock doesn't implement the "Docklet API" the way it used to do.

OnDropFiles is not called anymore, instead you have to implement OnDropData.

Here is an example (without full error checking, release of pUnknown in STGMEDIUM if not NULL, etc...):

HRESULT CALLBACK OnDropData(IDataObject *pDataObject, DWORD grfKeyState, DWORD *pdwEffect)
{
	FORMATETC fmtetc = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
	STGMEDIUM stgmed;

	// ask the IDataObject for some CF_HDROP data, stored as a HGLOBAL
	if(pDataObject->GetData(&fmtetc, &stgmed) == S_OK)
	{
		// We need to lock the HGLOBAL handle because we can't
		// be sure if this is GMEM_FIXED (i.e. normal heap) data or not
		HDROP hdrop = (HDROP)GlobalLock(stgmed.hGlobal);

		UINT  uNumFiles;
		TCHAR szNextFile [MAX_PATH];

		// Get the # of files being dropped.
		uNumFiles = DragQueryFile ( hdrop, -1, NULL, 0 );

		for ( UINT uFile = 0; uFile < uNumFiles; uFile++ )
		{
			// Get the next filename from the HDROP info.
			if ( DragQueryFile ( hdrop, uFile, szNextFile, MAX_PATH ) > 0 )
			{
				MessageBox(NULL, szNextFile, "Sample Docklet", MB_OK | MB_ICONINFORMATION);
			}
		}

		// cleanup
		GlobalUnlock(stgmed.hGlobal);
		ReleaseStgMedium(&stgmed);
	}

	*pdwEffect = DROPEFFECT_LINK;

	return S_OK;
}

And here we have a nice snippet of code for support, much better than the standard response

Thanks Littleboy,

I think I needed something like you responded... sure I found the 2004 posts here and in Aqua-soft, but I have been doing Docklet development for just three months, when I was those post, my initial reaction was that they were too old and that "maybe" those issues where already taken care of.

I do not pretend that stardock's support will solve my "issues" with docklet development but is discouraging to recieve such a response when I have donde (as to date) 7 docklets... maybe they are not the best-of-the-best (surely they arent), and maybe they really stink. But hitting a wall... well that disapoints me.

I can only thanks you all, the Master Developers which have been around for years...

Thanks again.

Well I got a little chat with the developper after that post (thanks again Jeff!), which cleared a few more things, so it was mainly a matter of knocking on the right door

Littleboy,

Maybe it's all my fault, maybe I did not ask the right questions, maybe... but anyway, you did help me... back to the kayboard.

I really appreciate your help.

Littleboy,

Yes! it worked just fine... know I am able to get the file names that are dropped on the docklet... Thanks!

fedroponce
HRESULT CALLBACK OnDropData(IDataObject *pDataObject, DWORD grfKeyState, DWORD *pdwEffect)
by this function,
how to know WHICH docklet to accept files?
thanks

Just for reference, a way to know which docklet was called is to save the docklet data pointer in the call to OnAcceptDropFiles and use that in the next call to OnDropData (and hope that ObjectDock does not start to cache the results in the future...).