Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION
Posted: 10 May 2019, 09:26
Recently when testing some old scripts of mine under Win10 x64 I noticed a couple of them were displaying their "skins" in color chunks instead of gradient as it always was the case from Win98SE to at least Win7. After some debugging I found out that the CopyImage() API was the culprit.
In fact it's the LR_CREATEDIBSECTION flag (value of 0x2000) that seems to behave in reverse. The function I use to stretch an ImageList bitmap from 2x5px to 140x36px uses a value of 0x2008 for the flags (LR_CREATEDIBSECTION | LR_COPYDELETEORG) and it has worked fine as mentioned above, however in Win10 CopyImage() fails to create the gradient when stretching if the LR_CREATEDIBSECTION flag is present.
Unfortunately, omitting that flag would make the bitmap "chunky" in all other Windows versions (tested only on XP SP3 so far but I'm pretty sure it would be the same on all older OSes). So, to me it appears that the functionality of the said flag - at least in conjunction with CopyImage() - has been (erroneously or on purpose?) reversed in Win10, maybe even in Win8.x.
I'd appreciate if anyone else had the time and will to test this and confirm (or not) my finding, or maybe it has already been found by someone else. It could be of help for fixing old AHK scripts that use CopyImage(), for Win10 compatibility, unless someone asks/reports the issue directly to Microsoft (if it indeed is a bug). Thank you.
In fact it's the LR_CREATEDIBSECTION flag (value of 0x2000) that seems to behave in reverse. The function I use to stretch an ImageList bitmap from 2x5px to 140x36px uses a value of 0x2008 for the flags (LR_CREATEDIBSECTION | LR_COPYDELETEORG) and it has worked fine as mentioned above, however in Win10 CopyImage() fails to create the gradient when stretching if the LR_CREATEDIBSECTION flag is present.
Unfortunately, omitting that flag would make the bitmap "chunky" in all other Windows versions (tested only on XP SP3 so far but I'm pretty sure it would be the same on all older OSes). So, to me it appears that the functionality of the said flag - at least in conjunction with CopyImage() - has been (erroneously or on purpose?) reversed in Win10, maybe even in Win8.x.
I'd appreciate if anyone else had the time and will to test this and confirm (or not) my finding, or maybe it has already been found by someone else. It could be of help for fixing old AHK scripts that use CopyImage(), for Win10 compatibility, unless someone asks/reports the issue directly to Microsoft (if it indeed is a bug). Thank you.