C / C++ / MFC

FirstPrevNext

Re: STL Map and function pointers Chris Losinger26-Mar-01 9:44 Chris Losinger 26-Mar-01 9:44  i'm not sure if it's an MS problem or not (really, i don't know). but it's caused when identifier names grow too large due to template expansion (which STL collections apparently do a lot of). i just always toss that pragma in whenever i use STL, just to keep things quiet. there used to be a lot of info on this on Deja.com, but i don't see it anymore. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com Re: STL Map and function pointers Jamie Nordmeyer26-Mar-01 9:48 Jamie Nordmeyer 26-Mar-01 9:48  Thanks for the help, Chris! Jamie Nordmeyer Portland, Oregon, USA Re: STL Map and function pointers Erik Funkenbusch26-Mar-01 12:11 Erik Funkenbusch 26-Mar-01 12:11  MS's c++ compiler is still based on a very old version of the C++ compiler that predates both the STL and templates. MS has modified it to allow templates and do a lot, but some of the basic issues surround debug info are still based on the old MS "code view" debugger (which was actually licensed from NuMega). One of those limitations is that the debug symbol name cannot be larger than 255 characters. Unfortunately, when STL templates expand, they often generate names that are larger than 255 characters. This causes the compiler to issue a warning that it is truncating the debug info to stay within the 255 character limit. This doesn't effect C++ code built in release mode, and it doesn't effect the actual code in debug either, just the debug information, which can cause problems for the debugger (but usually not). It's an informational warning, and can be safely turned off. This isn't a "problem with STL", but it is annoying. Re: STL Map and function pointers 26-Mar-01 14:57 26-Mar-01 14:57  And just to make it a little more annoying, it's not always possible to turn it off! http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP We have had several situations with complex header includes where no amount of "#pragma" will stop the warnings - but we have always been able to solve this by reorganising headers (changing the order of includes and sprinkling a generous helping of #pragmas, basically). Re: STL Map and function pointers 26-Mar-01 15:00 26-Mar-01 15:00  And just to make it a little more annoying, it's not always possible to turn it off! http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP We have had several situations with complex header includes where no amount of "#pragma" will stop the warnings - but we have always been able to solve this by reorganising headers (changing the order of includes and sprinkling a generous helping of #pragmas, basically). hmmmm.... another one l a u r e n26-Mar-01 3:03 l a u r e n 26-Mar-01 3:03  hi all twice in one day huh? i must be becoming one of those idiots i talk about wierd one (for me anyways) ... have a dialog with a treectrl in it ... tree gets built ok and all ... at the start of the tree build proc i do a m_tree.deletallitems() to clear it out ... if i call my tree build more than once i get an memory error on exit of the dialog: HEAP[prog.exe]: Invalid Address specified to RtlFreeHeap( 130000, 15caa8 ) looking at the memory i see the captions i inserted into the tree and i *know* my code isnt leaking memory (at least any memory i alloc i free) ... the only solution i have found is to delete the treectrl completely and re-create one every time i redraw it ... sounds nuts huh? the app is unicode and i'm wondering if there might be a bug in the mfc libs? or am i completely turning into an idiot and should retire from coding altogether? thoughts & help appreciated --- "every year we invent better idiot proof systems and every year they invent better idiots" Re: hmmmm.... another one 26-Mar-01 10:45 26-Mar-01 10:45  hmmm... Duh.. so much for 20 years of coding! Huh? Re: hmmmm.... another one 26-Mar-01 10:47 26-Mar-01 10:47  and i'm wondering if there might be a bug in the mfc libs? Yes sure! And now you got to figure our how to let the MS know about it! But how? hmmm... Duh.. so much for 20 years of coding! Huh? Re: hmmmm.... another one l a u r e n26-Mar-01 11:30 l a u r e n 26-Mar-01 11:30  gee thanks your constructive answer has shed a lot of light on the problem for me ... i can sleep safer at night knowing your there for me --- "every year we invent better idiot proof systems and every year they invent better idiots" Re: hmmmm.... another one Erik Funkenbusch26-Mar-01 12:39 Erik Funkenbusch 26-Mar-01 12:39  While i'm not arguing that there aren't bugs in the MFC libraries, chances are something like this would have been found a long time ago. It sounds like it may be a heap or stack corruption, which could result from overrunning a buffer. Re: hmmmm.... another one Tim Deveaux26-Mar-01 13:31 Tim Deveaux 26-Mar-01 13:31  I recently saw a form of this heap corruption in an app I am working on. I was able to trace the deallocation to an object created by a third party DLL. Linking statically to the third party lib solved the problem, and since that seemed to be a neat thing to do in other ways, I left it at that. Hmmm.. would have to check my notes on that one... Do you notice any dif in release/debug and static/dynamic links (to the MFC)? Are you allocating any strings that might be assigned too many chars? (That's one that might pass in debug, and/or have unicode implications) Or using more than one allocation routine? Damn... you do come up with the toughies... oh well - you did say "thoughts appreciated" solution... l a u r e n26-Mar-01 20:43 l a u r e n 26-Mar-01 20:43  ahem it turns out that vc had goofed up all my resource values in the resource.h file and i had 3 buttons on the same dialog with the same value ... the WM_CLOSE event was mapping to another function in my code and executing there when i checked the resource.h file i had like 20 IDC_WHATEVERS as the same value ... some on the same dialog ... i am anal about those things and often check them and clear out ones i dont use anymore some kind of alien visitation i call it thanks for the input --- "every year we invent better idiot proof systems and every year they invent better idiots" Bug with RichEdit2 and EM_FORMATRANGE? 26-Mar-01 0:22 26-Mar-01 0:22  I'm trying to use a RichEdit 2 control in an MFC app, deriving from CRichEditView and modifying the class string to "RichEdit20A". All's going well apart from Printing and Previewing. The culprit seems to be the EM_FORMATRANGE message, which is meant to format some text in a rect and return the index of the last character formatted plus one (i.e. in terms of pages, the index of the character for the next page). MFC uses this value to compare with GetTextLength() to determine whether to end the document. However, it seems to be treating CRLF pairs as a single character, so if my document is: A B C i.e. "A<cr><lf>B<cr><lf>C<cr><lf>", then the EM_FORMATRANGE message will return 7 as the index of the next character, whereas GetTextLength() returns 9 as the total number of characters, and hence my document never stops printing. Any thoughts / suggestions would be welcome Darren dumbass question... l a u r e n26-Mar-01 0:02 l a u r e n 26-Mar-01 0:02  i often use this code in dialogs to color the static controls HBRUSH CDlgWhatever::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor) { HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor); if (nCtlColor == CTLCOLOR_STATIC && pWnd->GetDlgCtrlID() == IDC_MYSTATIC){ pDC->SetBkColor(RGB(...)); hbr = CreateSolidBrush(RGB(...)); } return hbr; } and i just realised that i have a memory leak from the brush creation ... like hello wake up there ... but looking at the code i can't figure out where to delete the brush created as it must be returned out of the function intact or it won't exist when it gets to be used now i may be misunderstanding this part of mfc but sheesh ... can someone put a dunce cap on me and explain please? --- "every year we invent better idiot proof systems and every year they invent better idiots" Re: dumbass question... 26-Mar-01 0:30 26-Mar-01 0:30  Why not store an HBRUSH as a member of CDlgWhatever? Create the brush in the dialog constructor and delete in the dialog destructor (or use a CBrush instead). Darren Re: dumbass question... l a u r e n26-Mar-01 1:08 l a u r e n 26-Mar-01 1:08  funny how you never look at old code huh? heh ... sheesh lbrush is a LOGBRUSH is a dlg local var m_brush is a dlg local cbrush HBRUSH CDlgIdiot::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor) { HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor); if (nCtlColor == CTLCOLOR_STATIC && pWnd->GetDlgCtrlID() == IDC_WHATEVER){ pDC->SetBkColor(RGB(...)); lbrush.lbStyle = BS_SOLID; lbrush.lbColor = RGB(...); m_brush.CreateBrushIndirect(&lbrush); hbr = (HBRUSH)m_brush.GetSafeHandle(); } return hbr; } i think this is the right way --- "every year we invent better idiot proof systems and every year they invent better idiots" Re: dumbass question... Christian Graus26-Mar-01 10:05 Christian Graus 26-Mar-01 10:05  I think you're still leaking a brush, because hbr gets set to be a brush, then set to another without deleting the old one. Or does this take care of your return/delete problem ? *scratches head* Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion. Re: dumbass question... Chris Meech26-Mar-01 10:35 Chris Meech 26-Mar-01 10:35  Somewhere in your dialog destruction code, ie. DestroyWindow, or even the destructor itself, I think you still need to be calling m_brush.DeleteObject() in order to free up the GDI resources. Just make sure that you don't do it when it is selected into a DC somewhere That causes wonderful problems. Chris Re: dumbass question... l a u r e n26-Mar-01 11:32 l a u r e n 26-Mar-01 11:32  thanks i think i figured it out but i wonder if its safe to do this: if (m_brush.m_hObject != NULL) m_brush.DeleteObject(); seems to work --- "every year we invent better idiot proof systems and every year they invent better idiots" Acces Violation with oledb CoUninitialize() instruction 25-Mar-01 23:11 25-Mar-01 23:11  Hi, I use Visual C++ 6.0 SP 4 , SQL Server and oledb I create a class to connect to my database. In my constructor i initialize com library like this : CoInitialize(NULL); In my destructor i release com library like this : CoUninitialize(); If i use this class to execute for exemple an sql query ( store procedure), my functions open, execute, close,... work. But if i close my application ( OnOK ) , two seconds later i obtain the following acces violation message : EXCEPTION(c0000005 acces,@40f919) EBP184f0b8 EIP40f919) ASM 45 fc 8b 08 8b 01 52 ff 50 08 8b e5 5d c3 cc cc cc cc cc cc EAX:184f618 EBX:dc0110 ECX:383439 EDX:383439 ESI:dc0064 EDI:184f664 ESP:184f0b4 The suspect function is _Release() throw() which is in a Visual C++ include file ( in Include\COMIP.H ) // Releases only if the interface is not null. // The interface is not set to NULL. void _Release() throw() { if (m_pInterface != NULL) { m_pInterface->Release(); } } But if i comment out CoUninitialize() instruction, my code work without acces violation. Can anybody help me? Best regards, Cheickna Re: Acces Violation with oledb CoUninitialize() instruction 25-Mar-01 23:34 25-Mar-01 23:34  If you are using MFC, MFC will quitely do COInitialize() and CoUninitialize() for you. This may be a source of problems (calling things twice). The docs say you should prefer CoInitializeEx() over CoInitialize(). If you are using the IMallocSpy interface be sure to deregister your spy before destroying it. Don't know if that helps, but I've seen problems with these areas. Stephen Kellett Some problem when hosting WebBrowser control in an application 25-Mar-01 21:17 25-Mar-01 21:17  Hi, I faced some problem when develop a small Internet reliant application, could you help me to solve them ? How to use get/put_onsubmit method of interface IHTMLFormElement when hosting a WebBrowser control in an application ? How to hosting more than one WebBrowser control in an application, which use same session on the server ? Once the session is authenticated by first created control, other controls can enlist in the same session. Thank you. How resize dialog bar when it is in docked mode ? 25-Mar-01 21:15 25-Mar-01 21:15  Thanks How resize dialog bar when it is in docked mode ? 25-Mar-01 21:15 25-Mar-01 21:15  Thanks How to copy the value of _bstr_t into a BSTR variable?? 25-Mar-01 20:56 25-Mar-01 20:56  I have the _bstr_t *alt; BSTR *restxt; HOW COULD I PUT THE VALUE OF _bstr_t in restxt?????? Thanks and BEST REGARDS!!!! Javier.

Last Visit: 31-Dec-99 18:00     Last Update: 26-Sep-24 13:23 Refresh ᐊ Prev1...18415184161841718418184191842018421184221842318424 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.