possible bug

Help
2004-11-15
2013-04-15
  • Steven Weiss
    Steven Weiss
    2004-11-15

    hi,
    i only wanted to open a modal dialog but experienced strange behaviour...

    ok, let's go:

    1. i have a dialog sitting on an sdi_frame

    2. the dialog has a button to open a modal dialog. the event-handler for this looks like this:

    handle_event OnEdit()
    {       
       TRACE("before");
       create_modal_dlg<EditDlg> ( window() ).wait();
       TRACE("after");

       return command<IDC_BTN_EDIT> ().HANDLED_BY(&me::OnEdit);
    }

    3. when i click on the button - it works! but when i want to close the modal dialog with the X the dialog won't get closed but a new one is opened!!!

    4. for debug purposes i wrote the two TRACE-statements before and after the wait(). but all i see is "before" in the output window. when i try to close the dialog another dialog pops up and another "before" appears...

    do you know how to solve this problem? my app is very small and so i don't think it's a problem in my code. the modal dialog even has no event handler yet...

    greetz steven

     
    • Steven Weiss
      Steven Weiss
      2004-11-17

      ok, i pointed out what went wrong: on the dialog i placed a custom control with the dialog editor of vc7.0 and set the class name to "abcd_control_1.0".

      in the code i had a new window class ABCDControl which is exactly implemented as instructed on the docs:

      create_info ABCDControl::def_create_info() {
          const char* pchClass = "abcd_control_1.0";

          if (::RegisterClassEx( &window_class_info().wnd_class_name(pchClass).raw_info() ) == 0)
              _ASSERTE(false);
          return create_info().class_name(pchClass)
                  .style( WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | WS_TABSTOP);
      }

      bool ABCDControl::matches_hwnd(HWND)
      {
          return true;
      }

      and of course derived from auto_mapping and window_base. because i was so busy with catching the strange behavior of the dialog i didn't realize that the custom control wasn't displayed (it's very small and unconspicuous). instead there only was a small white rectangle.

      when i remove the control from the dialog the dialog closes correctly! so i tested the custom control instantiation and i discovered the following:

      - def_create_info() gets called -> OK
      - matches_hwnd() is never called -> ARGHH!
      - therefore the constructor of ABCDControl is also never called and the control isn't created -> ARGHH!

      i think there's a bug in placing a custom control on a dialog. can you please fix this? i will also take a look in your code, perhaps i'll find the bug

       
    • Steven Weiss
      Steven Weiss
      2004-11-17

      i solved it: the problem lies in the dispatcher::register_window() function, at this point:

      if (    (wnd_dlg_proc == reinterpret_cast<LONG_PTR>(&dispatcher::dlg_proc)) ||
                  (wnd_wnd_proc == reinterpret_cast<LONG_PTR>(&wnd_proc)) )

      wnd_wnd_proc has always the same adress as wnd_proc and therefore won't be subclassed.

      and here's a workaround:
      LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
      {
          return ::DefWindowProc(hwnd, uMsg, wParam, lParam);
      }

      create_info ABCDControl::def_create_info() {
          const char* pchClass = "abcd_control_1.0";

          if (::RegisterClassEx( &window_class_info().wnd_class_name(pchClass)   
                                                     .wnd_proc(WindowProc)
                                                     .raw_info() ) == 0)
              _ASSERTE(false);
          return create_info().class_name(pchClass)
                  .style( WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | WS_TABSTOP);
      }

      perhaps you can fix this problem or mention the workaround in the docs