Re: Using SHGetFileInfo causes Assertion
On Apr 16, 11:53 am, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On Thu, 16 Apr 2009 09:38:31 -0700 (PDT), newgroupsurfer <newsgroupsur...=
@yahoo.com>
wrote:
My program mirrors Windows Explorer with two views one a CTreeView and
the other CListView derieved classes. My program makes use of
SHGetFileInfo twice once in the derieved CTreeView and the other in
the CListView derieved class. I am not sure how to make use of this
function only for both views. If anyone has any ideas please share.
Running the code in Debug mode causes an Assertion window to appear.
But if I choose Continue (with the code execution) from the Debug
window the main application window appears normally without any
further errors and all icons are display correctly in both views. Also
if run the code in Release mode the code works without any errors with
both views displaying correct icons beside each entry/item.
When the code causes an Asssertion it takes place at the below line or
at least that is where the code stops in the Debugger (using VS 2005
Standard). It says my application has triggered a Breakpoint and an
option of to Continue or Break is given. If Break is chosen then this
line below is where the code stops. If you choose Continue the main
window opens and everything is displayed normally.
// within the CListView class
if ( !m_imgList.Attach( hImgList ) )
****
It should have stopped in the line that caused the error. There are a =
couple likely
causes, such as the m_imgList already has an image list attached (doing i=
t twice is an
error!). Reading the code of CImageList::Attach is informative:
Yes Joseph your absolutely correct on your assumption that the system
image list is already attached ! As far as trying to further step into
the code... I cannot or at least its not allowing me to. I gives the
following information when I try stepping into the line that I have
already mentioned... "There is no source code available for the
current location". Also it tries to find some file called winctrl2.cpp
not sure what about.
BOOL CImageList::Attach(HIMAGELIST hImageList)
{
ASSERT(m_hImageList == NULL); // only atta=
ch once, detach on destroy
ASSERT(FromHandlePermanent(hImageList) == NULL);
if (hImageList == NULL)
return FALSE;
CHandleMap* pMap = afxMapHIMAGELIST(TRUE);
ASSERT(pMap != NULL);
pMap->SetPermanent(m_hImageList = hImageList, this);
return TRUE;
}
The first ASSERT says the current m_imgList already has an hImgList attac=
hed.
The seconed ASSERT says the current m_imgList is *not* already assigned t=
o some other
CImageList object
The third ASSERT says that the creation of the mapping worked.
So single-step into the Attach code and see which one is actually failing=
!
****
Any ideas as to why the assertion takes place ? Should I worry about
it since it appears only in Debug mode and ignoring the Assertion and
continuing with the execution the windows still displays correctly ?
Is there a shortcoming with my code ? Any suggestions would be greatly
appreciated.
****
No, you may not ignore it. It is saying "your program is wrong". Yo=
u have to fix your
program. The Ostrich approach to bug fixes is not considered Best Prac=
tice, and you will
never find it described as a valid approach in Code Complete.
Your code is wrong, and it is up to you to figure out what you did wrong.
****
BOOL CMyListView::GetSysImgList()
{
SHFILEINFO shFinfo;
HIMAGELIST hImgList = NULL;
CListCtrl& m_listCtrl = GetListCtrl( );
****
I'm curious. Why is it that you are calling a LOCAL variable with a na=
me "m_" that says
"I AM A CLASS MEMBER"? Could it be you are totally clueless about prop=
er naming
conventions? If you don't understand the conventions DO NOT USE THEM. =
Using them
incorrectly is far worse than not using them.
joe
****
Your right its not a member variable and I really should not be using
the "m_" I guess if you can give me a link on naming conventions that
can allow me to brush up on that sort of thing it would be
appreciated. Thanks for your comments.