>devblog_

Got weird crashes at customers with foreign languages? Microsoft’s MFC’s MakeLower could be the culprit. Seems to be poorly written because it can crash if it doesn’t like the string. I could even reproduce it here by switching the Windows-Locale for non-unicode apps the Japanese and process some strings contains German umlauts. Bottom-line? Don’t use, write your own…

After porting Easy2Sync for Files to Unicode I experienced some really weird problems with some foreign characters. Unicode in general worked, Japanese characters were displayed nicely (not that I could read them). But Cyrillic characters failed when printed with TextOut and were displayed as small black rectangles.

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…

It sounds quite mad, but either of these lines can crash a program: (C++, Visual Studio 2005)

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.

It sounds pretty straightforward to enumerate the resources  in a file. But it turned out to be rather a lot of work (and waste of time), since the MS doesn’t tell you, that it doesn’t enumerate the strings, but blocks of strings in a binary format that you have to process yourself.

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);

Just a tiny trick today.

When you’re programming, you’re often…

• typing something
• Then you browse through the same file, look for something
• copy something
• And now you want to get back  to the place that you previously edited.

There’s a secret hotkey (actually a sequence) for that which works in most editors: Ctrl+Z, Ctrl+Y.

Works in Visual Studio, Word, text editors, etc.

One of my favorite internal functions. It helps my manage my app’s GUI. Checkboxes that cause their sub-elements to be greyed out when not checked can be easily handled by this:

bool EnableWindowsDependingOn (CWnd *pParent, DWORD DependingOnThisCheckbox, DWORD Value1, ...)
{
 va_list marker;

 bool bState = (((CButton*)pParent->GetDlgItem(DependingOnThisCheckbox))->GetCheck()!=0);

 DWORD i=Value1;
 va_start (marker, Value1);
 while (i != 0)
 {
 if (i<=0xffff)
 {
 if (pParent->GetDlgItem(i))
 pParent->GetDlgItem(i)->EnableWindow (bState);
 }
 else
 ((CWnd*)i)->EnableWindow (bState);

 i = va_arg (marker, long);
 }
 va_end (marker);

 return (bState);
}

It accepts the “this-pointer” of your CDialog and the id of the master checkbox. Then you can append any number of sub-element ids or pointers. And finally a NULL. Example:
EnableWindowsDependingOn (this, IDC_CHECK1, IDC_EDIT1, IDC_EDIT2, NULL);

This would enable the two edit boxes if the checkbox is enabled.

Placing a breakpoint can be dangerous. In some code sections, like drawing a menu, Windows doesn’t like to be interrupted. The debugger will stop your application, but your app will remain on-screen and Alt+Tab and all other options of changing the current application are blocked.

Except, if you’re using Windows 7.

For some reason the 3d-flipping mode with Win+Tab still works. And allows you to switch to the debugger.

Step 1: Waste hours researching to find out how to do something trivial. (Like renaming the insert link)

Step 2: Curse Microsoft

Step 3: Throw out the MS way and program it yourself.

Repeat for every trivial issue.

There’s a hidden switch in Visual Studio 2005 while doubles compile speed.

I know, it sounds ridiculous.  But I’ve tested it. It’s MUCH faster now. The switch works by enabling multi-core processing. I have no idea why Microsoft has hidden this, instead of making it a big, obvious feature.

Anyways. You can enable it by adding /MP to the “Additional options” in “Configuration properties > C/C++ > Commandline”.

(Found it at 1 and 2)