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())
matches_any_signal() returns true and therefore the dialog is closed
do you have an idea how i can avoid this problem?
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:
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:
However, in the last case, you need to handle the ok and/or cancel buttons, and destroy the window yourself.
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!
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.
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?
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?
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?
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:
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 ;-)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.