Violation destroying a CListCtrl whe
Stephan
Wednesday, February 07, 1996
Hello, MFC World:
I am the original poster of the query. I will be responding to Mike and
Colin's responses, as well as adding more information on my problem at the
end.
To summarise, I am getting an access violation within COMCTL32.DLL (not
within my code) when I had a CTabCtrl as a child of a CListCtrl. The access
violation would occur shortly after attempting to close the view containing
these two objects. I am using MSVC 4.0 + service patch 1, MFC 4.0 and
Windows NT 3.51.
Mike:
-----
> Why is the CListCtrl a child of the CTabCtrl? This seems wierd. I think
it
> should be a child of the CView, too. I don't think CTabCtrls, like me,
> expect to have children.
Ah, design philosophy! A man after my own heart.
In my real application a CTabCtrl-derivative manages different tab pages of
controls, all of which appear within the CTabCtrl window. This is
essentially the same behaviour as a property sheet, but without using dialog
resources and Okay/Cancel/Apply buttons. To do this I create all my
necessary controls for all the pages once, and then show/hide controls
depending on which tab the user has currently selected. (Of course,
different "pages" -- they're really collections of controls -- are
encapsulated in a C++ class, so the code is actually quite readable.)
The most natural window hiearchy in my mind was to make these tab page
controls children of the CTabCtrl. After all, they always physically appear
inside the client rectangle of the CTabCtrl, and they need to be repainted
when their parent tab control does, etc. If I make these controls children
of the view (ie, siblings of the CTabCtrl), then I would be continously
adjusting for their positions relative to the position of the CTabCtrl
during paints, resizes, etc., and that seemed rather inelegant. If there's
a better solution I'd be happy to hear it.
Anyway, everything worked like a charm with many different controls
(CListBoxs, CButtons, *CTreeCtrls*, even generic CWnds, etc.) until I tried
a CListCtrl and got that access violation. Reducing the problem in my
minimal application shows that it only occurs because a CListCtrl is a child
of a CTabCtrl.
Finally, I discovered yesterday that the same executable which causes the
access violation under NT 3.51 worked perfectly when I ran it under Windows
95. (Please see below).
Thanks for your reply!
> ..B ekiM
> --
> TCHAR szScratched[] = _T("Someone tried to tow my motorcycle. _Once_.");
Colin:
------
> My guess would be that it is a NULL pointer. Look at your call stack and =
> retrace the code backwards from here. Check the pointers that are =
> created, passed into functions etc (you are using VC++ 4.0 so you should =
> have the luxury of data tips) - everyone else including myself would =
> have to resign themselves to the Watch window.=20
[ more tips deleted ]
Thanks for your tips, Colin. NULL pointers are always a problem and they
have certainly bitten me in the past.
However, I do not believe this is a case of a NULL pointer. My minimal
application contains no pointer variables at all, and the access violation
is occuring inside a system DLL. In fact, the call stack shows no calls
within my source at all! All the entries on the stack are either within
COMCTL32, USER32 or the AfxWndProc routines.
> Colin Angus Mackay -- gs94@dial.pipex.com
More information:
-----------------
I tried running the same *executable* for my minimal application under three
different computers with Windows 95 (as opposed to NT) and it works
perfectly -- no access violation in COMCTL32.DLL. Similarly, I was able to
reproduce the access violation on two separate computers running NT 3.51.
The code to duplicate the behaviour is only a few simple lines using stock
MFC classes, so I am now inclined to believe that this is a genuine NT OS
bug. I will noodle over the problem for a few more days (and see if anyone
else on this list comes up with a keen idea) and, if the problem persists, I
will submit a bug report to Microsoft using the appropriate formal channels.
Thanks for reading,
Stephan
stephan@synapse.net, Stephan.Jou@Cognos.COM
Mike Blaszczak -- mikeblas@interserv.com
Thursday, February 08, 1996
[Mini-digest: 2 responses]
On Wed, 07 Feb 1996, Stephan.Jou@Cognos.COM (Jou, Stephan) wrote:
>In my real application a CTabCtrl-derivative manages different tab pages of
>controls, all of which appear within the CTabCtrl window. This is
>essentially the same behaviour as a property sheet, but without using dialog
>resources and Okay/Cancel/Apply buttons.
No, it isn't. If you use Spy++, you can readily find out that that a
property sheet is a dialog that owns a tab control. The tab control doesn't
have any children. The dialogs that act as property pages are directly
children of the property sheet.
>The most natural window hiearchy in my mind was to make these tab page
>controls children of the CTabCtrl. After all, they always physically appear
>inside the client rectangle of the CTabCtrl, and they need to be repainted
>when their parent tab control does, etc.
They don't unless they overlap. The tab control paints its tabs and nothing
else in its rect. The tabs don't usually overlap the controls or dialogs
"within" the tab.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
-----From: Mario Contestabile
[Cut-Start()]
Reducing the problem in my
minimal application shows that it only occurs because a CListCtrl is a child
of a CTabCtrl.
[Cut->Stop()]
They are both CWnds. Make sure each and every structure being used in and around
the control is memset() to zero. Retry the release and debug versions under the
two environments.
Are there still inconsistencies? If so, send some code snippet along.
mcontest@universal.com
| Вернуться в корень Архива
|