|
hai ...
a have some problems with memory
when creating Tabbed Dialogs ...
(when TCITEM.lParam = pointer to dialog ..)
every things i do correct, but after closing program
debugger sad:
Detected memory leaks!
Dumping objects ->
E:\home\projects\kTalk\MainDlg.cpp(343) : {105} client block at 0x00345438, subtype 0, 160 bytes long.
a CDialog object at $00345438, 160 bytes long
... and e.t.c ...
====================
ovverriding i also destroying them ...
CWnd *pWnd = (LPARAM)tci.lParam;
delete pWnd;
===============
maybe i should destroy them in other way ??
thanks
----------------
muaaa .. (:
|
|
|
|
|
I could be just guessing (as usual, but finding a bug is just a matter of a right guess anyway). I'm just gonna write some typical bugs (i've had these problems myself recently):
1. Before deleting a window (CWnd object) destroy a window with ->DestroyWindow() unless it isn't done earlier.
2. Before destroying a window make sure it doesn't own some objects like brushes, device contexts etc. - it could be it
3. before destroying any brush/context etc. make sure it's not selected by other objects - that's something I'm aware of very much
4. before creating any object destroy the previous one (example - I've been calling CBrush::CreateSolidBrush twice for the same CBrush object without calling CBrush::DeleteObject)
5. Maybe that tab control is the reason (it or it's elements are not deleted or destroyed - read carefully what they say about deleting it and it's structures)
Remember - be patient  (yeah, right...  )
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
But i have done it !!! (:
there is my DEL proc :
int CMainDlg::DelTab(int Index)
{
TC_ITEM tci;
CChatDlg *pWnd;
int iCount = m_tabs.GetItemCount();
int iCurrent = m_tabs.GetCurSel();
m_tabs.GetItem(Index,&tci);
ASSERT(tci.lParam);
pWnd = (CChatDlg *)tci.lParam; //CChatDlg is CDialog
pWnd->DestroyWindow();
pWnd = NULL;
delete pWnd;
m_tabs.DeleteItem(Index);
};
Sometimes its works... but i can't found a bug .. (: there it is .. !?
----------------
muaaa .. (:
|
|
|
|
|
Mandalay wrote:
there is my DEL proc :
int CMainDlg::DelTab(int Index)
{
TC_ITEM tci;
CChatDlg *pWnd;
int iCount = m_tabs.GetItemCount();
int iCurrent = m_tabs.GetCurSel();
m_tabs.GetItem(Index,&tci);
ASSERT(tci.lParam);
pWnd = (CChatDlg *)tci.lParam;
pWnd->DestroyWindow();
pWnd = NULL;
delete pWnd;
m_tabs.DeleteItem(Index);
};
Sometimes its works... but i can't found a bug .. (: there it is .. !?
Why do you set the pointer to NULL before deletion? Perhaps I missed something in another reply to this message...
Later,
Nathan
---------------------------
Hmmm... what's a signature?
|
|
|
|
|
As I said: be patient - inspecting the code I've noticed You reversed the order of two code lines. The proper order is:
delete pWnd;
pWnd = NULL;
...no comment... 
PS: Although delete doesn't set the pointer to NULL it is not necessarry to do that unless it's the only information about existance of an object.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Deleting a NULL pointer will do nothing and the original memory never gets freed. Try:
delete pWnd;
pWnd = NULL;
Best regards,
Alexandru Savescu
|
|
|
|
|
I'm not sure whether this will work, but it's simple to try. Override PostNcDestroy for your tabbed dialogs and add delete this as the last line of the function.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
...but keep in mind that "delete this" can be dangerous
Just kiddin'. Although delete operator removes the object, the code always remain in the memory (one for all objects of course).
I've just never seen anybody using "delete this".
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
I agree with you the procedure is a little weird, but this is the standard way to cleanup MFC modeless dialogs, for instance.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
thanks.
hehe. it works, no errors, no leaks .. no warnings ...
but sometimes ... it works without "delete this".
i couldnt understand.
(:
----------------
muaaa .. (:
|
|
|
|
|
Greetings:
I have an application whose view class is derived from CHtmlView. All is good except I do NOT want the user to be able to right click and have access to the 'Back', 'Forward', etc. that is available from the menu.
I have tried adding a handler for ::OnRButtonUp(UINT nFlags, CPoint point), but this never gets called. 
If I can just disable the right click menu, that would be fine. If I have to use a message override, I can just return nothing... I just need to trap the ON_WM_RBUTTONUP (or equivalent).
Thanks in advance for any help.
Alan Schneider
|
|
|
|
|
The proper way to do it is via the IDOCHOSTUIHANDLER flags.
The RButton messages will be interecpted long before your APP gets a chance
You could use PreTranslateMessage in desperation.
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
I am sick of fighting with Martin, I think I will ignore his posts from here on in, and spend the time working on articles instead.
Christian Graus
|
|
|
|
|
Thanks for the suggestion - It worked.
I went ahead and used the PreTranslateMessage method since I only care about one single event... the right button up.
BOOL CMyHtmlView::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message != WM_RBUTTONUP)
{
return CHtmlView::PreTranslateMessage(pMsg);
}
return TRUE;
}
Alan Schneider
|
|
|
|
|
In a mainframe event, the following
m_wndToolBar.GetToolBarCtrl().HideButton(ID_EDIT_COPY, TRUE);
does fine and hides the button. How do I hide a separator? I would have to specify its position as well, since I didnt see anything like ID_SEPARATOR1 etc...
THanks for your help,
ns
|
|
|
|
|
I have a horrible feeling you might be forced to remove and add all (except the offending separator) buttons again.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Try DeleteButton(). It takes an index, not a command id.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
how come all the ISAPI thingies like GetServerVariable and ServerSupportFunction and such don't handle unicode (LPSTR not LPTSTR)
also, what is the response header to send if my content ("<html>hello</html") is to be outputted in unicode format?
and will that allow me to output stuff based on a certain language like chinese or russian or something (e.g. right-click somewhere in IE6 and go to the 'Encoding' menu, you see lots of languages and stuff)? i want to be able to make my ISAPI extension flexible in that sense
-roman
|
|
|
|
|
These functions manage data that are stored HTTP headers --and HTTP is hopelessly based on ASCII.
It is only the contents of HTTP responses that can be encoded in codes other than ASCII.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If you read this message already - skip it. I just place it here one more time hoping someone will help me.
The question is simple, i have the following code for my popup menu:
Menu=new CMenu;
Menu->CreatePopupMenu();
(...)
Menu->AppendMenu(MF_STRING | MF_ENABLED, 0, "Insert");
Menu->AppendMenu(MF_STRING | MF_ENABLED, 0, "Delete");
(...)
Menu->TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON | TPM_LEFTBUTTON, Point.x, Point.y, ParentWindow);
Menu->DestroyMenu();
It works ok.
But i need to process commands to make it worth anything.
When I use:
Menu->AppendMenu(MF_STRING | MF_ENABLED, ID_INSERT_ATTRIBUTE, "Insert");
Menu->AppendMenu(MF_STRING | MF_ENABLED, ID_DELETE_ATTRIBUTE, "Delete");
These items appear as grayed and unavailable.
I've used CMenu::GetMenuItemID to check if the ID is assigned - it is (returned values were ID_INSERT_ATTRIBUTE and ID_DELETE_ATTRIBUTE).
I also used CMenu::EnableMenuItem to enable these (this function returned MF_ENABLED as a previous state of item  )
Did i missed something?
By the way - i have problems with CToolTipCtrl - i almost copied all code from one of MSDN's samples but it doesn't work. If someone has some experiences with ToolTips i would like to ask a few questions.
[ CoY0te ]
( greetings to all assembler coders  heh! )
|
|
|
|
|
This little jewel I found some years ago:
void CYourDlg::GfxCmdUIUpdateMenu(CMenu* pMenu, BOOL bDisableIfNoHndler)
{
ASSERT(pMenu == NULL || AfxIsValidAddress(pMenu, sizeof(class CMenu)));
if (pMenu){
CCmdUI cmdUI;
cmdUI.m_pMenu = pMenu;
cmdUI.m_pSubMenu = NULL;
UINT nMax = pMenu->GetMenuItemCount();
if (nMax == (UINT)-1)nMax = 0;
cmdUI.m_nIndexMax = nMax;
for (UINT n = 0; n < nMax; n++){
cmdUI.m_nIndex = n;
cmdUI.m_nID = pMenu->GetMenuItemID(n);
if (cmdUI.m_nID == (UINT)-1){
CMenu* pSubMenu = pMenu->GetSubMenu(n);
GfxCmdUIUpdateMenu(pSubMenu, bDisableIfNoHndler);
}
else cmdUI.DoUpdate(this, bDisableIfNoHndler);
}
}
}Use it just before TrackPopupMenu. Please tell me back if it worked.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Nothing.
The problem is, that items with nIDNewItem=0 (created by AppendMenu) are OK, but when i pass parameter greater then 0 to this function these items are disabled. This is the ONLY difference between these items. And more: I can add some items with nIDNewItem=0 and some with nIDNewItrm>0 in the same menu and only those with nIDNewItem>0 will be disabled (this is a popup menu with no submenus).
By the way - I've tested some negative ID values - -1000,-2000 and -3000 were enabled and -10000,-20000,-30000 were grayed. Funny thing, but it drives me crazy!
Is there any way to check the user's choice without processing the WM_COMMAND message? I didn't notice that CMenu class has any kind of GetSelectedItem method, so I doubt it, but it would be the simpliest way.
Anyway thanks for the answer. It's good that someone answered.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Those IDs have to have some command handler associated with them. Are you processing, for instance, ID_INSERT_ATTRIBUTE in any way?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I was supposed to, but I don't do that now since these items are "disabled" - can this really be it?
I thought, that if I don't do the processing itself, these items will be available, but they will affect no action when clicked - just that. Do I have to "create" commands somehow?!?!? Right now i'ts only:
#define ID_INSERT_ATTRIBUTE <value>
And the parent window's OnCommand method is almost empty (processes only ID_INSERT_ATTRIBUTE for testing).
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Yes you have to create those commands. Define them as WM_USER plus some offset of your choice. To implement a handler, take a look at the documentation for ON_COMMAND.
Also, you can use FALSE as the second parameter of GfxCmdUIUpdateMenu (this won't make the commands be handled, but at least you'll see the menu entries enabled.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Didn't work too.
I had these commands defined with #define directive.
I've changed them to WM_USER+n, and tried it in few different ways - no effect.
Both using that function with bDisableIfNoHndler set to TRUE and FALSE and without that function.
I'm running out of ideas.
I'm gonna get some sleep (it's 23:30 in Poland and I've got back from the pub recently  ).
Bye.
I'll be back tomorrow.
Thanks for the effort.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
