Setting colour on Xojo

On the old RS IDE, i used to be able to copy the code for the colour and then paste it on the control i want but on the new Xojo IDE, i need to keep selecting colour from the pop up.

Wish i can do the old way along with the new way.

I noticed that right away… It’s something I tended to do that often in RS.

It is very hard to select a specific color using a picker … Yes you can set color in code but when doing layout that is not very WYSIWYG.

I agree that we need able to either use the picker or type (paste) in the hex value.

  • Karen

i realise i can drag the colour i want to the bottom of the colour picker and then simply select the colour i want from there instead of going to the part on the top.

While certainly not a solution, there’s a neat color picker from Panic that works on OS X. See Developer Color Picker 1.5 for a description and link to the download page.

How did this color picker be use in Xojo?

There’s instructions with in the download on how to install it and where it shows up. An alternative is Hex Color Picker if you really want to input hex.

that joe, will check those 2 out

just try it out… i install both… it work very well…

The new Inspector really is a step backwards in functionality. We use constants for our colors ALL the time.

I wonder why the decision was made to only allow color entry via a picker in the inspector. Anybody at Xojo care to comment?

i agree fully with you , bob… but i can used code to the the sidebar on my application to set to the colour i want… but during design, you can’t really see the colour which is a pain.

BRING BACK THE COLOUR TEXTBOX!!!

While I agree that the current inspector could do with a lot of usability improvements, setting colors in the property list has been working bad for ages now, way before Xojo. For this specific example at least to me the new inspector is a lesser problem, since the property list itself has been broken for a long time:

feedback://showreport?report_id=22336

[quote=9828:@Eduardo Gutierrez de Oliveira]While I agree that the current inspector could do with a lot of usability improvements, setting colors in the property list has been working bad for ages now, way before Xojo. For this specific example at least to me the new inspector is a lesser problem, since the property list itself has been broken for a long time:

feedback://showreport?report_id=22336[/quote]

It seems that is only an issue if you have a non 0 alpha. As the alpha seemed not to have an effect one the displayed color, I have not been using it in the property list in RS so never noticed the issue.

Yes that bug needs to be fixed for sure, but In any case we need to have both ways to enter a color in the inspector as we did before.

The Alpha is translated to high bits and it’s the only way to have a color with or without alpha
So &cRRGGBB -> &hRRGGBB
while &cRRGGBBAA -> &hAARRGGBB

So the classic translation from string to color via variant (or similar tricks):
string="&cRRGGBB"
variant=string.replace(“c”,“h”).val
color=variant.colorValue
will not work with alpha.

This is not a xojo bug . This behavior exists since the first color with alpha.

Nope. Happens to all colors defined in the property list of the IDE for binary format. Most likely an artifact of the save routine, as it only happens when reloading a project saved since the last time it was opened.

Of course. But since using colors in the inspector is as broken as it is in the property list before that for the binary format, to me they’re co-dependent, not separate.

Agreed. And was called on that by Geoff. Not sure if I should raise a new ticket but I’ve added a note to mention that it happens in Xojo as well.

Yeah, it’s more of an unfortunate design decision.

The color -> string code that existed prior to alpha channels just worked by casting the color to an int and formatting it as hex. When colors got an alpha component, the thought was that changing it from a hex literal to a color literal could break code so we stuck with the current system. In retrospect, I don’t think much code would have been broken by just spitting it out as a proper color literal.

Here’s a couple of routines that sort this for us:

[code]Function ColorToLiteralString(c as Color, altcolor as color=&c00000000) As String
// yet another work-around: convert color to string using normal str(color) and then convert to color literal (with alpha in the correct place)
// (see also: ColorStringToColor)
dim cc as Color=c

if IsNull(cc) then
cc=altcolor
end

// str(cc) emits &h and puts alpha in high-bytes, but literal requires &c and alpha in low bits…go figure
dim s as String=str(cc)

return “&c”+mid(s,5)+mid(s,3,2)

End Function
[/code]

[code]Function ColorStringToColor(s as string, altcolor as color=&c00000000) As Color
// return color or an alternate from a color literal string (see also: ColorToLiteralString)
dim ss as Variant=s

if IsNull(ss) or ss.StringValue.LenB <> 10 then
// if it’s not a correct length or is null then use altcolor
ss=str(altcolor)
end

// quick fix in case function called with str(color) or we need to use altcolor instead of a properly formed color literal
if left(ss.StringValue,2)="&h" then
ss="&c"+mid(ss.StringValue,5)+mid(ss.StringValue,3,2)
end

return ss.ColorValue

End Function
[/code]

Hope it helps.