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 excepts 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.

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)

This code looks harmless enough:

CFileStatus rStatus;
CFile::GetStatus (MyFilename, rStatus);

And it will work most of the time. But CFileStatus uses CTime, which is limited to dates after 1.1.1970. If you apply this code to a file with a file-modification date of e.g. 1.1.1960, GetStatus will raise an exception. (Which it isn’t documented to to.) And if you don’t catch that, it will terminate your program.

char dir[2048];
GetCurrentDirectory(2048, dir);
printf(CString("Current dir is:")+dir));

That’s doesn’t look bad, does it? And (like in the great programmer quotes), it works on my computer. But it doesn’t work if the customer’s current folder is something like “%&§something”, because it contains %s.

So don’t throw any external data at the first parameter of printf, sprintf, etc; instead put it into the following parameters.

printf(“Current dir is: %s”, dir);

The problem is that the expected date format depends on the user’s system settings. If you’re parsing a string that is always in the same format (from a file or from the internet), then parsing might work on your computer, but fail on the customer’s computer (in another country).

Solution: Use the locale ID parameter to force the parsing language.

CMap<CString, LPCTSTR, CStringArrayX, CStringArrayX&>

where CStringArrayX is defined as:

class CStringArrayX : public CStringArray
{
 public:
 CStringArrayX() {}
 CStringArrayX(const CStringArrayX &qSource);
 CStringArrayX &operator = (const CStringArrayX &qSource);
};

CStringArrayX::CStringArrayX (const CStringArrayX &qSource)
{
 SetSize (qSource.GetSize());

 for (long c=qSource.GetSize()-1; c>=0; c--)
   (*this)[c]=qSource[c];
}

CStringArrayX &CStringArrayX::operator = (const CStringArrayX &qSource)
{
 SetSize (qSource.GetSize());

 for (long c=qSource.GetSize()-1; c>=0; c--)
   (*this)[c]=qSource[c];

 return (*this);
}

Hopefully this post keeps some people from searching as long as I did…

Here’s a simple freeware tool that I wrote to fix this: SilentCommandline.exe. It works as a DOS pipe with filter functions that can be configured in two external text files.

Using SilentCommandline:

Simply append it to your build batch files:

yourbuildcommand.exe |SilentCommandline.exe

It will take all output of  yourbuildcommand.exe, check if you want to see it and print it to stdout. To configure what you want to see, create 2 text files in the same folder where you keep SilentComandline.exe and name them silentlines.txt and silentlinesre.txt.

Config files:

The first one is simple. On string per line. If one of the strings equals a line from your build output, then this line will not be printed. You can use that for static texts that are always the same. Example:

Succeeded

The second file works basically the same, but allows you to use regular expressions in each line. Use it to handle build outputs that might change. Example:

Protected[0-9]* blocks of [0-9]* blocks total.

Download:

Here’s the download link to SilentCommandLine.exe

System requirements: Windows

1. Link settings in the project properties
2. Adding the file to the source file tree
3. Using a #pragma

So far I’ve mostly used 1 & 2, because they’re the easiest and most obvious ways. Solution 2 can even be used conditionally for certain build types (by using the “exclude for this build” option).

But with the projects getting more complex, I found that solution 3 is the best and switched projects to that. The reason is that different combinations of project types (debug/release 32/64 Bit) are otherwise quite difficult  to handle.

With #pragma’s is does take some space in one your .cpp-files, but at least the different conditions are easy to understand and verify:

#ifdef _WIN64
  #ifdef _DEBUG
    #pragma comment(lib, "C:\MyPath\\MyDebug64.lib")
  #else
    #pragma comment(lib, "C:\MyPath\\MyRelease64.lib")
  #endif
#else
  #ifdef _DEBUG
    #pragma comment(lib, "C:\MyPath\\MyDebug32.lib")
  #else
    #pragma comment(lib, "C:\MyPath\\MyRelease32.lib")
  #endif
#endif

%016I64lx

Usertype.dat?
First, usertype.dat is a file which can be configured in the MS IDE (see help file, because it differs with the versions). Simply activate it and use my usertype.dat as a start. It contains almost 4000 key words from the libraries.

When you now type one of these key words right, it will be displayed in a different color (I prefer gray – to emphasize that I don’t have to pay attention here). Here’s how it can look like.

Example:

Note that all the common things like HICON, LoadImage or LR_DEFAULTCOLOR are written in gray because they’re spelled correct. And other words (variables in this case) like hIcon and IconId1 a printed in white because they’re not predefined. If I had written Load_Image (instead of LoadImage), it would have been printed in white, too, and I know that it might be incorrect.