EasyDMS development - Bug in the ICustomSearchPageAddin?

Question

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 )
     AFX_MANAGE_STATE(AfxGetStaticModuleState());     
     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() ;
          pTab->Create(GeneralSearchTab::IDD,parent);
          CComObject<CGeneralSearch> *page = new CComObject<CGeneralSearch>;
          page->setWnd(pTab);
          page->AddRef();
          *pPageAvailable = VARIANT_TRUE;
          *poData = page;
and so on.
In the CGeneralSearch I implemented:
STDMETHODIMP CGeneralSearch::get_hWnd ( long * pHwnd ){
     AFX_MANAGE_STATE(AfxGetStaticModuleState());
     if(!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)
               break;
     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.

Answer 1

Hi, thanks for the answer.
I first tried this using two different tabs. I implemented GeneralSearch and AdvancedSearch  classes implementing the ICustomSearchPage interface. I also created two different dialogs GeneralSearchTab and AdvancedSearchTab and referred them without upcasting (later on I used CDialog to test things). Both tabs showed ok but putting cursor over first one would crash the application immediately. I debugged and it is the windows messages that crashes it. I think the parent window (tab control?) is doing something wrong with the first tab. It seems that I can create as many tabs I want to and even use same class over again and it is only the first one that fails.
Well, I did lot of testing because there wasn't examples of this and no proper documentation of the API, so I might have had CDialog * upcasting there but I'm pretty sure that I first tried without upcasting.
Fortunately we found out that the other tab is not yet needed, so I can continue with the project. As I said, if I only create one tab, that works perfectly and we have already modified abap code for the extra fields we need.
I will try to test this again starting from scratch this weekend.
-Miikka-