CPropertyView Problems Compiling
-
I have a project in which I was using a view using a CTabCtrl. I ran into some issues turning tabs on and off and my searching led me to the CPropertyView described here: Property Sheet View[^] I am writing here because the article is old and probably not being maintained. The original was written for VC 6. I have compiled the demo projects just fine under both VC 6 and VC 2005. When I included CPropertyView in my project and attempted to compile, I got three errors which are real head scratchers. In my class derived from CPropertyView, I get the following errors: C2248: 'CPropertyView::GetThisMessageMap' : cannot access protected member declared in class 'CPropertyView' C2352: 'CPropertyView::AssertValid' : illegal call of non-static member function C2352: 'CPropertyView::Dump' : illegal call of non-static member function The C2248 error comes up with the END_MESSAGE_MAP() macro. I tried commenting out everything in the message map and I still got the error. I have carefully checked the syntax and AssertValid and Dump are declared and called identically in this class as in all others. There is a slight variation between VC6 and VC2005 in that VC2005 has an extra #ifdef for Windows CE, but the error happens whether the ifdef is there or not. I found a Microsoft Knowledge Base article (Q243351) that talks about the C2248 error happening when the /Za flag is used in the compiler, but I'm not using that flag. I'm sure the answer is something simple, but I've run into a brick wall. Bill
-
I have a project in which I was using a view using a CTabCtrl. I ran into some issues turning tabs on and off and my searching led me to the CPropertyView described here: Property Sheet View[^] I am writing here because the article is old and probably not being maintained. The original was written for VC 6. I have compiled the demo projects just fine under both VC 6 and VC 2005. When I included CPropertyView in my project and attempted to compile, I got three errors which are real head scratchers. In my class derived from CPropertyView, I get the following errors: C2248: 'CPropertyView::GetThisMessageMap' : cannot access protected member declared in class 'CPropertyView' C2352: 'CPropertyView::AssertValid' : illegal call of non-static member function C2352: 'CPropertyView::Dump' : illegal call of non-static member function The C2248 error comes up with the END_MESSAGE_MAP() macro. I tried commenting out everything in the message map and I still got the error. I have carefully checked the syntax and AssertValid and Dump are declared and called identically in this class as in all others. There is a slight variation between VC6 and VC2005 in that VC2005 has an extra #ifdef for Windows CE, but the error happens whether the ifdef is there or not. I found a Microsoft Knowledge Base article (Q243351) that talks about the C2248 error happening when the /Za flag is used in the compiler, but I'm not using that flag. I'm sure the answer is something simple, but I've run into a brick wall. Bill
Have you put a DECLARE_MESSAGE_MAP in your derived class? [edit]Also - I presume you've inherited publicly from CPropertyView?[/edit]
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Have you put a DECLARE_MESSAGE_MAP in your derived class? [edit]Also - I presume you've inherited publicly from CPropertyView?[/edit]
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
DECLARE_MESSAGE_MAP is there. I was tracking down another compiler error and stumbled across the problem. When I converted the class as derived from CFormView to CPropertyView, I had updated all the references to CFormView except 1. I don't know why the compiler didn't see that as a problem, but when I changed that, it compiled. I'm having some other problems now. It appears that something in the parent class is causing a memory corruption in the derived class. It was blowing up when I tried to call Clear() for a COleVariant class variable. When I looked at it in the debugger, it was set to something strange. In the class declaration, I moved the COleVariant to the end of the fire and it ran Clear() fine. However, it now blows up when calling SetWindowText() for a CEdit variable. Tracing down into the debugger, everything looks fine until m_pCtrlSite->;SetWindowText(lpszString); I try to trace into it, but I get an access violation reading location 0x00000000. The issue is almost certainly caused by something in CPropertyView because the program runs just fine through that point with the old TabView. What tools are available to figure out what's corrupting memory? Bill
-
DECLARE_MESSAGE_MAP is there. I was tracking down another compiler error and stumbled across the problem. When I converted the class as derived from CFormView to CPropertyView, I had updated all the references to CFormView except 1. I don't know why the compiler didn't see that as a problem, but when I changed that, it compiled. I'm having some other problems now. It appears that something in the parent class is causing a memory corruption in the derived class. It was blowing up when I tried to call Clear() for a COleVariant class variable. When I looked at it in the debugger, it was set to something strange. In the class declaration, I moved the COleVariant to the end of the fire and it ran Clear() fine. However, it now blows up when calling SetWindowText() for a CEdit variable. Tracing down into the debugger, everything looks fine until m_pCtrlSite->;SetWindowText(lpszString); I try to trace into it, but I get an access violation reading location 0x00000000. The issue is almost certainly caused by something in CPropertyView because the program runs just fine through that point with the old TabView. What tools are available to figure out what's corrupting memory? Bill
wdolson wrote:
m_pCtrlSite->;SetWindowText(lpszString);
I hope that first semi-colon's just a typo in the message :-) First thing - I presume you're using a Debug rather than Release build for your debugging (strange things can appear to happen when you debug a Release build). If it is a Debug build, try setting a Data Breakpoint on the thing that's changing unexpectedly - that should be triggered when the data changes value.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
wdolson wrote:
m_pCtrlSite->;SetWindowText(lpszString);
I hope that first semi-colon's just a typo in the message :-) First thing - I presume you're using a Debug rather than Release build for your debugging (strange things can appear to happen when you debug a Release build). If it is a Debug build, try setting a Data Breakpoint on the thing that's changing unexpectedly - that should be triggered when the data changes value.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Yes, the semi-colon was a typo. When I copied and pasted the code, it turned the arrow head into > and I didn't delete the semi-colon. It is also being debugged in debug mode. I was putting a breakpoint where it was changing unexpectedly. The underlying code appeared to be getting corrupted. This problem appears to have gone away when I fixed the order with which I created the tabs. I noticed I had two reversed and fixed it. That made the problem go away mysteriously. I'm not sure why having the tabs out of order caused the SetWindowText() function to get corrupted, but I have seen stranger things. I once spent two weeks trying to find a bug in some hardware I designed. The thing just would not work. One morning, it just started working. My lead predicted it would be back and I had to agree with him. The hardware went into production and nobody ever saw that bug again. The debugging gnomes is the only explanation I have. (I'm feeling old, I just realized that was more than 20 years ago...) Thanks anyway, Bill