Bug Report - Designer code missing #include (4.10.0)

[brianshankland9]

When I added interactions to my container the compiler failed stating it did not know what an AbstractButton was.

When I manually added a #include for "touchgfx/widgets/buttons.hpp" using Visual Studio the fault was fixed.

It is a small project so I can zip it up and email if you tell me who to.

[brianshankland9]

I assume by the lack of reply from anyone at ST that they don't care their product can not even do the simplest of GUI tasks as have a button in a container of grouped widgets and allow it to be clicked!

Tried a new project just to be sure and yes as soon as you put a click interaction on a flexbutton that is in a container, the designer generated code that will not compile until you manually add

#include <touchgfx/widgets/Button.hpp> to the gui_generated base class for the container.

Since every time you amend the project this is rewritten you have to fix this every time you want to run your code.

Big fault to have let through to release so when is it going to be fixed?

[Martin KJELDSEN]

Hi @brianshankland9​,

I'm the only one monitoring this TouchGFX community and i've been traveling (Embedded World). Sorry you had to wait so long. Which version of TouchGFX are you using?

[brianshankland9]

Hello Martin, Thanks for the feedback, I look forward to the V4.11 release. I apologise for my tone, I thought there would have been a larger team on this at ST since it will effectively let you corner the MCU display app market, but now understand your situation. I saw that there were trade shows on this recently (but too late to attend). We are heavily involved with Keil’s MDK for our product development which requires the use of their CMSIS-RTOS wrapper for their middleware. I saw that your projects provide an OSWrapper for cmsis but have struggled to get this to work with either their RTX or FreeRTOS library (the letter I think is a problem with their latest V10.0.1 since it crashes their own blinky examples). The RTX “works�? in that I see that framebuffers are being refreshed (disco leds) but the screen is corrupted (looks like its is zoomed in 4x and repeated) I don’t have this issue with the RTX threads is I use your NoRTOS OSWrapper example. Not sure if this is an timing issue with the semephores/queues in RTX or not. I was wondering if it is safe to use the NoRTOS OSSwappers if I’m not planning to access the frame buffer from any other thread than your GUI thread, and simply use the CMSIS-RTOS to create you a separate thread to run? Can start a new discussion thread if you think that best. regards _________________________________________________­_ Brian Shankland Icon Research Ltd 3 Raw Holdings | East Calder | West Lothian | EH53 0HY | UK T: [phone] Ext 226 F: [phone] www.iconresearch.co.uk<>

[Martin KJELDSEN]

I've verified that this is an issue in 4.10.0 and i'll pass it on to the Designer Team. Thanks for reporting it! There's a possibility that this has already been fixed in 4.11.0 which will be out soon (it's done - I will test this)

And yes, the files in gui_generated will get overwritten ever time the designer generates new code.

I apologize for the inconvenience!

Thanks!

Best regards,

Martin

[Martin KJELDSEN]

This is not a problem in version 4.11.0 so we've already fixed it - Release is pending CubeMX / Cube Firmware release dates. Will keep this community updated on the release of course.

(Other things in 4.11.0 - 8-bit, Thai support, Dynamic Fonts and Translations, ...)