file_dlg bug?

Help
dp
2005-07-18
2013-04-15
  • dp
    dp
    2005-07-18

    I have the following code:

    file_dlg dlg(true);
    dlg.filter("All Files (*.*)\0*.*\0\0");
    if (dlg.show(self)) {
        child(IDC_FILENAME_EDIT)->text(dlg.file_names()[0]);
        self->LoadFile();
    }

    When the common file open dialog is closed with 'X' button, the application hangs and I have to kill it through the task manager. Pressing ESC key or "Cancel" button however works fine.
    This issue is always reproducible. I'm using version 1.6.6 of the library.

     
    • Steven Weiss
      Steven Weiss
      2005-07-18

      hi dremon,

      i was able to reproduce your problem. as a temporary workaround i suggest you to say dlg.show(null_wnd). i think it's no problem inside file_dlg but in the wait()-function (when you click on pause in the debugger you will find yourself there)

      mfg steven

       
      • dp
        dp
        2005-07-18

        Thanks Steven, the workaround with null_wnd works. I'll stuck with it until the bugfix will be released.

         
      • dp
        dp
        2005-07-27

        Hi,
        after looking in dispatcher.cpp I've found the following code that seems to produce this problem:

        if ( wm_msg == WM_SYSCOMMAND)
            if ( wParam == SC_CLOSE)
                if ( !dlg->is_modal()) {
                      ::DestroyWindow( h);
                      found = tss.disp.m_wnds.end();
                }

        Commenting this fragment out solves the issue, however I'm not sure about possible side effects (still not very familiar with internal architecture, but definitely like the whole thing).

         
        • Steven Weiss
          Steven Weiss
          2005-07-27

          hi,
          i think the bug this has to do because win32gui automatically subclasses all windows (and thus also the common dialogs). the common dialogs are modal dialogs but the library doesn't recognize this because we didn't create the dialog with create_modal_dlg.

          unfortunately i can't solve the bug atm because i have currently another project but you can ask john (although i think he's busy, too...).

          if you can dig deeper into the problem and gather some information or even solve the bug by yourself i would really appreciate that :-)

          thanks!

          mfg steven

           
    • dp
      dp
      2005-07-28

      Steven,
      I suggest another solution, based on the fact that the owner window of the "true" modal dialog is deactivated.

      bool dialog::is_modal() const {
      if (m_callback != 0)
      return true;
      HWND owner = ::GetNextWindow(raw_hwnd(), GW_OWNER);
      return (owner != NULL) && !::IsWindowEnabled(owner);
      }

      If we are not using some obscure frameworks with own modal processing loops, I think this patch will give reliable results.

       
      • John Torjo
        John Torjo
        2005-08-03

        Hi dremon,

        I think this might just work. I'll give it a shot. Thanks!

        Best,
        John