C / C++ / MFC

// Make sure you've called OleInitialize()
...
//----------------------------------------------------------------------------------------
// Add/implement a COleDropTarget-derived class
class CMyTreeCtrlDropTarget : public COleDropTarget
{
protected:
   virtual DROPEFFECT OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point);
 
   virtual BOOL OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point);
  
public:
};
 
DROPEFFECT CMyTreeCtrlDropTarget::OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point)
{
   if (pDataObject->IsDataAvailable(CF_HDROP, NULL))
   {
      <code>// Use the passed point to hittest on the treeview control to select the appropriate item</code>
 
      return DROPEFFECT_COPY;
   }
 
   return DROPEFFECT_NONE;
}
 
BOOL CMyTreeCtrlDropTarget::OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point)
{
   if (pDataObject->IsDataAvailable(CF_HDROP, NULL))
   {
      STGMEDIUM StgMedium;
      pDataObject->GetData(CF_HDROP, &StgMedium, NULL);
      DROPFILES *pDropFiles = (DROPFILES *)::GlobalLock(StgMedium.hGlobal);
      TCHAR *pFileNames = (TCHAR *)((BYTE *)pDropFiles + pDropFiles->pFiles);
      //
      <code>// do something with file pathname(s) here</code>
      //
      ::GlobalUnlock(StgMedium.hGlobal);
   }
 
   return FALSE;//COleDropTarget::OnDrop(pWnd, pDataObject, dropEffect, point);
}
...
//----------------------------------------------------------------------------------------
// Add a member variable somewhere to hold a CMyTreeCtrlDropTarget object
CMyTreeCtrlDropTarget MyTreeCtrlDropTarget;
...
//----------------------------------------------------------------------------------------
// When the treeview control is created (its HWND is valid) then register the control with the drop target
MyTreeCtrlDropTarget.Register(pTreeCtrl);

Jeremy Falcon wrote:

Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.

Jeremy Falcon wrote:

We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.

// InlineSmaller.cpp : Defines the entry point for the console application.
//
 
#include "stdafx.h"
#include <iostream>
 
inline int Add(int l, int r)
{
	return l+r;
}
 
void PrintResult(int r)
{
	using namespace std;
	cout << r << endl;
}
 
int main(int argc, char* argv[])
{
	int res = Add(1, 2);
	PrintResult(res);
 
	return 0;
}

18:   int main(int argc, char* argv[])
19:   {
004010F0 6A 03                push        3
004010F2 E8 89 FF FF FF       call        PrintResult (00401080)
004010F7 83 C4 04             add         esp,4
20:       int res = Add(1, 2);
21:       PrintResult(res);
22:
23:       return 0;
004010FA 33 C0                xor         eax,eax
24:   }
004010FC C3                   ret

7:    /*inline*/ int Add(int l, int r)
8:    {
00401080 8B 44 24 08          mov         eax,dword ptr [esp+8]
00401084 8B 4C 24 04          mov         ecx,dword ptr [esp+4]
00401088 03 C1                add         eax,ecx
9:        return l+r;
10:   }
0040108A C3                   ret
 
18:   int main(int argc, char* argv[])
19:   {
00401100 6A 02                push        2
00401102 6A 01                push        1
00401104 E8 77 FF FF FF       call        Add (00401080)
20:       int res = Add(1, 2);
21:       PrintResult(res);
00401109 50                   push        eax
0040110A E8 81 FF FF FF       call        PrintResult (00401090)
0040110F 83 C4 0C             add         esp,0Ch
22:
23:       return 0;
00401112 33 C0                xor         eax,eax
24:   }
00401114 C3                   ret

Jeremy Falcon wrote:

Nevertheless, what you just described is really better served as a macro, considering the restrictions on inline functions and compiler issues associated with them.

Jeremy Falcon wrote:

Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.

Stephen Hewitt wrote:

This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.

Jeremy Falcon wrote:

We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.

Stephen Hewitt wrote:

I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:

Stephen Hewitt wrote:

I did read your posts and have done so again when preparing this reply. You assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save!

Stephen Hewitt wrote:

You’ve obviously interpreted my (correct) comments as a personal attack.

Stephen Hewitt wrote:

I can see no where in you post to justify you assertion that you, “didn't deny your points on one-line routines.”

Stephen Hewitt wrote:

Macros make debugging harder and are not type safe.

Jeremy Falcon wrote:

Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.

Stephen Hewitt wrote:

Or just use inline and save yourself the hastle and enjoy type safety to boot!