Thanks Fabrice I look forward to a revised V3.
I have done some more experimenting with the V3 DLL and V1.2 AEF in my app
and it appears that the V3 DIBResizeBox() does retain the bpp settings of
the original picture (4,16,24 etc). At least according to the values in
the
resized bitmapinfo.bmiheader.bibitcount. As a test I then used a
DIBSaveAsJpeg() on the resized image and viewed the jpeg file in a
graphics
program, and the resized thumbnail is indeed the correct size, but the
DIBSaveAsJpeg() automatically converts its output to 24bpp output.
So assuming the DIBREsizeBox() function is working correctly in V3 then
the
only thing left is either the DIBGetHandle() function is not working
(which
your last post suggested may be the case) or some incompatibilty in
bbrowser.
hbitmap does return numerous different values in my app, but they may be
invalid values as they result in blank thumbnails in bbrowser.
I look forward to your revised V3 DLL to see if the DIBGETHAndle() is the
problem and if it is fixed.
Thanks
Ken Yorke
"Fabrice Foray" <fabrice.foray@[EMAIL PROTECTED]
> wrote in message
news:cb2e3854-cc8f-49d3-b140-8816b3ced0b2@[EMAIL PROTECTED]
> Hi Ken,
> sorry sorry my fault !!!
> The current public FabPaint V3 has a nasty bug in the GetHandle()
> function, so this one will ALWAYS return a null pointer, which might
> your trouble....
> I currenlty ending the lastest tests on the coming release than, at
> least, is correcting this bug.
>
> I'll also have to correct the do***entation in ResizeBox, thanks..
>
> Sorry for the inconvenience,
> Fabrice.
|
