AutoHotkey Community

Do not know if this is a bug, or intended feature, or maybe I am just crazy...

I took a screenshot of a GUI/Graph that I am working with.

I assume people may need some information about the graph, so I made a BMP image with the GUI/graph image inside with some text/edits to highlight key points.

Test code to display the BMP image itself:



If you want to test it, you need to take a screenshot of a GUI. (assuming any standard grey gui). Save the image as a bmp, and store it in the library with the script.

If you test it, you will see that the BMP image itself, which should remain grey (and is grey if you just open the image itself, as opposed to launching it with the script) changes colors.

I made an AHK.net page finally, and put the test script, test image and an example image up.



http://www.autohotkey.net/~carcophan/gd ... xample.bmp
http://www.autohotkey.net/~carcophan/gd ... 20test.ahk
http://www.autohotkey.net/~carcophan/gd ... estGDI.bmp

If you put all three items on your desktop, and run the ahk/hit the button, you will see the child-gui with the testImage, and it will be off color. If you look at the testGDI bmp file, it is grey, but addopts the background color of the chidl-gui that it is being displayed in.

Change the 0xaaffaa to any color, reload script and it will change to the new color.

I see the same thing if a color in the image is 0xf0f0f0.
I used mousegetpos & pixelgetcolor to get the original color of your test image and then tweaked my test image to have a portion of it be that same 0xf0f0f0 color, the background of the gui as well as the portion of the image both turned the same color.

I can't confirm but I believe it might be related to the 'default' color of gui controls. Namely the ahk assembly code saying "hey wait a minute, that is the same color as what a control should be, but the color of controls has been changed, therefore I must change this color to match."

Seems like a bug to me. (one ahker's opinion)

BUG CONFIRMED - XP SP1

I was about to post not confirmed, cuz running your exact test script did not exhibit that behavior, but then I made my own screenshot...& got the buggy behavior...the "magic" color in my case is 0xECD8E9 (RGB)...

Steps to reproduce...

1. Download Test Script: GDI test.ahk (don't need imgs)
2. Make a screenshot of 1st Gui in bmp & png formats
   
   1. Run test script
   2. On the 1st Gui press Alt+Print Screen to take a window-only screenshot
   3. Open MSPaint or some image program & paste the screenshot
   4. Save that screenshot in the scripts dir as testimg.bmp & testimg.png
   5. Close test script
3. Edit test script to point to the bmp version of the test img
   
   1. Find the line: Gui, 2:Add, Picture, , testGDI.bmp
   2. Change it to: Gui, 2:Add, Picture, , testimg.bmp
4. Run test script again & click button...2nd Gui's Picture control should (incorrectly) have the same bgcolor as set on 2nd Gui...
5. Edit test script to use png version & try again, see png version works correctly
6. Edit test script back to the bmp version
7. Add AltSubmit to the Picture control's options, now the bmp version works correctly

...I don't know what causes it, but it's definitely a bug...(but it's a bug with 2 workarounds...1) use png, not bmp...2) use AltSubmit...

Interesting. However,
... it's not GDI+. As Guest pointed out, it doesn't happen if you use AltSubmit. AltSubmit tells it to use GDI+. Using a PNG would have the same effect, since GDI+ is required to load it.

The inner workings of Gui,Color are very simple: when the colour is changed, create a solid brush of the new colour; when a WM_ERASEBKGND message is received, call FillRect using the background brush. It doesn't do much else.

Given that loading the image manually as below exhibits the same problem, I would rule out AutoHotkey's image-loading routine as the cause:
Actually, this is more or less the same as what AutoHotkey does by default (and what I imagine the majority of GDI-based applications would do). As you can see, it only sets the image; actually drawing the image is up to Windows.

It seems vaguely familiar to me, like an obscure Windows "feature". I found that resizing the image put the colour off slightly (f0f0f0 -> efefef) and that prevented it from changing colour. However, if the image was loaded by GDI+, the colour remained f0f0f0.

If I had more time, I'd complete the test: create a Static control via CreateWindowEx, load and set the image as above, and handle WM_ERASEBKGND in script. I suspect it would have the same issue.