Been busy with common controls and implemented a trackbar (At last..it works fine !) As I have limited skills in programming, I looked into MSDN and wonder how I can implement the buddywindows that are by default assigned to both ends of the trackbar...? I'd like these to show two icons..I have to work with the TBM_GETBUDDY and TBM_SETBUDDY Messages but I don't know how to proceed. Another thing is: whenever I click in the trackbar area ,a dotted line (probably the bounding rectangle) appears around the trackbar. Does anyone know how to prevent this? Should I send WM_KILLFOCUS messages or something? Ok, enough questions. Any help would be greatly appreciated.

Thanks. It seems I made a mistake Moreover I assumed that VC++ would "know" what platform I'm working on: this seems to be not the case. I #defined _WIN32_WINNT as 0x0500 abd now everything is working fine..:)

thanks for respons. I'm beginner to Winprog and VC++ I tried including , but no improvement. Still the same undeclared WM_MOUSEWHEEL identifier.... My WM_LBUTTONDOWN is accepted though, both with and without . WM_LBUTTONDOWN must be defined elsewhere also I concluded. Next I outcommented WIN32_LEAN_AND_MEAN in Stdafx.h hoping this would make a difference. nope. Other includes (a.o.): windows.h en windowsx.h

Joel Lucsy: I clicked on the link but the (forum) page states that the page can't be found.....

Maybe a stupid question but: I'm on Win2k with Visual C++ 6.0 and it seems nearly impossible to get any mousewheel code to work..... I had to specifically #define WM_MOUSEWHEEL 0x020 to avoid "undeclared identifier" messages. Sadly my OnMouseWheel method is not recognized anyway. I encountered several working MFC examples. Unfortunately I don't use MFC so my question is: Is it possible to get this working without MFC? Do I need a special include for this? thanx in advance

Need help please. Sorry for long and tedious introduction. In Win32 API the OpenFileDialog runs by initializing the OPENFILENAME struct. (quote msdn) a buffer provided in the ofn.lpstrFile member holds all the file info including path. The ofn.lpstrFileTitle holds the name of the file and ofn.MaxFile member points to the offset in the string contained in lpstrFile where the filename is located. If ofn.dwFlags is provided with the OFN_ALLOWMULTISELECT flag ,one is able to select multiple files at a time ,which all are contained-separated by '\0'- in the lpstrFile buffer. So this would look someting like "C:\programs\myapp\0file1.txt\0file2.txt\0" msdn states that if the multiselect-flag is NOT set,than the system takes the path info from the lpstrFile buffer. However,this seems not to be the case when the multiselect flag is set. It seems that in multi-mode directory information is no longer preserved. Sadly msdn doesn't touch this subject, does anyone know if ,and how the path info in case of multiselect is stored? For processing more selected files, I read them out of the buffer one at a time and strcat them to the path,yielding a usable file-identifier. Problem however is that if I select files from directories that are further from the root,and with many characters in their name, these files seem to be invalid as the system doesn't process them any more. As this smells of a buffer undersize,I tried enlarging sizes of various buffers and intermediate var's but however, with no success up to now. Maybe someone has a tip? I.m currently ona Win2k system thanx in advance