Fixed Screen Flow code generation with GX_ANIMATION_POOL_SIZE = 0 by fdesbiens · Pull Request #173 · eclipse-threadx/guix

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T14:54:49Z

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:

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.
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 / PRODUCTVERSION6,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.

GUIX Studio emitted five static helper functions in the generated specification file as soon as a project used 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 defined GX_ANIMATION_POOL_SIZE as 0 in gx_user.h to save resources therefore failed to build even when it used no animation action at all. GCC 14 rejects the implicit declaration outright, and MSVC fails on the unresolved external. The screen generator now wraps both helpers and the two GX_ACTION_TYPE_ANIMATION dispatch sites 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 static helpers without a visible prototype were not a deviation. The prototypes are still worth having and match the declaration the generator already emits for gx_studio_nested_widget_create(). All the checked-in generated specification files were regenerated so that they stay in sync with the generator, including the golden files of the Studio view test. Added test/guix_studio_test/test_demo/test_animation_pool_size.py as a regression test, registered in the demo compile CTest project. It verifies that every checked-in Screen Flow specification file guards the animation helpers, then compiles them all with GX_ANIMATION_POOL_SIZE set to 0, promoting the MSVC implicit declaration warning to an error so the failure mode above is caught. Fixeseclipse-threadx#172 Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release tooling could not express a hotfix version. Two gaps: - 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 therefore unusable, and running the script after a manual edit would have reset the hotfix constant. - prepare_release.sh looked for gx_port.h under ports only, 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 and 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: 6.5.1.202602 keeps revision 2, and 6.5.1.202602a becomes revision 3. 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. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Prepares the emergency hotfix release that carries the Screen Flow fix for GX_ANIMATION_POOL_SIZE = 0. Produced by scripts/update_studio_release_version.ps1 -Version 6.5.1.202602a: - gx_api.h: GUIX_HOTFIX_VERSION is now 'a'. The major, minor, patch and build constants are unchanged, as is the 6.5.1 banner. - studiox.rc: FileVersion and ProductVersion strings are 6.5.1.202602a, FILEVERSION and PRODUCTVERSION are 6,5,1,3. - guix_installer_release.iss: StudioFullVersion is 6.5.1.202602a and StudioVersionInfoVersion is 6.5.1.3, so the installer is named guix_studio_setup_version_6.5.1.202602a.exe. - Package.appxmanifest: the MSIX identity version is 6.5.1.03. STUDIOX_VERSION_NUMBER 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, matching what verify_studio_installer.ps1 expects. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Updated the _gx_version_id string in all 47 gx_port.h files for the emergency hotfix release, using the same substitution that prepare_release.sh performs. This includes guix_studio/ports/gx_port.h, the GUIX Studio Win32 port, which the release script previously missed because it only searched the ports directory. That gap is fixed in the preceding commit, so a future release picks the file up automatically. Assisted-by: Claude Code (Opus 5) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-25T21:22:26Z

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

compare_file() locates the line where comparison should start, so that the banner GUIX Studio writes into every generated file -- which carries a revision string and a generation timestamp -- is skipped rather than compared. It looked that line up correctly in the first file and then looked it up in the first file again for the second: for line in list_2: if compare_start_string in line: start_row_2 = list_1.index(line) So the golden was sliced at the *generated* file's offset. While both files happened to reach "#include" on the same line the mistake was invisible, which is why it survived since the tests were added in #84. The offsets diverged when 6ba13db added a ten-line MIT licence header to all 111 golden .c and .h files. GUIX Studio does not emit that header, so every golden now reaches its first #include ten lines later than the file it is compared against. The golden was therefore sliced ten lines early and compared banner text against source. That made every one of the 107 .c and .h comparisons in the suite fail -- all 29 reported test failures -- while the .csv, .xliff and .xml comparisons passed. Those use skip_line instead of compare_start_string and never reach this code, which is exactly the split the failure log shows. The reported mismatch is the same in all 29: a generated "#include" line against a golden banner comment. Confirmed arithmetically -- in every case the golden line reported sits exactly ten lines before that golden's own first #include: generic_16bpp_resources.c reported idx 13, #include at 23, delta 10 generic_16bpp_resources.h reported idx 16, #include at 26, delta 10 generic_16bpp_specifications.c reported idx 14, #include at 24, delta 10 generic_16bpp_specifications.h reported idx 16, #include at 26, delta 10 compare_output_file() is the only caller that passes compare_start_string, so the change cannot affect the xliff, xml or plain-file comparisons. Verified by running the suite locally against a Studio built from this tree. Seven suites that fail in CI now pass with no mismatches at all, each gaining exactly the tests it had been failing: CI (broken) local (fixed) Font 9 / 1 10 / 0 Multi-Themes 18 / 1 19 / 0 Project Import 10 / 2 12 / 0 Trigger Edit 6 / 1 7 / 0 Trigger Target Rename 1 / 1 2 / 0 Bidi Text 3 / 1 4 / 0 Widget Name 3 / 1 4 / 0 Project Import compares a generated specifications file, so this also shows that the screen flow prototype block added by #173 does not disturb these goldens: that block is only emitted for projects that use Screen Flow, and these do not. No golden file is regenerated. The goldens still carry "GUIX Studio Revision 6.1.12.0" and a 2022 timestamp in their banners, and still name Azure RTOS rather than Eclipse ThreadX, but the banner is what the comparison is supposed to skip -- so none of that needs to be touched to make the suite correct. This workflow had never actually executed before 2026-08-27. Every earlier run was cancelled after queueing 24 hours for the retired windows-2019 image, or sat awaiting approval on a fork pull request, including the run for the v6.5.1 release itself. #174 gave it a runner again; this is the first result it has ever produced, and the defect it found is in the test harness rather than in GUIX or in Studio. Note that studio_view_test.yml triggers only on pull requests targeting master, so this change is not exercised by its own pull request into dev. It is validated by the release pull request that carries dev to master. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

fdesbiens mentioned this pull request Aug 25, 2026
Documented Screen Flow behaviour with an empty animation pool eclipse-threadx/rtos-docs-asciidoc#42
Merged

fdesbiensand others added 3 commits August 25, 2026 11:10

fdesbiens merged commit c179c19 into eclipse-threadx:devAug 25, 2026
1 check passed

fdesbiens deleted the fix/issue-172-animation-pool-size-zero branch August 25, 2026 17:10

fdesbiens mentioned this pull request Aug 27, 2026
Fixed the Studio view test comparing goldens at the wrong offset #184
Merged

Uh oh!

Conversation

fdesbiens commented Aug 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Generated files

Regression test

Documentation

Hotfix release preparation

Release tooling

Version constants

Re-verified after the bump

Uh oh!

Uh oh!

fdesbiens commented Aug 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Aug 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Generated files

Regression test

Documentation

Hotfix release preparation

Release tooling

Version constants

Re-verified after the bump

Uh oh!

Uh oh!

fdesbiens commented Aug 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Aug 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Generated files

Regression test

Documentation

Hotfix release preparation

Release tooling

Version constants

Re-verified after the bump

Uh oh!

Uh oh!

fdesbiens commented Aug 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Aug 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

fdesbiens commented Aug 25, 2026•
edited
Loading

fdesbiens commented Aug 25, 2026•
edited
Loading

fdesbiens commented Aug 25, 2026•
edited
Loading

fdesbiens commented Aug 25, 2026•
edited
Loading

fdesbiens commented Aug 25, 2026•
edited
Loading