I have downloaded the source code both for the GUI and the command line version of winfingerprint. Unfortunately the GUI version is giving me problems. I believe that some ASSERT fails somewhere while loading GDI resources. Unfortunately it is not simple to download the source code from the CSV system here for files get modified (the combination of carriage return + line feed of win32 boxes is here subtituted by a single carriage return). Couldn't you provide the source code packed inside zip files? Also the macro HAS_BIT_STYLE is defined inside the ADSIHelpers.h file that you are not providing with the source code.
The ADSIHelpers.h file comes from the platform SDK which is availabler here: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
What OS are you running? I test it on the English versions of Windows 2000 and Windows XP.
The command line version in 0.5.0 should not fail and the ASSERT() should be removed when you compile release version.
You might want to check out wincvs (www.wincvs.org) for downloading the source at it has carriage return replacement options.
I would be happy to work with you on the problem once we can track down the details.
the compiled GUI version downloaded from here works fine on my machine. What is failing is the version I compiled on my own machine. I'm using a Windows 2000 Server (SP2). You may be interested in knowing that the release version of your application runs fine. It's the debug version that breaks.
Okay, I just tried compiling a debug version and I am getting the same results ;)
I will track this down today. As a start, remove the assert for HAS_BIT_STYLE and that obviously clears up one problem, getting another error I will track down later today.
Fixed problem by #ifndef _DEBUG for the OnCtlColor() stuff that changed the look of the interface and removing the assert(). Checking into CVS now, thanks for pointing this out.
The problem has reappeared in the OnCtlColor() for DEBUG compile. (I presume it's re-appeared since I don't see #ifndefs that you refer to in the previous post. My copy of the code is current as of 8-20.)
This time the problem disappears if you comment out the
line of OnCtlColor().
Nice program, btw.
The #ifndef _DEBUG were removed as they break classview/classwizard. The OnCtlColor() overrride is really just a gimmick anyway as it serves no purpose other that to recolor the dialog. If this is really a problem I can remove the color stuff from the codebase.
You might want to remove the setting of the bg color to dark blue now that the text color in that field is black again. :)