Thanks for your reply! It does almost make sense.
The only thing I'm confused about is why I'm seeing different results now - I am using OS X and if they were already ARGB on OS X, and the new function ensures they return ARGB, then why would it be different?
To give a little more detail, I have been storing colours as ValueTree properties by storing them as ints, casting the argb uint32 in a similar way to:
settingsTree.setProperty(MyClass::Ids::buttonColour, (int)c.getARGB(), nullptr);
where settingsTree is a ValueTree. I don't know another way of doing this except casting to int...
I then later retrieve the colour similarly to:
int x = settingsTree.getProperty(MyClass::Ids::buttonColour);
uint32 colour = (uint32) x;
This has always worked fine (though all the casting does smell bad - I didn't know how else to store the colour on the ValueTree and save to XML). The changes to the Colour and PixelARGB class have now made the retrieval of previously saved colours (using the old version of getARGB() ) not work, as things seem to be out of order.
So, in short, two questions...
1. Why would the changes have started producing a different result to what was happening before if I was using OS X and not Android?
2. Is there a better way to save colours on the ValueTree (and dump to XML) than my slightly icky casting to int? I can't convert from a uint32 to a var for storing on the ValueTree.