I have noticed a "visual scrolling" problem with owner-draw list boxes (both mine and others) in XP. This occurs with both stand-alone list boxes and ones associated with a combo box. The problem occurs if the My Computer | Properties | Performance Options | Visual Effects | Smooth-scroll List Box option is checked. The animated scrolling generated by windows is okay unless you click on the scroll bar to generate page-up/page-down messages. With this, the scrolling animation visually appears to be going in the opposite direction as expected...but when the animation terminates, the appropriate update has occurred (e.g. the expected items are visual). This is quite obvious when the list box size is large enough and the items are different in appearance. This does not appear to occur with non owner-draw list boxes. I cannot find any reference to this bug but it is clearly reproducible. Is anyone aware of a fix?

Does anyone know what determines the LOGFONT values received by the EnumFontFamExProc callback function (for TrueType fonts). At least on my test system, it is not affected by current dpi settings. It's easy to calculate the point size for the values received but I do not appreciate any patterns. For example, some fonts have values that are related to 24 point and others to 12 point. Are they values embedded in the *.ttf file?...perhaps related to a master glyph size?

Many introductory C++ programming books try to stay platform/compiler independent. So you are left figuring out your IDE on your own. Or worse yet, if you don't have an IDE then you will have to figure out how to build on the command line...ouch! Okay, I admit I tinker around with gcc but only for fun of it.;P I use VS .NET Pro 2003. Whether you use the .NET framework or not, in my opinion, this is a major improvement over the VC 6.0 for several reasons. Its compliance with the ISO/ANSI C++ Standard is just shy of 100%. Improved Intellisense. Improved debugger. Improved class browser (includes base classes, marcros, message maps). Improved IDE. More stable. MFC 7.0 is improvement over 6.0. Probably other reasons I can't think of right now. VC 6.0 is fine for learning the language, though. If you were going to buy one thing, I highly recommend Visual Assist from Whole Tomato (www.wholetomato.com). It's worth its weight in gold. You can still get the VC 6.0 version.

While it is true that Longhorn promotes managed code, there is backward compatibility the Win32 API. Without it, I don't think anyone would upgrade to Longhorn to see hundreds (or thousands) of dollars of legacy software not run on their new system. Also, just look on this site...there is a lot of good public domain C++/MFC code that likely won't be "ported" to managed code anytime soon. There are a lot of solidly written apps that rely on MFC which would be expensive to rewrite in managed code. So while it is true that MS is pushing the industry hard in the managed code direction, it has to overcome a tremendous amount of inertia. The history books haven't been written yet. So don't worry, start with learning the core C++ language (many good books) including standard C/C++ library and STL. The direction you take from there can be many depending on your goals (i.e Win32 API, MFC, .NET, WinFX, device drivers/Native API, COM/ATL, etc.).

#include #include using namespace std; int main() { fstream file; int size = 0; file.open("test.txt",ios::in); //Replace test.txt with file name if(file.is_open()) { file.seekp(0,ios::end); //Move position of stream to the end size = file.tellp(); //Get position at end which tells size file.close(); } cout << "File size: " << size << endl; return 0; }

1. Overloaded function errors due to missing const qualifier in function definitions When you declare a member function constant, the const qualifier is also required in the function definition (and declaration). For example, class Employee { ... int GetAge() const; ... }; int Employee::GetAge() const{ return age; } 2) Don't declare SetYearsOfService() as a constant member function (leave off the const at the end) 3) Missing ; in SetYearsOfService() void Employee::SetYearsOfService(int YearsOfService2) { yearsOfService=yearsOfService2; }

There are several options. Here are a few: - standard C++ lib: - MFC: CFile, CstdioFile - Win32 API: CreateFile() “…is this even a good idea…” No. There are so many reasons but the most obvious is nothing is encrypted. It appears your intent was to “password protect” a file but it only works if the file is opened with your app. What’s to stop someone from opening the file with notepad.exe for example. You have hard-coded the password into the code. Bad idea. With little effort, someone could just open your compiled exe with a hex editor and nab the password. The list goes on (and its long). Encryption is a very complex subject. If you are seriously interested consider picking up a copy of Bruce Shneier’s Applied Cryptography. you wrote: “ if(password = (password)) “ what you meant was: if(password == pword)… I have seen some of your other posts on this forum and I am not sure what compelled me to answer this one. I would suggest searching www.msdn.microsoft.com and google for your questions and if they still remain unanswered, post them as a question. “How to open a file” can be answered in less than 1 minute by searching the above sites

In the context of C++, is there technically a difference between, qualifier and modifier. I have seen the phrase "const modifier" and "const qualifier" used interchangeably. Clarification and/or references would be appreciated. Thanks Mike

Try to avoid TerminateProcess() if possible. See MSDN description of TerminateProcess for the reasoning. Solutions depend on whether the child process has a top level window or are running in a console. I'll assume the child process you describe will be running in a console. One way is to... 1. Spawn child process with ShellExecuteEx() or CreateaProcess() 2. WaitForSingleObject(Handle_To_ChildProcessID,YourTimeOutValue)...consider putting this in worker thread 3. If times out, then kill child process ***NOTE: I have read about others getting CreateRemoteThread to work as described below but I personally have not confirmed this. CreateRemoteThread is available in NT/2K/XP. X| *** - CreateRemoteThread() using the ProcessID handle you got from CreateProcess and passing the address of ExitProcess() as the lpStartupAddress. ExitProcess() appears to be mapped to the same address in each processes address space. You can obtain this address by using the address from your process. - When the remote thread starts (and calls ExitProcess) within the child process, the child process can now "cleanly" terminate. If the child process has a top level window, then just PostMessage(HandleToChildsWnd, WM_CLOSE, 0,0), then confirm the process terminated. Regards Mike

This link error is occuring because your compiler/linker settings are expecting WinMain(...) as the entry function, not main(). This occurred when creating the project. You can get the above code to compile by manually setting the compiler/linker settings: - Make sure your "Solution Explorer is visible" ( View | Solution Explorer) - Right click on project (**not the solution**) node in Solution Explorer tree view and select properties - Click on C/C++ | Preprocessor. On the right hand side you will see "Preproccesor Definitions". - Replace _WINDOWS with _CONSOLE (NOTE the underscore) - Now, click on Linker | System. Click on the "Subsystem" on the right. Once the Subsystem line is active and drop down arrow appears to the far right. Click on that and you will see a list of choices. You want to change the "Windows (/SUBSYSTEM:WINDOWS)" to "Console (/SUBSYSTEM:CONSOLE)". - Compile. Should work. Now "int main()" is the expected entry function. The above can all be avoided by selecting a "Win32 Console Project" instead of a "Win32 Project" when you create a new project. And by the way, I am assuming your iostream header was included and was clipped from your code above because the "< >" was treated as an HTML tag in the post. Mike

Try CxImage (search codeproject). Mike

Check out CPhysicalDiskFile, part of the Win32 Foundation Class (WFC). See links below. www.samblackburn.com/wfc/CPhysicalDiskFile.htm www.samblackburn.com/wfc/ Mike

Check out CxImage. Someone posted a thumbnail function in the article discussion thread (which worked well). I haven't tried the lastest version, but it looks like he now has included thumbnail support. Regards Mike

There is a known bug in the getline() VC 6.0 version (see MS KB #240015). This KB article has a "fix" which requires editing the string header file. It may not be related to the problem your having, but underscores your suspicions of getline(). By the way, it executes as expected in VS.NET 2003 without revision. Regards Mike