You are not supposed to use MM_ISOTROPIC with scroll views. The Scroll view has a function SetScaleToFitSize which will scale the view to the window size.

Search for "3D Graph ActiveX Control" at codeprject. I have not studied the code but it should help. There is no lack of graphics related sites on the www. INTP

:) Yeah, and when you figure it out, think about writing an article to post. That would be cool :cool: It shouldn't be too difficult, but will depend on the shape you're working with. If you're dealing with a polygon, you can calculate the distance out of the box for each point, and scale all the points so that the furthest one fits in the box. Sounds complex, but I don't think it is really, just takes a bit of thought :) Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Do you try scaling the width accordingly to the results? Example: Desired width = 100 1. pass: Font width = 17 and you've got 135 pixels wide output. 2. pass: Font width = 100*17/135 ~= 12 and you should get roughly 100 pixels. Sure it won't give exact results (because of all the kerning and precision bloat) but I think it's a better approach.

When you close the view, make sure you call the property sheet's DestroyWindow(). This should take care of the problem. When the view gets created, do: m_pPropSheet = new CMyPropSheet (...); ASSERT (m_pPropSheet != NULL); m_pPropSheet->AddPage (...); m_pPropSheet->AddPage (...); m_pPropSheet->AddPage (...); When the view gets destroyed, do: ASSERT (pPropSheet != NULL); m_pPropSheet->DestroyWindow(); delete m_pPropSheet; /ravi Let's put "civil" back in "civilization" http://www.ravib.com ravib@ravib.com

Take a look at purify plus for windows (IBM) it's a program that helps you to track memory leaks and so on... it also have a function that check the compatibilities of other OSes in your code... You can download a trial version...

Try a service pack (or not, see my most recent thread...) I know there were problems with sockets and statically linked MFC, which was supposedly fixed in SP5.

cdsmith wrote: - Will the the off-screen approach work for print preview and printing? It should do, but it may be possible that you could hit an upper limit on the size of the bitmap. As some printers work in very large resolutions (3000 by 3000 or larger), this can cause a very large bitmap to be created. I think there was some upper limit on the size in earlier versions of windows (9x) cdsmith wrote: the other problem I have is that some of the graphics I draw are transparent In my experience, BitBlt works ok for the preview by does not produce output in the actual print for most printers. As you cannot guarantee what printer your user may have, I would suggest moving to the more generic StretchDIBBits() function which I haver never known not to work on a printer. The only issue you may have is that StretchDIBBits() may not support your transparanecy stuff. As I have never used it for that, you will have to investigate using the documentation. Hope it works out for you. Printing can be hard work. Roger Allen Sonork 100.10016 Were you different as a kid? Did you ever say "Ooohhh, shiny red" even once? - Paul Watson 11-February-2003