How to avoid a dialog to close with a tree

[Steven Weiss]

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]

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]

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]

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]

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]

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]

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]

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