XnView Software

Continuing 2.90 to 3.40 upgrade.
Good evening.

Loading files with gflLoadBitmap I used GFL_LOAD_PARAMS::GFL_LOAD_CALLBACKS::AllocateBitmap to load bitmap into my own structure. My Callback function was something like this:
void* GFLAPI MY_CALLBACK_FUNCTION(GFL_INT32 width,
GFL_INT32 height, GFL ...

I apprehended it, but hoped for the best
So, LoadLibrary-way is waiting for me.

One more question.
As I found, GFL SDK 3.40 has no libgfl.lib for Borland compiler, only for MS. I used 2.90 and failed to update to 3.40.
Dear Developers, could you make а new Borland lib?

Hello.
I'm workng with CodeBlocks on Windows, using GCC (MinGW).
Is there a proper GFL for it? Where can I download it? And what version of GCC is maintained?

thanks

because of the world financial crisis Pierre stuggles against his software overstocking

A-a-a! There are two versions of lib. I didn't pay attantion.
sorry for a stupid question

But what for did you make two VC++ versions, if the unicode version works both with ansi and unicode??

Unicode versions of Load ans Save functions fail both in С++Builder and Visual C++.

This ANSI code works correct:
gflLibraryInit();
GFL_BITMAP* B;
GFL_LOAD_PARAMS LP;
gflGetDefaultLoadParams(&LP);
gflLoadBitmap("C:\\src.bmp",&B,&LP,NULL);

GFL_SAVE_PARAMS SP;
gflGetDefaultSaveParams(&SP ...

VC++2008, libgfl290 :

D:\Program Files\Microsoft Visual Studio 9.0\VC\include\Layer3\libgfl.h(62) : fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory


#if defined(WIN32)
#include <basetsd>

typedef INT8 GFL_INT8;
typedef UINT8 GFL_UINT8;
...
#else
#include ...

> you have special functions to translate this kind of Bitmap

translating needs much time and memory, especially with large images
I don't want to waste resources just copying megabytes

I prefer to use undocumented features and .. .. am ready for future troubles

Thanks for your cooperation :)
The problem is solved! The description is below (if you are interested in)

gflResize works correct when the function uses GFL_BITMAPs with their own data, I mean, GFL_BITMAP::Data points to a memory created with gflAllockBitmap, gflLoadBitmap etc.

But I use GFL ...

>I made a similar mistake writing the same bitmap in Src and Dest.
It's not a mistake. In previous version when gflResize got a pointer to NULL in Dst parametr it created a new GFL_BITMAP object
and now it fails.

>You should write NULL directly to resize in the Src bitmap (written in the help).
I ...

Very unusual behaviour...

the filename parametr in gflSaveBitmap function has char* type - const is missed
could you add const in next version?

the same about gflSaveBitmapW and const wchar_t*

This code worked successfully on 267 version, but it fails on 290: Access violation in module LIBGFL290.DLL