|
Use spy++ utility and check the message(s) when double-clicking My computer icon.
Me I think the message is for the SHELLDLL_DefView/SysListView32 classes that displays the icons, and not for #32769 desktop window.
|
|
|
|
|
|
Armond Sarkisian wrote: When I load the form, how can I get the value of name which is "John" to appear in the edit box for IDC_Edit1?
Assign a CEdit member variable (e.g., m_edit ) to the IDC_Edit1 control. Then just call:
m_edit.SetWindowText(name.c_str());
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
Armond Sarkisian wrote: What statement must I use to assign the CEdit member variable to the IDC_Edit1 control?
ClassWizard (Ctrl+W).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
SetWindowText for change text on the window and GetWindowText for retrive a text of the window
|
|
|
|
|
Hello all,
I'm studying some memory leaks that I have in one app that I'm writing, and I've seen that somehow the destructor of some of the dialogs is not called.
How can I ensure that this will happen?
Thank you in advance.
|
|
|
|
|
as any other object, dialog destructor is called when it goes out of scope (when is allocated on the stack), or when you delete its pointer (dynamically allocated). Please note that after EndDialog() ends the destructor is not automatically called, hence, if you need any cleanup at window closing, you have to override the OnClose handler and perform the cleanup there.
hope that helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I feel sorry because I've not explained that the dialog was not modal, but in fact, I'm trying to use the PostNCDestroy override function and it seems to work well.
But again, I do not understand why the destructor is not being called...
Thank you.
|
|
|
|
|
Maybe your CDialog goes never out of scope.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
How can this be after an ALT+F4 and getting the entire app closed?
|
|
|
|
|
As pointed out by DavidCrow if you allocate dynamically (i.e. using new operator) the Dialog and never delete it then its destructor will never be called, even if the app terminates.
Anyway, maybe posting the code will help...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Let me study it a little bit more, but by now what I must say is that adding the override to PostNCDestroy works like charm.
THANK YOU!
|
|
|
|
|
Joan Murt wrote: the dialog was not modal, but in fact, I'm trying to use the PostNCDestroy override function and it seems to work well.
Which means you have a modeless dialog. Do you have something like:
CMyDialog::CMyDialog(CWnd* pParent ) : CDialog(CMyDialog::IDD, pParent)
{
Create(IDD);
}
void CMyDialog::PostNcDestroy()
{
delete this;
CDialog::PostNcDestroy();
}
...
CMyDialog *pDlg;
pDlg = new CMyDialog;
pDlg->ShowWindow(SW_SHOW);
...
pDlg->DestroyWindow();
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Well, it is a little bit more complicated (but not a lot more ) in fact there are several property sheets that have several property pages that are being created dynamically at runtime.
Then when the main dialog is getting destroyed implicitly the other dialogs that are not modal are being destroyed... As I said it seems to be working... with PostNCDestroy.
|
|
|
|
|
Joan Murt wrote: ...I've seen that somehow the destructor of some of the dialogs is not called.
How are you verifying this?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I do it by placing a breakpoint there... (Moreover I'm changing all my destructors for PostNCDestroy overriden functions and it seems that the memory allocated becomes free).
|
|
|
|
|
I'm not sure if this helps, but a common approach with modeless dialogs is for them to delete themselves in their PostNcDestroy() handler, something like this:
CMyModelessDlg *dlg = new CMyModelessDlg;
dlg->Create(...);
dlg->ShowWindow(SW_SHOW);
CMyModelessDlg::PostNcDestroy()
{
CDialog::PostNcDestroy();
delete this;
} The WM_NCDESTROY message is guaranteed to be the last Windows message sent to the dialog. The PostNcDestroy handler, which is called after the window itself has been destroyed, is the last time a member of the MFC object will be called.
Using this technique, you don't need to keep track of when the user closes the modeless dialog. If you read my sig, you'll notice I've been here before .
Software Zen: delete this;
|
|
|
|
|
Nice thing to know, and yes, it seems a software zen
The thing here is that al the dialogs are not really dialogs, they are property pages...
But again, nice to know that.
Thank you.
|
|
|
|
|
Should I free everything before CDialog::PostNcDestroy(); or there is no difference if I do it before or after?
I'm not sure, but could it be interesting to delete/free all the members of that dialog before CDialog::PostNcDestroy(); and delete this; just after?
Thank you in advance.
|
|
|
|
|
Generally speaking, I do my cleanup before the CDialog::PostNcDestroy() call. This sort of makes sense, since the calling the base class PostNcDestroy() function passes the operation 'up' the hierarchy, and any derived version of that operation should be completed first.
I use PostNcDestroy() for things like calling DeleteObject on loaded resources (bitmaps, icons, fonts, etc.). I try to make it a practice to restore the MFC object to its initialized state, in the case user of the object is going to recreate the Window that the object manages.
Software Zen: delete this;
|
|
|
|
|
|
any easy way to scan a string that a user inputs in an editbox control,
for characters and remove them from the string?
charachters like: \ / ? * : " < > |
say i have this function...
void CMyDlg::OnCheck()
{
GetDlgItemText(IDC_EDIT1, str);
//do a scan of the string to see if it contains the characters \ / ? * : " < > |
//remove them from the string
//return the string without the characters
MessageBox("Your string: "+str,"");
}
or any other way to only let the user input only a-z and A-Z characters in the editbox?
thanks.
|
|
|
|
|
you can take advantage of CString.
There is a member function that wil automatically remove the chars or substrings that you pass to it.
I think it's called .Remove("");
You should call:
UpdateData();
editboxstring.Remove("/");
From the MSDN:
CString::Remove
int CString::Remove( TCHAR ch );
Return Value
The count of characters removed from the string. Zero if the string isn't changed.
Parameters
ch
The character to be removed from a string.
Remarks
Call this member function to remove instances of ch from the string. Comparisons for the character are case-sensitive.
Example
//remove the lower-case letter 't' from a sentence:
CString str("This is a test.");
int n = str.Remove('t');
ASSERT(n == 2);
ASSERT(str == "This is a es.");
|
|
|
|
|
thanks, this really helped a lot, it worked like a charm.
|
|
|
|