In my last post Enable crop and zooming in on your digital photograph display form  there is code that seemed to work just fine for me, but failed for others. I subsequently fixd the code in that post to call ValidateRect, which works around the problem. It turns out that the size of the JPG mattered. Why?


It turns out that it is related to this post from a couple days before: Interesting form paint behavior.


There is this line of code in the zoom/crop code:

thisform.img.picture=thisform.img.picture &&paint over sel rect


This line is meant to repaint the entire picture with itself. VFP invalidates the image control, causing Windows to send a WM_PAINT message. If the processing of the subsequent code (the rectangle calculation, the creation of GDIPlus objects, etc) takes long enough (200 millisecs), VFP will check to see if there are any pending events and dispatch them. Thus the WM_PAINT will be processed and the window rect will be painted and validated. A way to force the rect to paint immediately is DOEVENTS (force). Calling ValidateRect causes the rect to be removed from the update region for WM_PAINT, so it won’t be painted.


It seems that my machines are so slow that they take more than 0.2 seconds to process a 1 Meg JPG file.


One way to prevent WM_PAINT from being processed in the middle of code execution is to set _VFP.AutoYield =0 (don’t forget to remove the ValidateRect call )

If the WM_PAINT processing occurs after the zoomed in image is drawn, then the zoomed image is overwritten and it appears that the zooming code doesn’t work at all.


Thanks to Dawa Tsering and Craig Boyd for pointing out this behavior and giving good suggestions and explanations. (and Randy Brown, Richard Stanton for helping too!)