Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MPW691]

Hi, this probably a simple question to many but I couldn't find the answer in the FT81X Programmers guide so thought I would ask here.

I am able to set the colour of the button with the 'CMD_FGCOLOR', however, while the button is pressed it reverts back to the default colour(dark blue). I Initially thought that CMD_BGCOLOR would set the press colour, but it turns out that's not the case, and looking at the manual (section 5.2.2) it clearly stated CMD_BGCOLOR is not used.

So my question is simple: How do I set the button colour for when it is pressed?

Thanks!

[Rudolph]

This must be an issue in your code since the foreground color is one of the persistent variables.
You do not even need to re-set it every frame and changing a button from default to opt_flat does not change it.
See chapter 5.7 Graphics State

You either have a CMD_FGCOLOR or CMD_COLDSTART in your display list.

[BRT Community]

Hi,

Which method do you use to indicate if the button is pressed or not? One way is to set the 3D option when not pressed and to make it flat when pressed in. As Rudolph mentioned, this should not cause the colour to change however,

Could you post a small command list which shows how you display and refresh the button?

Best Regards, BRT Community

[MPW691]

Hi All,

Thank you for the fast response, I didn't initially realise that the button press colour change was done within our code instead of the EVE.

The idea about using the OPT_FLAT is a good one which we already use for 3D buttons, but the buttons I am drawing are always drawn flat (in my opinion they look smarter), so colour-change is needed to signify the difference between pressed and not pressed. I went back through the code and found that when we define a button, we add the following to the display list:

Code: [Select]

#define FGCOLOR 0x003870
#define BGCOLOR 0x002040

#define GUI_BUTTON(tag,x,y,w,h,font,flat,str)                             \
{                                                \
    bool pressed = ((tag) == current_tag);           \
    uint16_t toggle_flat = (pressed ? FT_OPT_FLAT : 0);  \
    if (pressed) ft_cpcmd_fgcolor(avgcolour(FGCOLOR, BGCOLOR)); \
    ft_cpcmd(FT_DL_TAG(tag));                    \
    ft_cpcmd_button(x, y, w, h, font, (flat == 1 ? FT_OPT_FLAT : toggle_flat), str);
    if (pressed) ft_cpcmd_fgcolor(FGCOLOR); \
}

As you can see, the issue is that the FG_COLOR (and BG_COLOR) is hardcoded for these items. I was getting lucky by calling the 'ft_cpcmd_fgcolor' command in my main display list, which is setting the colour on the EVE and when not pressed this structure/function is not adding any additional colour commands to the display list. However, when it is being pressed, the redraw over-rides any colour changes I make and auto-sets it to an average of the FG and BG colours, which is what causes the issue.

If I add an intermediate function for setting FG colour that sets the value locally (and change from a constant to a global variable) and then call the ft_cpcmd_fgcolor function with that colour then it will probably work.

Thanks for all your help guys, sometimes you just need someone to point out your own mistakes! Great community, keep it up

[MPW691]

I do have one further question though. Is it possible to read out what the FG and BG values are currently set to in co-processor? I know if I call a cmd_coldstart then they revert back to default values, but since I can change that value via the cmd_FG_COLOR, it might be helpful to read out the current state. Is there a specific address where that value is stored?

[Rudolph]

While I am not aware of a method to retreive these values, wouldn't it be easier and quicker
to store these values with every command in a global structure on the host controller as well?

[BRT Community]

Hi,

Yes, it is recommended to keep your own graphics states in a structure for example and you can then update and read the values there throughout the rest of your application. Your calls to set FG colour etc can then use the values from your structure. This will make the code easier to maintain too and also means you can check the value without a SPI access. I'm afraid you are not able to read the values back but we find the structure to be a good way.

Best Regards, BRT Community

[MPW691]

Makes sense, it was more for a sanity checking function to ensure the structure had been updated correctly when debugging any issues, but if it's not possible then it doesn't change anything.

Thanks for the help everyone!