[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 204
  • Last Modified:

Windows XP problem.

I have an app I wrote with Visual C++ and released a little over a year ago.  We tested it on Win 95/98/NT/2000 and never had a problem.  It's been in the market and, so far, hasn't had any reported problems.  

I recently got an email from a user that said she put it on an XP machine and after 10 minutes the program shuts down.  No warning; no error messages; just shuts off the program (not the computer).  That sounds like an unhandled exception to me.  I tried to replicate the problem on a Win2k machine and never had it crash.  I don't have access to an XP machine to test it and try to debug.  

This is a shot in the dark.  Does anyone have any idea why a program that never had any problems and seems as solid as a brick would suddenly have this problem in XP?  If I can come up with some possible problems and solutions, I might be able to blind-fix the problem without buying XP. I'd send the fixed program to the same user and see if the problem was resolved.  Thanks for any help.
0
jjjkkklll
Asked:
jjjkkklll
1 Solution
 
SteveGTRCommented:
I encountered a problem with the way various operating systems (NT4, 95, 2000, XP) handle the ::GetWindowText function when processing a RICHEDIT control. The way XP handles the function are dangerous! The problem occurs during standard MFC DDX_Text processing in the AfxSetWindowText() function in WINUTIL.CPP:

void AFXAPI AfxSetWindowText(HWND hWndCtrl, LPCTSTR lpszNew)
{
        int nNewLen = lstrlen(lpszNew);
        TCHAR szOld[256];
        // fast check to see if text really changes (reduces flash in controls)
        if (nNewLen > _countof(szOld) ||
                ::GetWindowText(hWndCtrl, szOld, _countof(szOld)) != nNewLen ||
                lstrcmp(szOld, lpszNew) != 0)
        {
                // change it
                ::SetWindowText(hWndCtrl, lpszNew);
        }
}

The problem occurs when the RICHEDIT field was larger than 256 characters and was being reduced to a size smaller than 256 characters.

The ::GetWindowText() call acts strangly under different operating systems.

On NT4/SP5 and on Windows 95 the function returns 255 and str is equal to the first 255 characters.

On NT2000 ::GetWindowText() returns 0 and str is empty. Calling ::GetLastError() returns 122 (ERROR_INSUFFICIENT_BUFFER). A true statement, but the documentation says: "nMaxCnt [in] Specifies the maximum number of characters to copy to the buffer, including the NULL character. If the text exceeds this limit, it is truncated.".

I'd have expected XP to act the same as NT 2000, and it does sort of. It returns 0, but str is set to
the 1st 256 of data. I wonder if it returned the NULL also? If so, then the stack is messed up.

I fixed the processing in our code by redefining the DDX_Text() function to a custom function that bypasses this processing when dealing with a RICHEDIT control.

Good Luck,
Steve

PS: See http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=cplusprog&qid=20280051 for more information about this problem.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now