I'm using Expression Blend 3 and writing some of the XAML by hand, specifically the color values of controls.
I have a list of RGB colors already converted to hexadecimal. I just need to insert the hex value into my XAML.
Initially, I pasted the hex value from an email into the appropriate properties. Before I could finish, Blend started having a fit, underlining the color property with a squiggle and a tooltip telling me "Token is not valid." After some research, I found placing a pound sign ("#") in front of the hex value resolved this issue.
In the process of researching this problem, I started chaning colors via the color picker in Blend. I quickly found the values Blend was inserting not only started with the pound sign but also "FF". The values I was pasting were valid colors in valid hex format. But when entering the RGB values into Blend and letting Blend insert the hex value, I noticed all mycolors were prefixed with "#FF". Removing the #, as i already pointed out, generated errors but removing the "FF" seamed to have no effect at all.
In the world of hexadecimal colors, is the color #5A7F39 really the same as #FF5A7F39 ? Why the FF ? They are two different hex values, right? But appear identical onscreen. Why the difference?
That may be the alpha component of the color, which represents the opacity (00 -> transparent, FF -> opaque).
MSDN seems to agree with this : http://msdn.microsoft.com/en-us/library/bb980062(VS.95).aspx
16-bit hexadecimal, alpha -- #AARRGGBB
I believe the leading FF is the Alpha. 255 (or FF) being 100% opaque, and 00 would be transparent.
the 'extra' ff is an alpha value (degree of transparency). If you only have 3 hex pairs, the alpha value is assumed to be ff (no transparency). However, if you compare #335A7F39 and #FF5A7F39 you should see a difference
来源：https://stackoverflow.com/questions/1484834/why-the-leading-ff-in-hexadecimal-color-values