Modal dialog - Close - ESC
-
Huh? I am not pissed or anything. I think its absolutely waste to rename ID_CANCEL and then write code inside that oncancel function and all. If it is Just for the sake to argue, you can continue to rename everything and modify functions. Its that you know what it is and still you want to rename something and then edit existing functionality or add a button separately to close,,,..... Phew! I am tired. I will continue to use Pretranslatemsg.
:confused: Prakash is talking to me. What is ur problem You have an apple and me too. We exchange those and We have an apple each. You have an idea and me too. We exchange those and We have two ideas each.
-
:confused: Prakash is talking to me. What is ur problem You have an apple and me too. We exchange those and We have an apple each. You have an idea and me too. We exchange those and We have two ideas each.
i had been reading this thread. i thought PreTranslateMessage() is better. i always use that only. he told anybody using PreTranslateMessage() is pissed. so i replied.
-
Huh? I am not pissed or anything. I think its absolutely waste to rename ID_CANCEL and then write code inside that oncancel function and all. If it is Just for the sake to argue, you can continue to rename everything and modify functions. Its that you know what it is and still you want to rename something and then edit existing functionality or add a button separately to close,,,..... Phew! I am tired. I will continue to use Pretranslatemsg.
wow, cool down, i didnt say using pretranslate message is a bad way of using it, Like I said it would all depend on the design of the dialog.
-Prakash
-
i had been reading this thread. i thought PreTranslateMessage() is better. i always use that only. he told anybody using PreTranslateMessage() is pissed. so i replied.
Aljechin he told anybody using PreTranslateMessage() is pissed.
talk about misinterpretation. ;)
-Prakash
-
it all depended on the design on the dialog box. Instead of traditional IDCANCEL a different id say ID_CANCEL button can be added to the dialog which could call the baseclass OnCancel to cancel the dialog. from your reply you look like pissed off, just chill baby.
-Prakash
Yeah, but the "x" button and the system menu close functions don't work then. Steve
-
Yeah, but the "x" button and the system menu close functions don't work then. Steve
Exactly! That is what I am talking about and trying to explain, but he is talking something else. Either he is not understanding what we tell or he does not know it or he understands it, but just wants to argue. Leave him there. Regards, Rajesh R. Subramanian You have an apple and me too. We exchange those and We have an apple each. You have an idea and me too. We exchange those and We have two ideas each.
-
Hi Mike, Is handling the PreTranslateMessage() better or the one which you have given is better? How? My opinion is that when you write code inside the OnCancel() it will modify the functionality of the cancel button (and the close button of the window) too! Which in turn will stop the dialog from closing somehow.. Should another button be added to close then? Is this approach right? I am asking because I am a big fan of you and I need the reason behind your approach in this matter. Regards, Rajesh R. Subramanian You have an apple and me too. We exchange those and We have an apple each. You have an idea and me too. We exchange those and We have two ideas each.
In general, the higher-up the call stack that you can make a change, the better. Doing it on OnCancel() is as high up as you can go. The reasoning being, the higher-up layers are less likely to change between versions of MFC (thus breaking your code), and higher-up changes are easier for others to maintain. PreTranslateMessage() deals with the raw messages, you may perhaps run into weird cases regarding key states, shift states, and so on. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
-
In general, the higher-up the call stack that you can make a change, the better. Doing it on OnCancel() is as high up as you can go. The reasoning being, the higher-up layers are less likely to change between versions of MFC (thus breaking your code), and higher-up changes are easier for others to maintain. PreTranslateMessage() deals with the raw messages, you may perhaps run into weird cases regarding key states, shift states, and so on. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Hey Michael, Is there a way to identify how OnCancel message was called? i.e. by clicking on the button or pressing the ESC key. thanks
-Prakash
-
Hey Michael, Is there a way to identify how OnCancel message was called? i.e. by clicking on the button or pressing the ESC key. thanks
-Prakash
I've never had to do this myself, but if there is a difference, it would be in the
WM_COMMANDparameters - you could compare whatwParamandlParamare in those two cases, and then you'd know what you check for. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ -
In general, the higher-up the call stack that you can make a change, the better. Doing it on OnCancel() is as high up as you can go. The reasoning being, the higher-up layers are less likely to change between versions of MFC (thus breaking your code), and higher-up changes are easier for others to maintain. PreTranslateMessage() deals with the raw messages, you may perhaps run into weird cases regarding key states, shift states, and so on. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Michael Dunn wrote:
In general, the higher-up the call stack that you can make a change, the better.
Very good. But if it does not just solve the purpose, then I do not think it it is a sin to move a little lower into the stack! I read this same solution in your FAQ also. But it just is not the way to do it.
Doing this will stop the dialog from closing by clicking the cancel button or the X button even.
However it may prevent the dialog from closing on 'Escape' button press. But to solve a problem, I do not want to run into other problems.
How will i ever close the dialog then?
Add another button for it? Huh?
Michael Dunn wrote:
you may perhaps run into weird cases regarding key states, shift states, and so on.
Nothing weird. Shift state is readily available at GetKeyState(). I strongly believe that you would edit your FAQ also. Think on it! Regards, Rajesh R. Subramanian. You have an apple and me too. We exchange those and We have an apple each. You have an idea and me too. We exchange those and We have two ideas each. -- modified at 2:03 Wednesday 25th January, 2006