Like all statistical data, it’s up to the reader to interpret it.

Google Correlate

1. Making it run with XP

Go to “configuration properties > general” and switch the “Platform toolset” to “Visual Studio 2012 – Windows XP (v110_xp)”.

2. Making it run on older systems

This caused me hours of work. By default VS2012 will “optimize” fp-operations. But it doesn’t work on all systems. Don’t know if it’s the older processors but I had at least 2 customers where a simple statement as “myfpvar=1″ caused the program to terminate without error message. To fix this go to “C++> Code generation” and set “Enable enhanced instruction set” to “No Enhanced Instructions (/arch:IA32)”.

In the end it turned out it both cases that the customer had not done these simple steps or not done them properly or whatever.

For me this means that I should work even even more with log files, configuration files and other “hard evidence”. And less with what the customer says…

Even weirder: Adding just 1 Japanese character to a string with Cyrillic characters caused the entire string to be printed right.

It seems that TextOut is only 50% Unicode compatible (of course Microsoft doesn’t mention this). So one has to use DrawText instead, which doesn’t seem to have these limitations. Since DrawText behaves differently regarding the position and background drawing, here’s a wrapper which fixes this and makes it behave like ExtTextOut:

void FixedExtTextOut (CDC *pDC, int x, int y, UINT nOptions, LPCRECT lpRect, LPCTSTR lpszString, UINT nCount, LPINT lpDxWidths)
{
 CRect rr(x, y, lpRect->right, lpRect->bottom);

 pDC->FillSolidRect(lpRect, pDC->GetBkColor());
 pDC->DrawText(lpszString, nCount, &rr, 0);
}

You're not gonna catch this... (LIttle League baseball, May 2009 - 03 by Ed Yourdon; CC BY-SA 2.0)

C++ exceptions can be surprising. This works easily:

try
{
throw(1);
}
catch(…) //Catch all
{
//caught
}

But if you replace “throw(1);” with “throw;”, it suddenly doesn’t work anymore. Code compiles, exception is thrown, but it’s not caught. The program is terminated…

To fix this, override the program’s PreTranslateMessage  function and add this:

 if (pMsg->message==WM_MOUSEWHEEL)
 {
    CPoint point;
    GetCursorPos (&point);

    HWND hWnd = ::WindowFromPoint (point);

    if (hWnd && pMsg->hwnd!=hWnd)
    {
       ::PostMessage(hWnd, pMsg->message, pMsg->wParam, pMsg->lParam);
       return(true);
    }
 }

Please note that you have to add this  before calling the default implementation of PreTranslateMessage.

long x = long(my_float_var);
float f = exp(my_float_var);

If the number is too large/small, the program is terminated. (No, try/catch doesn’t help.) And to make it even stranger, this happens only on some computers. And of course it happened on the customer’s computer and not on mine…

To fix this, it helps to turn off the floating point exceptions:
control87(_EM_INVALID|_EM_DENORMAL|_EM_ZERODIVIDE|_EM_OVERFLOW|_EM_UNDERFLOW|_EM_INEXACT, _MCW_EM);

Of course the problem of the large number still exists, but now the program at least continues to run, and I have a chance to handle it.

Here’s how to do it:

BOOL CALLBACK EnumResNameProc(HMODULE hModule, LPCTSTR lpszType, LPTSTR lpszName, LONG_PTR lParam)
{
 switch ((int)lpszType)
 {
 case RT_STRING:
 {
 HRSRC hRes = FindResourceEx(hModule, RT_STRING, MAKEINTRESOURCE(lpszName), MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL));

 if (hRes)
 {
 HGLOBAL hGlo = LoadResource(hModule, hRes);
 LPCWSTR lpStr = (LPCWSTR)LockResource(hGlo);
 DWORD dwsize = SizeofResource(hModule, hRes);

 long count=0;
 for (int i=0; i < (int)dwsize; i++)
 {
 count++;
 if (count>=16)
 break;

 if (lpStr[i])
 {
 WORD *pString = lpStr+i+1;
 long lString = lpStr[i];

 //Process string here

 i += lpStr[i];
 }
 }
 }
 }
 break;
 }

 return(TRUE);
}

EnumResourceNames(hModule, RT_STRING, &EnumResNameProc, NULL);