Fixed Screen Flow code generation with GX_ANIMATION_POOL_SIZE = 0

[fdesbiens]

Fixes #172

Problem

GUIX Studio emits five static helper functions in the generated specification file as soon as a project uses Screen Flow. Two of them, gx_studio_action_parent_find() and gx_studio_animation_execute(), are reachable only from the GX_ACTION_TYPE_ANIMATION handler and reference the GUIX animation API, which is compiled out when the animation pool is empty:

• gx_system_animation_get() is only defined under #if (GX_ANIMATION_POOL_SIZE > 0) in gx_api.h.
• The body of _gx_animation_start() is guarded the same way in gx_animation_start.c, so the reference does not resolve at link time either.

A project that defines GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore fails to build, even when it uses no animation action at all.

Reproduced on system_screen_stack_specifications.c with GX_ANIMATION_POOL_SIZE 0:

error C4013: 'gx_system_animation_get' undefined; assuming extern returning int
UNDEF External | _gxe_animation_start        <- LNK2019 at link time
UNDEF External | gx_system_animation_get

GCC 14, the default compiler for the project, rejects the implicit declaration outright rather than warning about it.

Fix

screen_generator.cpp now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites (the <= 50402 and the current library version branches) in #if (GX_ANIMATION_POOL_SIZE > 0). Every other action type keeps working with an empty pool, and an animation action simply becomes a no-op at runtime.

The generator also emits forward prototypes for the four static Screen Flow helpers, which addresses the secondary request in the issue. Note that MISRA C:2012 Rule 8.1 covers explicitly specified types and Rule 8.4 applies to objects and functions with external linkage, so the static helpers without a visible prototype were not a deviation. The prototypes are still worth having, and they match the declaration the generator already emits for gx_studio_nested_widget_create().

Generated files

All 30 checked-in generated *_specifications.c files were re-synced with the generator, including the three golden files of the Studio view test.

Verified with test_demo/test_main.py -t across all 227 Studio projects: 227 passed, 0 failed, so the updated files match generator output exactly.

Regression test

test/guix_studio_test/test_demo/test_animation_pool_size.py, registered in the demo_compile CTest project so the existing GUIX Studio Demo Compile Test workflow runs it:

1. Source check — the two helper definitions and the case label must sit inside the guard. Rejects "prototypes only guarded", "definitions unguarded", "case unguarded" and the pre-fix shape.
2. Compile check — compiles every Screen Flow specification file with GX_ANIMATION_POOL_SIZE 0 and /we4013, so the implicit declaration is an error rather than a warning.

Results on this branch: 27 source-checked, 25 compiled, all passing in about 7 seconds under ctest. Against the pre-fix tree the same test fails 27/28 source checks and 24/26 compiles.

all_widgets_5_4_0 and all_widgets_5_4_1 are excluded from the compile stage because their generated code targets a pre-5.4.2 widget API; the existing demo compile test skips them for the same reason. They are still covered by the source check.

Documentation

Matching documentation update: eclipse-threadx/rtos-docs-asciidoc#42

🤖 Generated with Claude Code

---

Hotfix release preparation

This PR also carries the version bump for the emergency hotfix release that ships the fix, 6.5.1.202602a.

Release tooling

The tooling could not express a hotfix version at all, so it was fixed first:

• Get-StudioReleaseVersion rejected anything that was not major.minor.patch.build, and update_studio_release_version.ps1 hard-coded GUIX_HOTFIX_VERSION as ' '. The documented path to build a hotfix installer was unusable, and running the script after a manual edit would have reset the hotfix constant.
• prepare_release.sh searched only ports/ for gx_port.h, so it never updated the version string of the GUIX Studio Win32 port in guix_studio/ports/gx_port.h.

Get-StudioReleaseVersion now accepts an optional trailing hotfix letter and exposes it as Hotfix / HotfixDefine. The Win32 and MSIX version formats are strictly numeric and cannot carry the letter, so the revision is offset by the position of the letter in the alphabet instead:

Input	FullVersion	Win32	MSIX	RC numeric	Hotfix
6.5.1.202602	6.5.1.202602	6.5.1.2	6.5.1.02	6,5,1,2	' '
6.5.1.202602a	6.5.1.202602a	6.5.1.3	6.5.1.03	6,5,1,3	'a'
6.5.1.202602b	6.5.1.202602b	6.5.1.4	6.5.1.04	6,5,1,4	'b'

That keeps the hotfix installer recognizable as the newer build for Windows upgrade detection and for the Store. Versions without a hotfix letter resolve exactly as before, and 6.5.1, 6.5.1.202602A, 6.5.1.202602ab and 6.5.1.202602-a are all still rejected.

Version constants

Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a, plus the port strings:

• common/inc/gx_api.h — GUIX_HOTFIX_VERSION 'a'. Major, minor, patch, build and the 6.5.1 banner are unchanged.
• guix_studio/studiox.rc — FileVersion / ProductVersion strings 6.5.1.202602a; FILEVERSION / PRODUCTVERSION 6,5,1,3.
• guix_studio/installer/guix_installer_release.iss — StudioFullVersion "6.5.1.202602a", StudioVersionInfoVersion "6.5.1.3", so the installer is named guix_studio_setup_version_6.5.1.202602a.exe.
• guix_studio/build/vs_2022/msix_package_project/Package.appxmanifest — MSIX identity 6.5.1.03.
• All 47 gx_port.h files, including guix_studio/ports/gx_port.h.

STUDIOX_VERSION_NUMBER deliberately stays at 202602: it stamps the Studio version into .gxp project files, and a hotfix does not change the project file format.

Verified against a rebuilt guix_studio.exe, which reports FileVersion 6.5.1.202602a with a numeric file version of 6.5.1.3 — what verify_studio_installer.ps1 checks.

README.md still points at the current 6.5.1.202602 download, since the v6.5.1.202602a_rel tag and its asset do not exist yet. It should be updated when the release is published.

Re-verified after the bump

• test_animation_pool_size.py: 27 source-checked, 25 compiled, 0 failures.
• test_main.py -t: 227 projects, 227 passed, 0 failed.

[fdesbiens]

@parsley This PR should fix your issue. I need to prepare a new installer and release. This should be done tomorrow (Wednesday).