home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / mswindo / programm / misc / 1826 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.0 KB

  1. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!unidui!hm329sc@duc220.uni-duisburg.de
  2. From: hm329sc@unidui.uni-duisburg.de (Scheunemann)
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Subject: Re: StretchDIBits and one other question...
  5. Date: 14 Sep 1992 18:15:08 +0200
  6. Organization: Universitaet Duisburg GH
  7. Lines: 43
  8. Distribution: world
  9. Message-ID: <hm329sc.716483147@duc220>
  10. References: <1992Sep13.231220.686@twisto.eng.hou.compaq.com>
  11. NNTP-Posting-Host: unidui.uni-duisburg.de
  12.  
  13. In <1992Sep13.231220.686@twisto.eng.hou.compaq.com> mccreary@sword.eng.hou.compaq.com (Ed McCreary) writes:
  14.  
  15. >I'm having an odd problem with StretchDIBits (and SetDIBitsToDevice also.)
  16.  
  17. >I'm using it do display grey scale images but for some reason it
  18. >doesn't seem to work with certain dimensions.  Here's a code fragment:
  19.  
  20. > lpbmi = (LPBITMAPINFO)GlobalLock(hbmi);
  21. > lpImageBits = (char huge *)GlobalLock(hImageBits);
  22.  
  23.  
  24. > i=StretchDIBits(hdc, 0, 0,
  25. >        nZoomFactor*nImageWidth,
  26. >                nZoomFactor*nImageHeight,
  27. >        0, 0, nImageWidth, nImageHeight,
  28. >        lpImageBits, lpbmi,
  29. >        DIB_RGB_COLORS, SRCCOPY);
  30.  
  31. >nZoomFactor is an integer used to perform a quick and dirty zoom on
  32. >the image.  The rest should be self explanatory.  Now it works fine with
  33. >images with dimensions of 200x200 and 800x800, but when I try 130x130
  34. >or 255x210 it fails.  It returns 0 meaning 0 lines displayed.
  35.  
  36. >I've checked all of the variables right before the function is called,
  37. >and they all are correct, yet it still fails!!  I'd appreciate any
  38. >hints.
  39.  
  40. I had the same problem using StrectDIBits. For certain dimensions the
  41. function just returned 0. In my case the reason for this was, that each
  42. line of the image had to be expanded to a multiple of 4 byte (adding some
  43. zero bytes if neccessary). Somehow StretchDIBits seems to check the size
  44. of the image (which is in the BITMAPINFO) against a value which it calculates
  45. itself and if it finds a difference it apparently does nothing.
  46.  
  47. Hope this helps
  48. Thomas Scheunemann
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.