Archive for the ‘programming’ Category

Dangerous COleDateTime::ParseDateTime

Friday, August 20th, 2010

COleDateTime::ParseDateTime is a handy function to parse a date string into a COleDateTime (and then SYSTEMTIME and then CTime).

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: Mapping CString to CStringArray

Monday, August 9th, 2010

Just a simple MFC trick. To map from CString to CStringArray use:

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

Silencing command line builds

Monday, August 2nd, 2010

My builds have become more and more complex. Especially when releasing a new version it wasn’t always easy to tell at first glance whether all build steps succeeded. Some tools (I’m not telling names, here) are quite verbose and “pollute” the build log with things that I don’t really care about.

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

Linking .lib files in C++

Thursday, July 22nd, 2010

Sooner or later you will need to link static external library files (.lib files), when developing a larger project. Microsoft C++ can do this in several ways:

  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

The C++ riddle

Thursday, June 24th, 2010

C++ is sometimes even more cryptic that regular expressions. Can you figure out what this one means?

%016I64lx

Amazing customer feedback…

Monday, March 15th, 2010

For one of my projects I have implement a system that handles crashes, reports technical details to me and asks the customer “which program function (hotkey or name in the menu) did you just use?

So far, the answers to this question have often been amazingly useless. For example one customer just wrote: “CRASHED AGAIN! no obvious reason…“. The data shows however that the customer was right in the middle of importing a project.

Yeah, no obvious reason. Customers are only humans, I guess. And some of them more than others…

Weird problem with AfxWinMain()

Wednesday, January 27th, 2010

I spent the last hours hunting down a weird crash problem in AfxWinMain(). It’s the init function in an MFC application that gets called before anything else.

And it crashes at “if (!pThread->InitInstance())” because AfxGetThread() returned a NULL pointer.

The problem was paired with link errors that vanished when the buid was repeated. Since this is “normal” with MS C++ (I’ve seen that problem often before), I didn’t really notice it.

As it turns out the entire code was correct. I imported it into a new project and it worked. Comparing the the vcproj-Files I found the line that made all the difference. Removing this line suddenly fixed my problem:

“ObjectFile=”.\DebugD64″

(in Configuration > Tool Name=”VCCLCompilerTool”).

JavaScript MessageBeep

Tuesday, December 15th, 2009

For quite some time I tried to find something like MessageBeep in JavaScript to attract the user’s attention for a change on the screen. JavaScript doesn’t have anything similar.

But I found a small flash player called niftyplayer that can play mp3 sounds, stay invisible and be controlled from javascript. To get the MessageBeep effect, simply install the player, set width and height to 0 and call niftyplayer(‘niftyPlayer1′).play();

(Thanks to pragma for pointing me in the right direction.)

Using Google to protect your site

Sunday, November 29th, 2009

Is your website error free?

My site  has grown over the years and uses a lot of PHP code. It’s difficult to test each and every aspect of it. Here are 3 simple tricks that can help you test your website. They don’t replace a real test (that you should do after a each change), but they’re a nice addition.

Trick 1:

Use Google to search your website for “error” or “warning”. You can use the format:
site:yourdomain.com (warning or error )

This of course has a terrible lag, since Google crawls your website only every few days or weeks, but on the other hand Google may use different parameters or aspects that you use in your own tests.

The real fun comes with combination of trick 2.

Trick 2:

Use Google alerts to automatically search your website for problems. You can create a free Google alerts account and use the search mentioned above to have Google automatically check your site every day. If something breaks, Google will send you an e-mail.

Trick 3:

Same as above, but use your Google to watch your site for hacked pages. A hacker might have exploited a weakness in your server and created a new page for whatever product he promotes with his spam mails. You probably don’t want to become involved with this. So instead of using “warning or error” in the search. use a list of the usual phrases and medical products that the spam mails usually contain.

It’s a one-time work of a few minutes. The rest of the work is done automatically by Google and can save you a lot of trouble.

Using usertype.dat as spell checker

Sunday, November 15th, 2009

There are thousands of classes, structure, functions and constants in the Windows library and it’s often hard to remember the right spelling. Here’s a simple trick to use the usertype.dat as a very simple spell checker.

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.