|
Which is the preferred way to terminate the modal dialog? I notice that no matter which one I use, the lines of code following it do get executed, even though the dialog itself has vanished!
i.e.
<pre>MYClass::OnOK()
{
CDialog::OnOK();
CMyDlg myDlg;
myDlg.DoModal();
}
</pre>
The original dialog vanishes and the second one gets spawned. This hapens even with EndDialog(IDOK).
That seems peculiar to me. I'd have thought that if the dialog itself is terminated, the subsequent statements would never be reached....
Thnaks,
ns
|
|
|
|
|
EndDialog() is a Win32 call. Its argument is the return value of DoModal(). CDialog::OnOK() does the same thing as EndDialog(IDOK). Also CDialog::OnCancel() does the same thing as EndDialog(IDCANCEL).
EndDialog() and CDialog::OnOK() are just function calls. If you want execution to end, you need to stick in a return; after the call.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
EndDialog() does not destroy the dialog immediately. It destroys the dialog at the end of the current message handler.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
nss wrote:
Which is the preferred way to terminate the modal dialog?
I just realized my thesis didn't include an answer to your question. I suggest using CDialog::OnOK() or CDialog::OnCancel(), unless you need to return a custom return value, in which case use EndDialog().
You typically do the latter when you have more than one button that ends the dialog, and you want to inform the caller which button the user clicked. For example:
CMyDialog dlg (this);
long nStatus = dlg.DoModal();
switch (nStatus) {
case IDOK:
doOkHandling();
break;
case IDCANCEL:
doCancelHandling();
break;
case ID_SomethingElse:
doSomethingElseHandling();
break;
default:
ASSERT (FALSE);
break;
}
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I wonder if there's a way of making Windows not reallocate the memory for CArray objects without using CArray::SetSize(int) function?
I mean I want to create a dynamic array of relatively large objects and I need pointers to the elements. When I add a new element with CArray::Add function, the operating system reallocates the memory and my pointers to the previous elements become invalid. Is there any way of 'fixing' the addresses of the elements?
|
|
|
|
|
Space Ace wrote:
When I add a new element with CArray::Add function, the operating system reallocates the memory and my pointers to the previous elements become invalid.
Not really. I suspect there are problems in your code. Can you post a sample?
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
If it's anything like vector you should be able to pass an initial size into the constructor, then it won't reallocate until you go over that size. That naturally removes one of the main advantages of a dynamic array.
By the way, CArray is absolute trash, you should ditch it and use vector instead.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Hello, the codegurus around the world.;)
Generally speaking, we can define Find function to find CArray index.
So, without the pointer of CArray, we can find any index with some
key value.
This means if we derived some class from CObject, we can insert
this class in CArray template.
(Or, I misunderstand something?  )
Please, don't send me your email about your questions directly.
Have a nice day!
Sonork - 100.10571:vcdeveloper 
-Masaaki Onishi-
|
|
|
|
|
Store the index instead of the pointer. You can always get the pointer back.
Joel Lucsy (jjlucsy@ameritech.net)
|
|
|
|
|
I see that This method is used by class CWinApp to translate window messages before they are dispatched to the Windows CE TranslateMessage and DispatchMessage functions from the MSDN but what in the world is the meaning of translate in this case? I cant find a technical definition of translate anywhere....
Thanks,
ns
|
|
|
|
|
You're reading the documentation for the CE version. Here's the Win32 doc:
The TranslateMessage function translates virtual-key messages into character messages. The character messages are posted to the calling thread's message queue, to be read the next time the thread calls the GetMessage or PeekMessage function.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks much! BTW I'm having a heck of a time with overriding the OnOK() and bad behavior (see my thread). I'm going to have to use the pretranslate msg I've tried and tried! If the OnOK() is blank (no base handler) all is well. But try to get rid of the OK button and it behaves bizzaerely...enter dismisses agin!
|
|
|
|
|
I'm having no luck preventing the dismissal of my modal dlg with the Enter key press by overriding the OnOk of the class. SO I am going to go with pretranslatemessage. Question before I invest time in the UI of the modal dlg:
There wil be a listcontrol on it and the user chooses an item which gets written to a textbox. associated with this textbox is another CEdit where the user enters a value. then I press a "Done" button which calls EndDialog(nRet);
Will pretranslate message interfere with any of these functionalities?
BOOL CLog::PreTranslateMessage(MSG* pMsg)
{
if ((pMsg->message == WM_KEYDOWN))// && (pMsg->hwnd == m_hWnd))
{
if (pMsg->wParam == VK_RETURN)
{
return TRUE;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
Thanks,
ns
|
|
|
|
|
OnOK() is the way to do this. If you don't want the dialog to close simply don't call the parent class OnOK().
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
|
Really, I did - my OnOK for the OK button is empty and Enter is ignored. But I dont want that button around. I want my own button that does some stuff then exits. So if I make the default Ok button invisible or delete it after making sure that OnOK() is blank (no CDialog::OnOK() being callled in it), the Enter dismisses it again! I cant keep a useless OK button around, and deleting it brings back the bad behavior.....
Thanks,
ns
|
|
|
|
|
You also need to add a new button (see my previous reply) with id IDC_DONE. That button's handler should eventually call CDialog::OnOK().
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
The new button is all very well. its the old OK button that doesnt want to be deleted or invisibled....and I really dont want a useless buttonaround...Really the enter behavior returns if you get rid of the OK button.
|
|
|
|
|
nss wrote:
ts the old OK button that doesnt want to be deleted or invisibled....
Sorry, I don't understand you're saying! There seems to be a disconnect between what you're trying and what's been suggested.
I've been doing the "get rid off the OK button and use a substitute" thing for years to provide precisely the behavior you want.
If you want, I can send you a little code example.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Let me try to explain more clearly. First I cleared out the OnOK() handler for my dlg class OK button. Then ran it - fine. No dismissal on Enter. Then added a done button, called CDialog::OnOK() in it. Works fine. Still no dismissal.
Then I deleted the old OK button and ran it. Hit enter! Viola - the dlg vanishes!
I'll email you my latest atttempt...
thanks for checking this out!
|
|
|
|
|
|
nss wrote:
Then I deleted the old OK button and ran it. Hit enter! Viola - the dlg vanishes!
Hitting Enter actually does one of two things:
1. If a push button has the focus, clicks that button.
2. If some other kind of control has the focus, clicks the default push button in the dialog.
It sounds like you saw one of those cases. Hitting Enter clicked your new button, and the handler called OnOK(), thus closing the dialog.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I've mailed you a sample.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks - yours works great (though its got nothing in the DEbug folder even though I built it! Thats something I've not seen before). ANyways - I sent you mine. It doesnt work! I even put in the return in my OnOK() that i didnt have. What do you think is the problem with my attempts?
aaaaargh!
|
|
|
|
|
nss wrote:
though its got nothing in the DEbug folder even though I built it! Thats something I've not seen before
WAH! MOMMMMMMMY! 
There's something very wrong with your system! I suggest a reboot. Really. Are you pulling another all-nighter? 
nss wrote:
What do you think is the problem with my attempts?
Did you get my email (not thru CP)?
Whatever happened to Avis? Has he disappeared off the face of the earth? A web search has yielded NULL.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
