This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GrLiib WIDGET_MSG_KEY_UP message

Other Parts Discussed in Thread: EK-TM4C1294XL, BOOSTXL-K350QVG-S1


How & when is WIDGET_MSG_KEY_UP sent to a RectangularButton, as my buttons are staying in the 'Pressed' colour once they have been pushed.

As a simple example, I have two canvasses, each has a single RectangularButton added, and each button has it's own pfnOnClick handler.
I add one Canvas widget to WIDGET_ROOT and paint it.
Whichever canvas is displayed, it's button handler removes it from WIDGET_ROOT, and adds the other Canves,
so you can simply toggle between Canvasses using the botton on each.

But once pressed, each button remains in the colour of the 'Pushed' state. They still work, ie the canvasses change & are painted, but the button colour never 'resets'

I have tried sending the buttons a WIDGET_MSG_KEY_UP in the OnClick handlers using WidgetMessageQueueAdd() but with no success.

So how/when does the button widget get a WIDGET_MSG_KEY_UP usually?
Is it the case that once the canvas is removed from WIDGET_ROOT it's widget tree will not process messages? Or discard them even?

I'll keep trying but any help would be appreciated.

Regards,
Tony Hanratty

  • May I respond & note yours as a, "terrific" posting?   Nicely introduced (but for *) - sequential - and highly detailed.  

    Unfortunately my firm is in the display biz - we've not employed this vendor's graphic library - preferring our (pre-existing own.)

    Perhaps logic & reason may compensate for, "Zero experience?"

    • Might your (more) extensive search uncover a "Graphic example" which overlaps your requirement?
    • Absent that - there must appear "set-up code" which introduces your "RectangularButton" in the initial (Unpressed) state.   By examining that code (assumed available) and contrasting it w/your button's "pressed" state - a solution should dawn
    • It (almost) appears that you seek a form of, "one-shot" button "color" or operation.   The effect you note signals that the button has latched - does it not?

    The appeal of this vendor's graphic library is the richness of functions.   Most always - such "richness" leads to issues such as yours - which challenge the tech team to provide full/complete operating details - while marketing (screams) "You are LATE!"    (not to ask - HOW I know...)

    Bon chance, mon ami.   

    *   "How/when" - off the bat - is bit too "courtroom" demanding when seeking (free) tech support...   (I'd soften w/ "May I ask, How & When...")

  • Hello Tony,

    Can you please share the CCS project for us to check the issue as well? I hope it is using the DK-TM4C129x

    Regards
    Amit

  • Hi Amit.

    I've stripped the code down to it's bare bones and attached the zipped project folder.

    There is a hard coded path in Project Properties->Compiler->Include Options
    Set this to your TivaWare base folder. Currently it's set to: "T:\TI\TivaWare_C_Series-2.1.2.111"

    I've included the prebuilt grlib and driverlib libraries I've been using in the Libs folder.

    I ported the touch screen and LCD driver from an MSP devkit install and converted them to use the Tiva C DriverLib
    and that all seems to be working OK. I did this because the MSP LCD example uses an SPI interface to the SSD2119 controller,
    but the LCD example in the Tiva C 2.1.2.111 release uses an 8 bit GPIO interface. Not what I wanted.

    Also note, I have the LCD on the BoosterPack 2 interface on the EK-TM4C1294XL card.
    And I've set stack & heap sizes to 4k, more than enough.

    Anyway, the behaviour is as I've described in my earlier post.


    Many thanks,
    Tony.
    GrLib-Widget-Problem.zip

  • Hello Tony,

    Thanks for the project files. I am looking into it. Please note that it is BP1 and not BP2 header where it works.

    Regards
    Amit
  • Hello Tony,

    The widget is being removed when the press happens and hence the detection of the Key up does not clear the Style of the button. You can modify the code to change the button style as PB_STYLE_RELEASE_NOTIFY

    RectangularButton( g_btnToggle_1_To_2,
    0, 0, 0,
    &g_sKentec320x240x16_SSD2119,
    LCD_HORIZONTAL_MAX/5, LCD_VERTICAL_MAX/2,
    LCD_HORIZONTAL_MAX*3/5, 27,
    PB_STYLE_FILL | PB_STYLE_OUTLINE | PB_STYLE_TEXT | PB_STYLE_RELEASE_NOTIFY,
    ClrLightSteelBlue, ClrDarkBlue, ClrWhite, ClrWhite,
    &g_sFontCmsc18, "Switch To canvas 2", NULL, NULL,
    0, 0,
    OnButtonClick );


    RectangularButton( g_btnToggle_2_To_1,
    0, 0, 0,
    &g_sKentec320x240x16_SSD2119,
    LCD_HORIZONTAL_MAX/5, LCD_VERTICAL_MAX/2,
    LCD_HORIZONTAL_MAX*3/5, 27,
    PB_STYLE_FILL | PB_STYLE_OUTLINE | PB_STYLE_TEXT | PB_STYLE_RELEASE_NOTIFY,
    ClrLightSteelBlue, ClrDarkBlue, ClrWhite, ClrWhite,
    &g_sFontCmsc18, "Switch To canvas 1", NULL, NULL,
    0, 0,
    OnButtonClick );


    Regards
    Amit

  • Hi Amit.

    I had tried the PB_STYLE_RELEASE_NOTIFY flag but this didn't give me the button behaviour I was desired.
    I want the button to have an 'action on press' response, not 'action on release'.

    Further investigation shows that the widget manager uses the variable g_psPointerWidget to track
    which button currently has the pointer focus. If that widget subsequently disappears from the tree,
    this variable is cleared. So my button will never see the WIDGET_MSG_PTR_UP message, and therefore
    remains in the pressed state.

    So the simplest way to get the 'action on press' behaviour is to clear the button's internal state flag
    in my OnButtonClick handler:

        if (psWidget == (tWidget*) &g_btnToggle_1_To_2)
        {
            // Remove canvas 1 from WIDGET_ROOT and add canvas 2
            WidgetRemove( (tWidget*) &g_MenuCanvas_1 );
            WidgetAdd( WIDGET_ROOT, (tWidget*) &g_MenuCanvas_2 );

            // Clear the button's pressed flag        
            g_btnToggle_1_To_2.ui32Style  &= ~PB_STYLE_PRESSED;
        }

        ... etc
        
        
    I think I'll run with this solution.
    Thanks for all your help.
        
    Cheers,
    Tony.

  • Hello Tony,

    While the solution will work, notify on release would be a better solution. The reason is because if you press the button and decide not to move to the next widget, it will allow you to slide out of the box and then release it.

    However it's your application and in that context the solution you deem more appropriate should be the solution.

    Regards
    Amit
  • Hello Tony,

    I did notice that touch.c is different from the TivaWare one that I have for ek-tm4c1294xl for the L35 panel booster pack. Anyways, as an update the next TivaWare release would have the BOOSTXL-K350QVG-S1 for both the TM4C123 and TM4C1294 launch pad

    Regards
    Amit
  • Good to know - I'll keep an eye out for the update.