CListCtrl disappears after minimising

[bordonbert]

Let me say at outset that I'm using old technology by today's standards! This happens in MFC on Visual Studio 2005 and running under WinXP. (If it 'aint broke.... ;-) )

I have a dialog based app which has a CTabCtrl with two tabs. Each contains a CListCtrl. These work perfectly under normal circumstances. They populate correctly and show and hide as they should. When I first open the application the display selection is correct. If I then minimize the dialog and restore, the CList Ctrl does not show, the tab is blank. It is the only control which has this problem. Another CListCtrl outside of the CTabCtrl does show up correctly. If I then swap tabs and back again, the other tab shows up then the first appears as normal.

This does not happen if I access any other part of the dialog before minimising, it is only when minimising is the absolute first action I take. It also happens with the CListCtrl I have in the other tab if I set this tab to be selected on startup in OnInitDialog where I set up the CTabCtrl.

I have actually solved the effect of this problem by adding into my OnSysCommand(...) the following:

if ((nID & 0xFFF0) == SC_RESTORE)
{
m_ctrlReadList.Invalidate();
}

but it bugs me that I'm adding code to solve a problem which only happens in such odd circumstances. I can't help thinking that there is something I have missed in the setup which is leading to this behaviour. Can anyone offer any explanation as to what is causing it in the first place?

[Thomas1965]

Can you upload the project somewhere ?
Maybe this problem exist only with your MFC or Windows version
I would like to check if this problem exist also in VS 2013 and Win 7.

[bordonbert]

Thanks for the response Thomas. I've zipped the entire project up and dropped it on Dropbox here: https://www.dropbox.com/s/w0a2psqyojjaqed/GM36_File_Converter_Project.zip?dl=0 It's a tad over 24MB

[bordonbert]

I should have pointed out that that is supplied with the correcting code included and active.

It's in the GM35_File_Format_ConverterDlg.cpp file in OnSysCommand(...), last four lines. You'll need to comment that out before compiling of course. (Granny - eggs - suck - sorry ;) )

[Thomas1965]

It has some strage behaviour. When I compiled it with VS 2013 and ran it on Win 7 I first couldn't minimize it.
Removing SetWindowLong(m_hWnd, GWL_STYLE, GetWindowLong(m_hWnd, GWL_STYLE) | WS_MINIMIZEBOX); and setting the minimize box in the property inspector fixed it.

When I changed the Tabstop property of IDC_MAIN_TAB to true the ReadListView was visible after minimize and restore.

Please don't ask me why. It was just trial and error.

[bordonbert]

Great catch Thomas! I've done the same here and it seems to have worked, at least for the first dozen times I've checked. I can't even suggest why. What was strangest was that I couldn't get it to show that behaviour once any control in the dialog had been accessed.

It's a bit worrying that it shows different behaviour under Win7. There has to be something about that SetWindowLong which just doesn't apply now, my old version of VS2005 is plain too long in the tooth. But as I don't do this for a living it's hard to justify the cost of a new version just for hobby use. This may not be my area but it fits in with other stuff I like.

Anyway, thanks very much for your help, it's greatly appreciated. Even if we don't fully understand why there is hope that this has taken me forward with that little app. And I thought it would be so simple!

[bordonbert]

I'm sorry I left it this long to answer your responses but I have been doing a lot of diagnostic work to get to the bottom of this. My explanation is based on the facts of what I have found but this has been a learning experience for me so apologies if I get some of it a little confused, I'm still letting it settle in my mind.

Along with this problem I found another which turned out to be relevant. From the nature of the program I'm writing, my CListCtrls needed fixed width headers. Now that turned out to be another thing I couldn't set up! I just needed to prevent the user from grabbing and resizing the header's dividers or double clicking them to autosize, and of course there is functionality in the CListCtrl based on its child CHeaderCtrl to set this up isn't there? Well apparently not. LVS_EX_HEADERDRAGDROP for example isn't the way.

So I explored trying to capture messages which would allow me to myself, and what do you know, I couldn't! I could trap a few but not the ones I needed. I was looking for HDN_BEGINTRACK and HDN_DIVIDERDBLCLICK. (We won't go into the fact that you HAVE TO deal with both A and W versions of those separately!) The CHeaderCtrl is a child of the CListCtrl but it sends its messages back to the CDialog as the CListCtrl's parent. I tried there using both my list's and 0 as ID which headers apparently use. Many of them just plain didn't appear there at all.

So I created my own CListCtrl class inheriting from CListCtrl, overrode OnNotify and they turned up there. I simply prevented CListCtrl::On Notify from being called for those messages and it worked, no resize functionality at all.

I also played with the Z-order too which could have been relevant to the original problem. I didn't explain earlier but this and another list are on two tabs, exactly aligned over each other. Selecting a tab simply HIDEs and SHOWs each of the lists in turn. The other list had no display problems even when I changed the default display in OnInitDialog to show it at start up. It was under the problematic one. So changing the Z-order in OnInitDialog where I set them up - did nothing! And to rub it in that second list was also unresizeable by default just as I wanted and I couldn't find out why. Their Properties listed exactly the same and there was nowhere in the code where any different aspect was set manually for either, they were effectively theoretically identical, but practically not so. So frustrating!!!

And the upshot of it is that now that the header resize issue is solved my display problem has vanished too! It looks to me and to a few others out there too who report similar symptoms as myself as though the CListCtrl is another one of the slightly flaky ones and needs a little massaging to get the best out of it.

I hope that makes sense to those of you out there who know this control well. I was surprised how simple the solution was, but it also surprised me that the diagnostic process was so difficult. It may of course come down to the ageing system I work within. Nowadays I do this only for fun and the expense of updating VS from 2005 for occasional use is not a high priority. I am sure that some of the symptoms will not show under other build and run environments but it may be worth having the issue and my solution on record somewhere for Google to find for others.

Thanks for the help and if anyone can shed any more light on this I would be grateful.

[Thomas1965]

Glad to hear that it works now. Another way to fix the headers is to call in InitDialog()

  
CHeaderCtrl *pHeader = (CHeaderCtrl *) m_ctrlReadList.GetHeaderCtrl ();
if (pHeader != 0)
   pHeader->EnableWindow (FALSE);

On Codeproject.com there are some articles about the CListCtrl:
http://www.codeproject.com/search.aspx?q=CListCtrl&x=0&y=0&sbo=kw