Screen Flow actions silently failing in gx_studio_auto_event_handler()

[parsley]

Describe the bug
Return values of the following functions are silently ignored within Screen Flow action handler gx_studio_auto_event_handler():

• gx_system_screen_stack_push()
• gx_system_screen_stack_pop()
• gx_system_screen_stack_get()
• gx_system_screen_stack_reset()
• gx_widget_attach()
• gx_widget_detach()
• gx_widget_delete()
• gx_widget_show()
• gx_widget_hide()
• gx_window_execute()

Please also mention any information which could help others to understand the problem you're facing:

Two examples:

1. Once I reached the limit of my screen_stack I got unexpected behavior of Screen Flow actions that use gx_system_screen_stack_push().
2. I tried to attach a runtime_allocated widget to a runtime allocated screen: In Screen Flow I added a trigger to the runtime_allocated screen and added an action of type Attach with target being the runtime_allocated widget and parent being the runtime allocated_screen itself. This didn't work with no hint to the reason why. (I later found out that Attach with Screen Flow only works if the parent is NOT runtime allocated. 🙁 Would be nice to have at least some way to use "myself" as parent on runtime_allocated screens/widgets.)

These are just two examples where it took too long to identify the circumstances.

• What target device are you using? STM32G0
• Which version of Eclipse ThreadX? GUIX v6.5.1.202602a with custom binding to FreeRTOS.
• What toolchain and environment? IAR
• What have you tried to diagnose or workaround this issue? Breakpoints and single stepping through the GUIX library.

To Reproduce
Steps to reproduce the behavior:

1. issue:

• Use gx_system_screen_stack_create() to set a screen_stack with a size of 1 and then
• use Screen Flow actions to push more than one screen to the stack. -> Nothing happens and you wonder why.

2. issue:

• In GUIX Studio create a screen "screen_1" that is the size of your LCD and tick "Runtime Allocate".
• Configure a second screen "content_for_screen_1" that is a bit smaller and is meant to become part of the content on screen_1 at runtime. Tick "Runtime Allocate" for this, too.
• In Screen Flow go to screen_1 and add a custom trigger "trigger_1".
• On trigger_1 add an Attach action with Target = content_for_screen_1 and Parent = screen_1.
• Run this GUI and send the trigger_1 event from screen_1. -> Nothing happens and you wonder why.

To escalate issue 1. even further:

• Configure a single Screen Flow trigger that contains two actions:
  1. Screen Stack Push "yourself" ( == the screen this trigger and action belongs to).
  2. Attach a new screen.
     Once the screen_stack is full this contraption will attach the new screen but will not detach the old screen since it was unable to push it to the stack. (I've made a feature request (Screen Flow: Add "stack_push + attach" to toggle action #185) that would not solve the failing push but reduce the impact of this "contraption" by only attaching the new screen if the stack push was successful.)

Expected behavior
A clear and concise description of what you expected to happen.

I guess there are a few different options for this. One solution (to ease development) might be to add something like

#ifndef ASSERT_GUIX_STUDIO
#define ASSERT_GUIX_STUDIO(x)
#endif

to the GUIX Studio generated specifications.c file and within gx_studio_auto_event_handler() put ASSERT_GUIX_STUDIO(status == GX_SUCCESS) after each call of either of those functions listed above with 'status' being the return value of each function.

Another solution (to also capture these issues at runtime) might be to add calls for some optional hook-function (to be implemented by the application) that gets called instead of the ASSERT macro. It could report the failed action to the application together with *widget, *parent and *target and ideally also enable the application to optionally abort or alter a multi-action Screen Flow operation.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Issue 1: In my project the UI will be rather static so I can just increase the screen_stack size to fit. But if a project would dynamically generate the structure and navigation depth of its UI this issue be a serious risk. It might even impact security.

Issue 2: Is a major annoyance because now I have to make all those screens static whose content I want to alter at runtime using Screen Flow trigger&action features.