In some app like WinSpy/Spy++ to make adjustments to list controls. It can correctly set an app’s list control’s modes, alignments,
sorting, styles, and extended styles. It can also get the widths of the columns and count of items.

The problem is that you cannot seem to get the columns’ names or the item text. The app uses code like this, where lc is a pointer to the target app’s list control:

  lc->GetColumnWidth();
  lc->GetItemCount();
  lc->ModifyStyle();
  lc->SetExtendedStyle();
  lc->GetHeaderCtrl()->GetItemCount();

That all works fine, but when you try something like this, it doesn’t work:

  TCHAR colname[256]=_T("");
  LVCOLUMN lvcol;
  ZeroMemory(&lvcol, sizeof(lvcol));
  lvcol.mask=LVCF_TEXT;
  lvcol.cchTextMax=sizeof(colname)-1;
  lvcol.pszText=colname;
  lc->GetColumn(col, &lvcol);

GetColumn may return TRUE or FALSE, but the LVCOLUMN structure remains unchanged. If you tried using that same code in a test app to get the name of a column from that app’s own list control and it worked. It only seems to fail when use it from a different app.

Solution:

Well, there is no surprise here; in fact, if there is any surprise, it is that you did not manage to totally crash the target app (I presume that lc is a CListCtrl::FromHandle of an HWND in another process).

Think about this case:

you are passing the address of a data structure in YOUR process as a LPARAM-sized value to some totally different process, where that LPARAM value is completely and utterly meaningless.

David Ching did a remote-sendmessage DLL some time ago.  This essentially does DLL injection of the code so it is running in the target process; you can google for this by looking for SendMessageRemote.

http://www.dcsoft.com/private/sendmessageremote.cpp

The simple implemetion is to handle the EN_UPDATE notification message. The EN_UPDATE message is useful to handle as it caters for both normal entry and clipboard paste. You can do that in the Dialog or subclass the CEdit class.

Here is an example of a derived CEdit class.

class CNumEdit : public CEdit
{
//….
afx_msg void OnUpdate();
//}}AFX_MSG

DECLARE_MESSAGE_MAP()
private:
CString m_strLastGood;
};

In the cpp file:

BEGIN_MESSAGE_MAP(CNumEdit, CEdit)
//{{AFX_MSG_MAP(CNumEdit)
ON_CONTROL_REFLECT(EN_UPDATE, OnUpdate)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CNumEdit::OnUpdate()
{
CString str;
GetWindowText( str );
bool bProblem = false;
for ( int indx = 0; indx < str.GetLength(); indx++ )
{
if (( str[indx] < ‘0′ ) || ( str[indx] > ‘9′) )
{
bProblem = true;
break;
}
}
if ( bProblem )
{
int start, end;
/* Find the current caret position */
GetSel( start, end );
/* Restore the last good text that was entered */
SetWindowText( m_strLastGood );
/* Restore the caret */
SetSel( start-1, end-1, true );
/* Let the user know */
MessageBeep( MB_OK );
}
else
{
/* Store the last good entry string in a member variable of the Hex edit class*/
m_strLastGood = str;
}
}

At last, you may find one of these meets your needs:

• http://www.codeproject.com/editctrl/maskededit.asp
• http://www.codeproject.com/editctrl/validatingedit.asp

There are some standard method to translate among Cstring ,string and char[].

// Suppose
CString str;
std::string s;
char buf[SIZE];

// from CString to std::string
s = str;

// from std::string to CString
str = s.c_str();

// to char[]
_tcscpy(buf, str);
_tcscpy(buf, s.c_str());

// from char[]
str = buf;
s = buf;

Also, beware of unicode. If UNICODE is defined, you should convert between unicode and ansi versions. Better to use TCHAR instead of char and std::basic_string instead of std::string.

CWnd::IsIconic

BOOL IsIconic( ) const;

Return Value

Nonzero if CWnd is minimized; otherwise 0.

Remarks

Specifies whether CWnd is minimized (iconic).

Example

// This code, normally emitted by the AppWizard for a dialog-based
// project for the dialog’s WM_PAINT handler, runs only if the
// window is iconic. The window erase the icon’s area, then
// paints the icon referenced by m_hIcon.

if (IsIconic())
{
CPaintDC dc(this); // device context for painting

IconEraseBkgnd(dc);

// Center icon in client rectangle
int cxIcon = GetSystemMetrics(SM_CXICON);
int cyIcon = GetSystemMetrics(SM_CYICON);
CRect rect;
GetClientRect(&rect);
int x = (rect.Width() – cxIcon + 1) / 2;
int y = (rect.Height() – cyIcon + 1) / 2;

// Draw the icon
dc.DrawIcon(x, y, m_hIcon);
}

In the C time, we used to use sscanf to read data from string as following:

char strUserName[20], strPassword[20];
// if the content of m_recvBuff is “Microsoft Bill”.
sscanf((const char *)m_recvBuff, “%s %s”, strUserName, strPassword);

And when you first get CString in sight, you may write the similar code:

CString strUserName, strPassword;
// if the content of m_recvBuff is “Microsoft Bill”.
sscanf((const char *)m_recvBuff, “%s %s” , strUserName, strPassword);

Unfortunately, it can not work as you expected and, in most cases, the process will crash.

Solution:

First, you should not be using sccanf, since this is not Unicode-aware. You should use _stscanf which allows for Unicode.  In addition, it is not a “safe” methodology because it can generate buffer overruns.

Second, the problem here is that you are doing something profoundly illegal: you are passing a CString pointer to a call that expects an LPTSTR.  You can’t do this.  It won’t work, and it surprised me that it merely produces an erroneous result instead of crashing with an access fault, heap corruption assert, or some similar fatal situation.

After all, you can use scanf safely, but you should try to use the new _s versions to make them more “trustworthy”.  Here’s some info on it:

http://msdn2.microsoft.com/en-us/library/w40768et(VS.80).aspx

The problem you’re having is that you are not actually passing the buffers
of the CStrings to the scanf function. Take a look at the GetBuffer()
function in CString.  Also, this function might be useful to you:

http://msdn2.microsoft.com/en-us/library/k4ftfkd2(VS.80).aspx

In additional, You can cast a CString to type LPCTSTR to get read-only access to the contents of the string.  However,
(1)  You can’t cast a CString to type LPTSTR to get writeable access.  You have to do something like call GetBufferSetLength and make sure you set the buffer large enough.
(2)  In variable parameters to sscanf, you can’t expect any casting to be done automatically, you have to code the casts.

But if you take enouth care of your code, sscanf may be not necessarily dangerous. You should check the length of the string and make sure you’ve allocated large enough sizes for your other variables then you won’t have buffer overruns.

At last, in MFC, the following code may be the general solution:

CString strUserName;
CString strPassword;
m_recBuff.Trim(); // remove leading and trailing space
int n = m_recvBuff.Find(_T(” “));
if(n>0) /* has space */
{
strUserName = m_recvBuff.Left(n);
strPassword = m_recvBuff.Mid(n + 1);
strPassword.Trim();
}

Unlike sscanf, which should no longer be considered a viable mechanism for any purpose dealing with string outputs, this actually works and is safe.  It will not cause a buffer overrun.  You should make it a practice to avoid mechanisms that can cause buffer overrun.

The next paragraph is writen by Joseph M. Newcomer, as reference.

There is no economy in using obsolete and unsafe mechanisms.  sscanf is overused and I consider it one of the design errors of the C language.  I have never yet found a situation in which I would trust it to do the right thing in the presence of bad input, and the best I can say for it is that it is only suitable for use in the most naively trusting situations possible.  I never use it, and I have never used it since I first learned of it.  I had, as a beginner, used and trusted such mechanisms in languages I learned in the 1960s, and I quickly learned that such mechanisms are simply not to be trusted.  I doubt if I have used such a mechanism since about 1967 or so.  It was a bad idea then and it remains a bad idea today.  The passage of 40 years does not make a bad idea good.

There are two main steps:

• Load the bitmap from the file to a memory DC.
• Paint the content of the memory DC to the one which display the bitmap.

In MFC, there is no API to load a bitmap directly from a file, but you can use a Win32 API: LoadImage.
Here is the delaration of LoadImage.

HANDLE LoadImage(
HINSTANCE hinst, //handle to instance, if load from file, it should be NULL
LPCTSTR lpszName, //image resource name or the image file path
UINT uType, //image type
//1. IMAGE_BITMAP
//2. IMAGE_CURSOR
//3. IMAGE_ICON
int cxDesired, //desired width
int cyDesired, //desired height
UINT fuLoad //load options
);

After this,  the following steps are similar with loading a bitmap from resource. Here is a short example.

CClientDC dc(this);
CDC *mdc=new CDC;
mdc->CreateCompatibleDC(&dc);

CBitmap bitmap;
//CBitmap is devived from CGdiObject
//It has a handle:m_hObject, which can obtained with LoadImage
bitmap.m_hObject=(HBITMAP)::LoadImage(
NULL,
“b1.bmp”,
IMAGE_BITMAP,
500,
400,
LR_LOADFROMFILE);

mdc->SelectObject(bitmap);
CRect rect;
GetClientRect(&rect);
//BitBlt()
dc.BitBlt(0,0,rect.right,rect.bottom,mdc,0,0,SRCCOPY);

//release mdc
delete mdc;

struct IPicDrawer
{
virtual void GetSize(CSize&) = 0; // It’s the smallest size for EMF
virtual BOOL Draw(CDC*) = 0;
};

BOOL DrawEnhMeta(LPCTSTR lpszFileName, IPicDrawer *pIDrawer)
{
// Draw EMF file, the limitation of DC function refer to MSDN
HDC hDC = ::CreateEnhMetaFile(NULL, lpszFileName, NULL,
_T(“FQ EMF Func\0No Title\0″));
CDC *pDC = CDC::FromHandle(hDC);
if(pDC)
{
CSize sz;
pIDrawer->GetSize(sz);
pDC->FillRect(CRect(0,0,sz.cx,sz.cy), &CBrush(RGB(255,255,255)));
if(pIDrawer->Draw(pDC))
{
HENHMETAFILE hEmf = ::CloseEnhMetaFile(hDC);
if(hEmf)
{
::DeleteEnhMetaFile(hEmf);
return TRUE;
}
else
::DeleteFile(lpszFileName);
}
}
return FALSE;
}

BOOL DrawBitmap(LPCTSTR lpszFileName, IPicDrawer *pIDrawer)
{
// Draw 24 bit true color bitmap file
HANDLE hFile = ::CreateFile(lpszFileName, GENERIC_READ | GENERIC_WRITE,
0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
BOOL bRet = FALSE;
if(hFile)
{
CSize sz;
pIDrawer->GetSize(sz);
BITMAPINFO BmpInfo = {0, }; //
BmpInfo.bmiHeader.biWidth = sz.cx;
BmpInfo.bmiHeader.biHeight = sz.cy;
BmpInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
BmpInfo.bmiHeader.biPlanes = 1;
BmpInfo.bmiHeader.biBitCount = 24; // 24bit
BmpInfo.bmiHeader.biCompression = BI_RGB;
BmpInfo.bmiHeader.biSizeImage = BmpInfo.bmiHeader.biBitCount / 8 *
BmpInfo.bmiHeader.biWidth * BmpInfo.bmiHeader.biHeight;

BITMAPFILEHEADER bmpFileHeader = {0, }; //
bmpFileHeader.bfType = *(WORD*)_T(“BM”);
bmpFileHeader.bfOffBits =
sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER);
bmpFileHeader.bfOffBits +=
sizeof(DWORD) – (bmpFileHeader.bfOffBits % sizeof(DWORD));
bmpFileHeader.bfSize = bmpFileHeader.bfOffBits + BmpInfo.bmiHeader.biSizeImage;
//write file header and image information
DWORD dwNum = 0;
bRet = ::WriteFile(hFile, &bmpFileHeader, sizeof(BITMAPFILEHEADER),
&dwNum, NULL);
bRet = bRet && ::WriteFile(hFile, &(BmpInfo.bmiHeader), sizeof(BITMAPINFOHEADER),
&dwNum, NULL);
if(bRet)
{
bRet = FALSE;
//create file mapping
HANDLE hMap = ::CreateFileMapping(hFile, NULL, PAGE_READWRITE,
0, bmpFileHeader.bfSize, NULL);
if(hMap)
{
// create bitmap object
void *pBits = NULL;
HBITMAP hBMP = ::CreateDIBSection(NULL, &BmpInfo, DIB_RGB_COLORS,
&pBits, hMap, bmpFileHeader.bfOffBits);
if(hBMP)
{
// draw the specified figure to file
CDC memTmpDC;
memTmpDC.CreateCompatibleDC(NULL);
if(memTmpDC.GetSafeHdc())
{
CBitmap *pbmp;
pbmp = CBitmap::FromHandle(hBMP);
if(pbmp)
{
memTmpDC.SelectObject(pbmp);
memTmpDC.FillRect(CRect(0,0,sz.cx,sz.cy), &CBrush(RGB(255,255,255)));
bRet = pIDrawer->Draw(&memTmpDC);
}
}
::DeleteObject(hBMP);
}
::CloseHandle(hMap);
}
}
::CloseHandle(hFile);
}
if(!bRet)
::DeleteFile(lpszFileName);
return bRet;
}

The following article from CodeProject provided a good solution.

• Changing Row Height in an owner drawn Control

And there is a similar article on CodeGuru.

• Changing row height in owner drawn control

When you try to move the item selection of a CListCtrl object, you should remember to call SetSelectionMark. If not, the program will not work as you think. It will only work once and won’t work any longer.

The reason is that even you have called SetItemState and the selection was changed in visiable, but the selection mark still keeps the old value.

The solution is to call the SetSelectionMark function after SetItemState.

Here is a short example.

void CTestListDlg::OnBtnMoveNextItem()
{
int curSel = m_list.GetSelectionMark();
int nCount = m_list.GetItemCount();
m_list.SetItemState(curSel, 0, LVIS_SELECTED);
curSel ++;
if (curSel>= nCount) curSel=0;
m_list.SetItemState(curSel, LVIS_SELECTED,LVIS_SELECTED);
m_list.SetSelectionMark(curSel);
m_list.SetFocus();
}

Such problem often occures because of incorrect signature of message handle functions, that included into MFC message map for your CWnd based class.
We should very carefully check signatures such functions in comparision with expected one by MFC library. For example, if you put follow handler into message map

ON_MESSAGE(WM_SOME_USER_MESSAGE, OnMyMessage)

and define OnMyMessage as:

void CMyWnd::OnMyMessage()
{
//do something
}

this code will be compiled without errors. DEBUG build can work without any problems, but RELEASE will crash besause ON_MESSAGE macro expect follow
signature:

LRESULT CMyWnd::OnMyMessage(WPARAM /*wParam*/, LPARAM /*lParam*/)

DEBUG build works because stack processing has differences for debug and release builds.

so, the solution is simple:

Solution 1:  modify the  message handle functions with the following style and it will be ok.

void CMyWnd::OnMyMessage(WPARAM wParam, LPARAM lParam)

Solution 2:  don’t modify the message handle functios, and change the ON_MESSAGE macro to ON_MESSAGE_VOID.

ON_MESSAGE_VOID(WM_SOME_USER_MESSAGE, OnMyMessage)


This macro is in AfxPriv.h, but is largely undocumented.