How to avoid a dialog to close with a tree

Help
2005-01-05
2013-04-15
  • Steven Weiss
    Steven Weiss
    2005-01-05

    Hi John,
    I have a dialog with a tree_ctrl on it. I want to be able to edit the labels - so I added TVN_EDITLABELS. but when you edit one and press enter the dialog is closed - as expected.

    i added this piece of code to my dialog class:
    handle_event on_ok(answer a)
    {
      a = event_handled;
      return command<IDOK, BN_CLICKED> ().HANDLED_BY(&me::on_ok);
    }

    but unfortunately this doesn't work, too...the dialog is closed everytime! i think it is no special problem that has to do with the tree - i clicked on the OK button and the dialog closed. so you can easily try this problem out

    i stepped through the code and it boils down to these lines in dispatcher::dlg_proc:

    bool any_signal = tss.disp.matches_any_signal(h, wm_msg, wParam, lParam);
                    if ( any_signal && dlg->is_modal())
                        ::EndDialog(dlg->raw_hwnd(), 1);

    matches_any_signal() returns true and therefore the dialog is closed

    do you have an idea how i can avoid this problem?

    mfg steven

     
    • John Torjo
      John Torjo
      2005-01-10

      Hi,

      The problem is when you wait for the dialog to be closed. I assume it's a modal dialog.

      When you create it, you say something like:

      create_modal_dlg<..>(...) .wait();

      This is equivalent to:

      create_modal_dlg<..>(...) .wait(ok_pressed || cancel_pressed);

      If you don't want to close when ok is pressed, just say:

      create_modal_dlg<..>(...) .wait(cancel_pressed);

      Or:

      create_modal_dlg<..>(...) .wait(wait_for::destroy);

      However, in the last case, you need to handle the ok and/or cancel buttons, and destroy the window yourself.

      Best,
      John

       
      • Steven Weiss
        Steven Weiss
        2005-01-10

        yeah, this sounds correct.
        but it is a dialog on a tab_dialog control but i will take a look if i get it to work anyway

        thx for your reply!

         
        • John Torjo
          John Torjo
          2005-01-10

          The problem is when you wait for a modal dialog - for its ok/cancel buttons.

          (it should not matter if you have one or more dialogs on a tab dialog)

          That is, usually, you'll want to preserve the default behaviour: the Ok & Cancel buttons. Which is what win32gui does.

          Best,
          John

           
    • Steven Weiss
      Steven Weiss
      2005-01-11

      it works perfectly =)

      but i have another question: on the tab_dialog the tab-order (means if you press the TAB-key, not the tabs of the control ;-)) doesn't work - if you press the tab key the next sibling control in the dialog that owns the tab_dialog gets the focus. will you fix this in near future?

      mfg steven

       
    • Steven Weiss
      Steven Weiss
      2005-01-11

      argh, i must correct me...it does work perfectly for a simple tree on a dialog but not for the more complicated case (tree-on-dialog-on-tab_dialog-on-dialog)

      spy tells me that the dialog which owns the tree doesn't get a WM_COMMAND message for IDOK - instead the main dialog gets these WM_COMMAND's which is of course useless. i think this behaviour is another side-effect of the input-focus-problem i described in my last post...do you have any suggestions?

       
      • John Torjo
        John Torjo
        2005-01-12

        What comes to mind now, is not to provide an "Ok" button (in other words, your "Ok" button should have a different ID than 'IDOK') - and make sure there are no default buttons.

        This should not close the dialog after editing an item in the tree view.

        Or am I missing the point completely?

        Best,
        John

         
        • Steven Weiss
          Steven Weiss
          2005-01-12

          i did this tomorrow but then i got another strange behaviour: TVN_ENDLABELEDIT never succeeded, even if i used end_edit_label_now(false);

          after half of the day of debugging (!) it turned out that one event handler for a WM_USER-message caused the trouble:

          handle_event on_refresh()
          {
            populate_tree();
            return event<WM_REFRESH_TREE> ().HANDLED_BY(&me::on_refresh);
          }

          i don't call this message - but because WM_REFRESH_TREE is defined as WM_USER it is likely that it interfered with a win32gui message...after changing it to another id everything works like a charm :-)

          thank you anyway for your help!

          p.s. will you fix the problem with the tab key in near future? if not i can do it - i really need it ;-)

          mfg steven