Chris Maunder wrote: coming out soon :) Vasudevan Deepak Kumar Personal Homepage Tech Gossips

Harold Bamford wrote: I just don't think that being critical of somebody's work, that has survived for many years, on the basis of holier-than-thou is appropriate. I don't anyone in this thread has had a holier-then-thou attitude. The only debate is the definition of fragile code. The way I define it is code with unnecessary dependencies on other parts of the application. In this case it is the UI of the application. A code wizard like that should just manipulate the files directly without being dependent on any kind of keyboard layout. Those extra dependencies which tend to build up over time are probably the biggest source of bugs in any application, which is why so many developers have such a dim view of them. Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder

This should now be fixed. cheers, Chris Maunder CodeProject.com : C++ MVP

Got it, thanks!

K(arl) wrote: As I understand it, you want to force the size of your application. I would do so by resizing the MainFrame object, using CMainFrame::SetWindowPos. Then I would catch the WM_SIZE message in the Form View to handle controls size and position changes. Oh, and you can manage the way your view handles scroll bars by overring CScrollView::SetScrollSizes. OK, now I understand what you meant. What I am doing now is use WindowSetPos() and SetScrollSizes. Pretty much as you suggested. I didn't understand from the documentation what SetScrollSizes did. It just sets the the threhold for window size for when the scrollbars appear. Which is what I needed. Thanks for your help.

THAT's what I was looking for! Thanks!

That's it! I know about and use SetWindowPos() but I just couldn't think of it. Thanks! And here is my working implementation (if anybody wanted to see actual code): ///////////////////////////////////////////////////////////////////////////////// // This assumes a REPORT-style CListCtrl. // // Resize the control. This works correctly only if scrolling is disabled. If // there is scrolling, then setting to the size from ApproximateViewRect() will // always give scroll bars showing. Which is irritating. // // We need to adjust the vertical size from what ApproximateViewRect() returns // by one row minus border width ////////////////////////////////////////////////////////////////////////////////// CSize sz = m_list.ApproximateViewRect(); // always adds room for a new row CRect itRect; // Get the height of a single row (there had better *be* a row!) m_list.GetItemRect(0, &itRect, LVIR_BOUNDS); int vOffset = itRect.Height() - 3; // leave a little 'cuz it looks better m_list.SetWindowPos(NULL, 0, 0, sz.cx, sz.cy - vOffset, SWP_NOZORDER|SWP_NOACTIVATE|SWP_NOMOVE);

Thanks.

Well, I tried it and the method suggested by you and Joaquín M López Muñoz worked perfectly. On the off-chance that AcroRd32.exe creates an empty file before writing to it, I added a check for a non-zero length file, but basically the technique works. Thanks to both of you!

OK, thanks to all you folks giving me help, I think I have it. I now use FindExecutable() to get the default program, then CreateProcess() to spawn it: // Get the name of the program that runs on a .pdf file char *filename = "C:\\src\\IOGuides\\PDF Files\\751018a.pdf"; TCHAR szExe[MAX_PATH]; ::FindExecutable(filename, _T(""), szExe); HANDLE hProcess = NULL; // Use for WaitForInputIdle() STARTUPINFO startupInfo; PROCESS_INFORMATION processInfo; ::ZeroMemory(&startupInfo, sizeof(startupInfo)); startupInfo.cb = sizeof(startupInfo); ::ZeroMemory(&processInfo, sizeof(processInfo)); // better safe than sorry char cmd[MAX_PATH + MAX_PATH + 5]; sprintf(cmd,"\"%s\" \"%s\"", szExe, filename); BOOL startedOK = CreateProcess( NULL, cmd, // "acrord32.exe file.pdf" NULL, // Process security NULL, // Thread security FALSE, // Inheritance 0, // no special startup flags NULL, // no special environment NULL, // no default startup directory &startupInfo, &processInfo); if(!startedOK) { ShowLastError(filename); return; } hProcess = processInfo.hProcess; WaitForInputIdle(hProcess,INFINITE); I then get the process ID from processInfo.dwProcessId and enumerate all the windows, using GetWindowThreadProcessId() to get the associated process ID. BOOL CIOGuidesView::enumwndfn(CWnd * wnd) { WININFO wininfo(wnd); wnd->GetWindowText(wininfo.title); DWORD ProcessId; GetWindowThreadProcessId (wnd->GetSafeHwnd(), &ProcessId ); wininfo.Pid = ProcessId; m_WinInfoArray.Add(wininfo); return TRUE; } Comparing processInfo.dwProcessId against the value from GetWindowThreadProcessId() gives me the match-up I needed. Unfortunately, AcroRd32.exe is cutesy and allows only one instance to run at a time. If I already have the Reader running, the new process just closes down. Presumably after talking to its counterpart and giving the new filename. Sigh. I guess I can kill the old one first, but that won't alway work if the user manually started up AcroRd32. Thanks for all your help. I'll probably make a "beginner" level article showing all of this in the next few weeks since doing this is not so obvious. I suspect the trick in making the article will be coming up with keywords and phrases to allow people to find it when they are looking to do this kind of thing. All the information I needed was in the articles; I just couldn't find it. Again, many thanks for all of your