C / C++ / MFC

Error deleting first column in CListCtrl

31-Aug-17 13:14

I have learned C programming with Turbo C in the late 1980's and can't remember that it supported references.

Turbo C was discontinued as stand alone product in 1990 and the C compiler was included with Turbo C++ 1.0. So you probably used that.

Member 86892625-Aug-17 10:09

Member 868926

25-Aug-17 10:09

Hi,
I am generating a CListCtrl in Report view (MFC). It loads fine and I can reorder columns by dragging the headers. I've made it so clicking a column header deletes the column - again this works fine except for the first (leftmost) column. Here the header is deleted but the data underneath doesn't change - in fact the data from the last column is deleted:

Before:

Header1    Header2     Header3

 Data1      Data2       Data3

After trying to delete first column:

Header2     Header3

 Data1       Data2

Having created the columns to begin with, I'm setting up the rest of the table like this:

void MyClass::InsertItem(int x, int y, CString &str)
{

    LVITEM lvi;
    lvi.mask = LVIF_TEXT;
    lvi.iItem = y;
    lvi.iSubItem = x;
    lvi.pszText = (LPTSTR)(LPCTSTR)(str);
    int result;
    if(x == 0)    {
        result = mCSVListCtrl.InsertItem(&lvi); 
    }
    else {
        result = mCSVListCtrl.SetItem(&lvi); 
    }
}

which seems to create the table OK. Then when a header is clicked:

void MyClass::OnLvnColumnclickList(NMHDR *pNMHDR, LRESULT *pResult)
{
    LPNMLISTVIEW pNMLV = reinterpret_cast<LPNMLISTVIEW>(pNMHDR);

    mCSVListCtrl.DeleteColumn(pNMLV->iSubItem);// This IS getting zero

    *pResult = 0;
}

Any ideas?

Rick York25-Aug-17 12:35

Rick York

25-Aug-17 12:35

Either look using the debugger or put in a trace statement but make sure the sub item value is what you expect it to be.

That's the only idea I have because I know that calling DeleteColumn(0) works because I do it often. One of the weird things with the list control is you can't set the first column to be right-justified so the work-around is to add one more column than needed, set column 1 to be right-justified, and then delete column 0. BTW - this was true with older versions and I don't know if it is still necessary. I do it anyway because it still works.

Member 86892626-Aug-17 11:00

Member 868926

26-Aug-17 11:00

Thanks for the various replies. The debugger doesn't go beyond DeleteColumn() but I can see it's passing zero. Can you see anything odd about the way I'm creating my sub items that could be causing the problem? I've created the columns first then for each item (row) I'm adding subitems left to right. Otherwise I'll have to go for the dummy first column option.

David Crow25-Aug-17 16:41

David Crow

25-Aug-17 16:41

What happens if you create a "dummy" column 0 with a width of 0 (or maybe 1)?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

Jochen Arndt25-Aug-17 22:31

25-Aug-17 22:31

Not a solution to the problem but a tip.

Instead of deleting columns you might set the width to zero. Then you can implement a hide/show column handler (which requires storing the actual or a default width for each column when hiding to be restored when showing it again).

Note also that it might be necessary to get the effective column index when the columns has been reordered (GetColumnOrderArray).

Victor Nijegorodov27-Aug-17 7:51

Victor Nijegorodov

27-Aug-17 7:51

Member 868926 wrote:

when a header is clicked:

void MyClass::OnLvnColumnclickList(NMHDR *pNMHDR, LRESULT *pResult)
{
    LPNMLISTVIEW pNMLV = reinterpret_cast<LPNMLISTVIEW>(pNMHDR);
 
    mCSVListCtrl.DeleteColumn(pNMLV->iSubItem);// This IS getting zero
 
    *pResult = 0;
}

Any ideas?

Just for a test: what will happen if you call

mCSVListCtrl.DeleteColumn(0);

from anywhere but from this MyClass::OnLvnColumnclickList(...) message handler?

Member 8689264-Sep-17 0:01

Member 868926

4-Sep-17 0:01

Victor Nijegorodov wrote:
Just for a test: what will happen if you call
mCSVListCtrl.DeleteColumn(0);
from anywhere but from this MyClass::OnLvnColumnclickList(...) message handler?

It's the same. I think I'll have to go for the dummy left column idea some of you have suggested - maybe I'll use it to number the rows which might be quite nice anyway.
Thanks again for all your replies.

Debug Assertion in Release wrong version of MFC Shared DLL

Victor Nijegorodov27-Aug-17 7:55

Victor Nijegorodov

27-Aug-17 7:55

Member 868926 wrote:
Any ideas?

Additional info: LVM_DELETECOLUMN message

ForNow24-Aug-17 13:44

Re: Debug Assertion in Release wrong version of MFC Shared DLL

24-Aug-17 13:44

HI,

I have code that works fine in debug but I have already learned my lesson that it does mean It will work in Release

Anyway I got an assertion in wincore.cpp line 656 for having a window handle = NULL

After the message box came up pointing me to the location in wincore.cpp where the problem was I tried to attach the VS debugger with my solution.

Wasn't much help as the call stack was all windows code

One thing I did notice that was odd the DLL was MFC140d.DLL isn't that the debug version of MFC

I checked my property pages for release and I had /MD not /MDd shouldn't I have MFC140.DLL ??

leon de boer24-Aug-17 19:15

leon de boer

24-Aug-17 19:15

Turn your warning level up .. it will give you uninitialized use warnings. The default is W3 go to W4 or WALL you might get a lot of warnings but saves you headaches Smile | :)

I usually start out W3 when it's getting close to release I crank the setting up and walk thru each warning.
What you are really saying is you have a bad habit of either using uninitialized variables or forgetting to initialize them which will be what your current problem is about. You need to work on getting rid of what is obviously a bad coding habbit.

/MD is the correct selection for the VC runtime library release but usually I go for /MT in release the exe gets bigger but no VC runtime install required on the target machine. Now I assume it follows thru to MFC I write so little on the MFC framework I can't say definitively. But yes usually in release /MD or /MT is the setting you would use the difference as stated, and if the blowup in size is worth not having to distribute the run-time library at all.

Now when VS debugs in release mode it's a quirky thing, as you stated you wanted no debug compilation but the VS IDE still tries to give you debug info. It seems to sort of guess at the line sometimes you will find it out by a line or 2 especially if it has optimized some of the code away. When running outside the IDE I know it only uses the correct DLL because the times I have used DLL distribution I only copy the one DLL for install.

In vino veritas

Re: Debug Assertion in Release wrong version of MFC Shared DLL

ForNow24-Aug-17 20:32

Re: Debug Assertion in Release wrong version of MFC Shared DLL

24-Aug-17 20:32

Thanks

I just realized I did a number of SetDlgItemText for labels in my Dialog but I never Created a window

Maybe I'll just have the appropriate CStatic's and use DDX_Control to initialize the windows handle

or better yet just use DDX_Text and put the data in a CString

Thanks

Jochen Arndt24-Aug-17 21:13

Re: Debug Assertion in Release wrong version of MFC Shared DLL

24-Aug-17 21:13

For some reason your release build is linked with the debug version of the MFC. You should find out why and fix that. A possible reason is linking with another DLL that depends on the MFC DLL and is a debug version itself.

With proper code, a debug build should also assert at that point (window handle NULL). However, it would not assert if the handle is not NULL but invalid (uninitialised variable). But then you usually get other runtime errors.

ForNow25-Aug-17 2:26

Re: Debug Assertion in Release wrong version of MFC Shared DLL

25-Aug-17 2:26

My only guess at this point that after doing various "new" to allocate heap storage to format labels for the dialog

I do AfxCheckMemory rather then assert to see if I some how over stepped my storage allocation

Thanks

Jochen Arndt25-Aug-17 2:41

Re: Debug Assertion in Release wrong version of MFC Shared DLL

25-Aug-17 2:41

AfxCheckMemory[^]
This function works only in the Debug version of MFC.

Therefore, it is common to call that within an ASSERT().

Note also that you should check if the affected handle is on the heap. It does not help when it is on the stack.

ForNow25-Aug-17 2:54

Re: Debug Assertion in Release wrong version of MFC Shared DLL

25-Aug-17 2:54

I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd

Just surprising that it worked at all under debug but then again I am beginning to understand the "debug" version covers up for a lot of mistakes

On more thing should assert only be used in "debug"

Thanks

Jochen Arndt25-Aug-17 3:08

Creating Custom Controls in MFC

25-Aug-17 3:08

Quote:
I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd

That is very likely.

ForNow wrote:
On more thing should assert only be used in "debug"

Just read the documentation:

assert Macro, _assert, _wassert[^]
The assert macro is enabled in both the release and debug versions of the C run-time libraries when NDEBUG is not defined. When NDEBUG is defined, the macro is available but does not evaluate its argument and has no effect. When it is enabled, the assert macro calls _wassert for its implementation. Other assertion macros, _ASSERT, _ASSERTE and _ASSERT_EXPR, are also available, but they only evaluate the expressions passed to them when the _DEBUG macro has been defined and when they are in code linked with the debug version of the C run-time libraries.

My tip: Use them often (e.g. on top of functions for parameter checking and with function return values when there is no error handling). They are simply ignored in release builds but can save you a lot of debugging time.

Bram van Kampen23-Aug-17 14:01

Bram van Kampen

23-Aug-17 14:01

Hi,

How do I create a totally new MFC Control type? I take it that I have to create and register a new Window Class, with it's own Message Procedure, and thereafter write my own MFC/CPP around it as a Husk. Is there any way of deriving my own custom controls from CWnd directly and using the message map Macro's? As a new type of control it will need a resource to display it on screen, etc. How do I tie all this together.

Regards,

Smile | :)

Bram van Kampen

Re: Creating Custom Controls in MFC

Rick York23-Aug-17 15:53

Rick York

23-Aug-17 15:53

Start by reading a few of the many articles at this site on custom controls. You can't expect someone to explain all of that in a few forum posts.

Re: Creating Custom Controls in MFC

Richard MacCutchan23-Aug-17 21:11

Richard MacCutchan

23-Aug-17 21:11

It depends what you want your class to do. Take a look at the Hierarchy Chart | Microsoft Docs[^] and see if there is an existing control that you can derive from (even if it is CWnd), since the base class will provide lots of functionality.

Re: Creating Custom Controls in MFC

Jochen Arndt23-Aug-17 21:47

MFC - painting on a secondary modeless dialog with OnPaint()

23-Aug-17 21:47

Because all MFC controls are CWnd based you should use that as base class too. Then add the painting (OnPaint, OnEraseBackground), register the window class and add control specific message handlers as necessary.

An old but good article by Chris: Creating Custom Controls[^]

Bonobo818-Aug-17 3:52

Bonobo8

18-Aug-17 3:52

Hello everybody,

I'm new to MFC and after passing several hours trying to solve a problem (that might seem simple to most of you), I decided to post my question here in order to get your help and hints.

I'm developing an MFC (C++) application using Visual Studio 2017. The application contains a main CDialog to communicate with a 2D Laser sensor using TCP/IP and to plot the points detected by the sensor on screen in real time (this is done on an IDC_PICTURE element with OnPaint() as the following:

// I create the pDC, memDC and the compatible device/bitmap
CDC* pDC = m_Picture.GetDC();  // m_picture is a member CStatic element in the main CDialog class 
CDC memDC;
CBitmap bmp;
memDC.CreateCompatibleDC(pDC);
bmp.CreateCompatibleBitmap(pDC, PicW, PicH); //  PicW, PicH are the width and height of the associated CRect member object in the class  

// After that, I get the points to plot in order to write them to my memDC

//then, I copy the memDC to the device and delete the memDC, release the pDC 
pDC->StretchBlt(0, 0, PicW, PicH, &memDC, 0, 0, PicW, PicH, SRCCOPY);
bmp.DeleteObject();
memDC.DeleteDC();
ReleaseDC(pDC);

This previously mentioned code is working very well without problems with the main dialog.

Long story short, my problem is the following:

On that same dialog, I created a button that opens a secondary modeless dialog that contains another IDC_PICTURE element. The main goal of the secondary dialog is to plot a delayed version (t-n) of the points seen by the Laser sensor. My main problem is that I am not being able to show anything on the secondary IDC_PICTURE. Is it wrong to do the same thing applied on the main dialog (on another IDC_PICTURE, with anothe pDC and memDC)?

The secondary dialog is defined in a separate class of which I have created an instance in the (first) main CDialog class.

I have been looking everywhere on solutions that could look similar to my problem, but I haven't found anything. What exactly am I missing?

PS. sorry if my problem description isn't clear enough. My code is getting too big to be copied/pasted.. I'd be very happy if you have any hints / questions that might make me find the solution..

Thanks in advance for your help!

Re: MFC - painting on a secondary modeless dialog with OnPaint()

Jochen Arndt18-Aug-17 4:13