Skip to Content
Former Member
Nov 22, 2009 at 12:05 PM

EasyDMS development - Bug in the ICustomSearchPageAddin?


Customer has need for special search page for the documents in the EasyDMS. I checked the Addin interface and found the ICustomSearchPageAddin and ICustomSearchPage interfaces. After some trying I got new nice new custom made tab in the search. What I did was little bit of tweaking of the property page example in the Wiki. Basically I did this:

STDMETHODIMP CSearchAddin::raw_CreatePage( 
	long	pageIndex, 
	long	hWnd,
	struct IEasyDmsApplication * pEasyDms,
	struct ICustomSearchPage **poData,
	VARIANT_BOOL * pPageAvailable )

	CWnd * parent = CWnd::FromHandle((HWND)hWnd); // Get the parent window from  handle 

 	if(!pEasyDms || !pPageAvailable || !poData)
		return E_POINTER;

	if ( pageIndex == 0) {
		CDialog *pTab = new GeneralSearchTab() ;
		CComObject<CGeneralSearch> *page = new CComObject<CGeneralSearch>;

		*pPageAvailable = VARIANT_TRUE;
		*poData = page;

and so on.

In the CGeneralSearch I implemented:

STDMETHODIMP CGeneralSearch::get_hWnd ( long * pHwnd ){

		return E_POINTER;
	*pHwnd = (long)m_page->GetSafeHwnd();
	return S_OK;


With one tab, this seems to work ok, but if I add more tabs (return more than 1 from the get_Pages method) the first custom tab will always crash when receiving any message (example WM_MOUSEMOVE). Crash happens in the explorer.exe process WalkPreTranslateTree method when calling the PreTranslateMessage.

BOOL PASCAL CWnd::WalkPreTranslateTree(HWND hWndStop, MSG* pMsg)
	ASSERT(hWndStop == NULL || ::IsWindow(hWndStop));
	ASSERT(pMsg != NULL);

	// walk from the target window up to the hWndStop window checking
	//  if any window wants to translate this message

	for (HWND hWnd = pMsg->hwnd; hWnd != NULL; hWnd = ::GetParent(hWnd))
		CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
		if (pWnd != NULL)
			// target window is a C++ window
			if (pWnd->PreTranslateMessage(pMsg))  <----------CRASH HERE
				return TRUE; // trapped by target window (eg: accelerators)

		// got to hWndStop window without interest
		if (hWnd == hWndStop)
	return FALSE;       // no special processing

I did some debugging, and the handle hWnd is the correct handle of the CDialog I created for the tab. This only happens with the first created tab when there is more than one custom tab. If I don't return any hwnd in the get method for the dialog, I get one empty tab but the others work well. This definately seems to be some sort of bug in the interface when initializing the tabs.

Have anyone got this working? I tried with 6.0 and 7.0 and both fail same way.

Oh, and I think the search interface I badly designed. It is always calling the normal search first. It would be lot wiser to be able to disable the original search if using custom. Other option would be to provide the search result list in some interface so it could be filled with any own dialog.