I had to rewrite a custom file dialog (derived from MFC's CFileDialog) to WTL's CFileDialog. I have a bit of a problem to retrieve data when I don't have access to the dialog object itself. Imagine the following.

I have a member in the class

static WNDPROC m_wndProc;

I initialize it in the following static member fnct.

void CMyFileDialog::OnInitDone(LPOFNOTIFY lpon)
{
  m_wndProc = (WNDPROC)::SetWindowLong(thisHWND, GWL_WNDPROC, reinterpret_cast<long>
                                       (&CMyFileDialog::WndProcSelect));
}

The handle comes into the callback method with no problem and I can "connect" to it with CWindow

LRESULT CALLBACK CMyFileDialog::WndProcSelect(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  // ...
  CWindow callerWnd(hwnd);
}

And here, I don't know the real methodology to convert the CWindow to my CMyFileDialog. As I think, this CWindow class is just connected somehow to the handle itself, but does not the same object as it was created before. So for example, if I have a CString or other members in my CMyFileDialog, it won't access its state, because it was created in another object.

有帮助吗?

解决方案 2

You could always use SetWindowLongPtr with your "this" pointer, then it would be fairly easy to extract the pointer to your CMyFileDialog.

其他提示

I think you are doing something wrong here. You have access to the message map without having to modify the WndProc (that is something that the CFileDialogImpl will have already done).

See for example http://www.codeproject.com/Articles/12999/WTL-for-MFC-Programmers-Part-IX-GDI-Classes-Common#usingcfiledialog, where they simply

BEGIN_MSG_MAP(CMyFileDialog)
   CHAIN_MSG_MAP(CFileDialogImpl<CMyFileDialog>)
END_MSG_MAP()
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top