Hi Pelle,
when I use the 'ListView_GetSubItemRect' macro, POCC displays the following warning message:
warning #2130: Result of comparison is constant.
To reproduce the issue, please use the test files attached to this message.
The project was downloaded from the following link:
https://www.smorgasbordet.com/pellesc/zip/vlistvw.zip
I only added the following 4 instructions to the 'VListVw.c' file (everything else has been left untouched):
#pragma comment(lib, "user32.lib") // <-- Added
#pragma comment(lib, "comctl32.lib") // <-- Added
...
BOOL InitListView(HWND hwndListView)
{
...
RECT rc; // <-- Added
ListView_GetSubItemRect(hwndListView, 0, 1, LVIR_LABEL, &rc); // <-- Added - generate the warning message
}
Simply double-click the 'build.bat' file to compile the application. The batch file assumes that PellesC is installed in the default folder ('C:\Program Files\PellesC'). If not, please edit the batch file and change the value assigned to the 'PCPATH' environment variable, for example:
set PCPATH=c:\PellesC
When building, the compiler should give some other warnings that can be ignored for the sake of this example.
Marco
This is a known problem with no (good) solution.
The warning comes from how the macro is written by Microsoft:
#define ListView_GetSubItemRect(hwnd, iItem, iSubItem, code, prc) \
(BOOL)SNDMSG((hwnd), LVM_GETSUBITEMRECT, (WPARAM)(int)(iItem), \
((prc) ? ((((LPRECT)(prc))->top = (iSubItem)), (((LPRECT)(prc))->left = (code)), (LPARAM)(prc)) : (LPARAM)(LPRECT)NULL))
The condition ((prc) ? ... : ..) is in your case ((&rc) ? ... : ...) /* i.e. ((&rc != NULL) ? ... : ...) */ which will always be true.
There is no way to suppress a warning from a statement in a macro. To permanently disable this warning when including <windows.h> or <commctrl.h> seems unhelpful.
This could be worked around by replacing the macro with an inline function, where the warning can be suppressed, but I prefer to keep the Windows SDK as original as possible.
Quote from: Pelle on April 22, 2025, 03:59:49 PMThis could be worked around by replacing the macro with an inline function
Yes, this is the same solution I used.
Quote from: Pelle on April 22, 2025, 03:59:49 PMI prefer to keep the Windows SDK as original as possible.
I agree, it is the most sensible choice.
Thanks Pelle.
Marco