Animated gifs

[KenDown]

I looked up the Wiki and the procedure given there for displaying animated gifs using the GDIPLIB works just fine - in the main window (@hwnd%). However I want to display the gif in an alternative window (MULTIWIN). There are two places where @hwnd% is referenced, but changing them to handle of the alternative window does not work.


Am I missing something?


Thanks.

[guest]

Am I missing something?

I don't think it's something I've ever tried, but the DC to which GDIPLIB renders its output is set in PROC_gdipinit so either you must call that routine after selecting the required window, or you must override the initial selection by subsequently calling FN_gdipsetdc() (the latter method would be necessary if you are wanting to output to multiple windows).

[KenDown]

Thanks. Annoyingly, that particular FN is not listed in the list of functions and procedures in the Help file. Having looked at the actual library, it would appear that the parameter should be the handle of the window you are wanting to use but it is not clear to me what I should do with the value returned by the function. I tried substituting it for the window handle and all I got was a dramatic crash.

Sorry to be so dim.

[guest]

Having looked at the actual library, it would appear that the parameter should be the handle of the window you are wanting to use

The function name is FN_gdipsetdc which might, I would have hoped, have indicated to you that it is expecting to receive a DC not a window handle. I also stated in my earlier reply that "the DC to which GDIPLIB renders its output is set...". Anyway, for clarity, FN_gdipsetdc takes as its parameter the (handle to the) DC to which you want it to render its graphics output, as is normal for graphics functions. It is not very surprising that if you supply a window handle it crashes!

In general (sorry if this is something you are already familiar with, but not everybody may be) it is much more flexible to specify a DC as the destination for any kind of graphics output because, for example, you may be wanting to render the graphics to an off-screen bitmap that is not related to a specific window. Consider David Williams' GFXLIB library which renders everything to an intermediate memory DC before ultimately 'blitting' it to the output window. Or perhaps you might be wanting to save the graphics as a BMP or PNG file, in which case a window need not be involved at all.

Pretty much the only reference to a window handle that you are likely to encounter when outputting graphics is in the InvalidateRect API function. This tells Windows which region of a window needs to be updated, so unlike the rendering functions it really is associated with a window rather than a DC.

[KenDown]

Please don't worry about "talking down" to me! I need all the talking down I can get.

Anyway, thanks to your kind help I now have the animated gifs working properly and can even increase the size by a specified parameter. This was necessary because the gif I wanted to use was pretty small and if used at the original size occupied a small box in the centre of the screen and people at the back of the hall would not have been able to see what was going on.

Incidentally, I didn't manage to get the undocumented FN_gdipdcset function working, but I moved the init function to after the output screen is created (which means that I can't get the animated gifs working in either of the other screens, but I can live with that.)

Many thanks for your help.

[guest]

Incidentally, I didn't manage to get the undocumented FN_gdipdcset function working

I suspect I've never used it myself, so it is possible that it has never worked.

If you, or somebody else, can confirm that it's broken I will make a note in case GDIPLIB is ever updated, but at the moment I have no plans to re-visit BB4W or its libraries. It's unfortunate that BBCSDL, on which all my current (albeit limited) efforts are expended, has no similar capabilities but neither SDL2 itself, nor any third-party libraries that I know of, provide support for antialiased graphics. I hope that this may be resolved at some future point - it's one of only a few serious weaknesses of SDL - but even if so it will probably come too late for me to take advantage of it.