Skip to content

[Win32] Consolidate tool bar image list native synchronization - #3508

Draft
HeikoKlare wants to merge 2 commits into
eclipse-platform:masterfrom
HeikoKlare:toolbar-imagelists-cleanup-step2
Draft

[Win32] Consolidate tool bar image list native synchronization #3508
HeikoKlare wants to merge 2 commits into
eclipse-platform:masterfrom
HeikoKlare:toolbar-imagelists-cleanup-step2

Conversation

@HeikoKlare

@HeikoKlare HeikoKlare commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Important

This change is based on and should thus be merged after #3504

ToolBar's setImageList/setHotImageList/setDisabledImageList each carried a near-identical copy of the logic to compare the current TB_GET*IMAGELIST handle against the ImageList's handle for the current zoom, and, if different, apply it via TB_SET*IMAGELISTv while toggling vsetDropDownItems around it to avoid a Windows layout glitch. handleDPIChange and addImage each called all three setters in turn whenever any one image list might have changed.

This change consolidates that duplicated logic into a single refreshImageList/refreshImageLists pair operating on the current
field values, replacing the three getters and three setters. This is a standalone, behavior-preserving cleanup; ToolBar's representation is still three separate ImageList fields. It prepares the ground for introducing a class that owns the three image lists as one unit.

Related to #3466

Note: This change is human-crafted and was only slightly revised and documented with the help of AI

This is the second of multiple incremental steps to enhance ImageList handling and consistency inside ToolBar. This is supposed to be merged for 2026-12 M1.

ToolItem manipulated ToolBar's three normal/hot/disabled ImageLists
directly: reading them via ToolBar's getters, creating them inline
when absent, and calling add()/put() on each of them itself. This
spread the bookkeeping for a single item's images across both
classes and made ToolItem responsible for details that are really
ToolBar's to own, such as lazily creating the image lists sized to
the first image added.

With this change, ToolBar exposes addImage/putImage/clearImage
instead, and ToolItem goes through these instead of touching
ImageList directly. ToolBar's internal representation (three
separate ImageList fields, and their existing
setImageList/setHotImageList/setDisabledImageList synchronization
methods) is otherwise unchanged.

Related to
eclipse-platform#3466
ToolBar's setImageList/setHotImageList/setDisabledImageList each
carried a near-identical copy of the logic to compare the current
TB_GET*IMAGELIST handle against the ImageList's handle for the
current zoom, and, if different, apply it via TB_SET*IMAGELIST while
toggling setDropDownItems around it to avoid a Windows layout glitch.
handleDPIChange and addImage each called all three setters in turn
whenever any one image list might have changed.

This change consolidates that duplicated logic into a single
refreshImageList/refreshImageLists pair operating on the current
field values, replacing the three getters and three setters. This is
a standalone, behavior-preserving cleanup; ToolBar's representation
is still three separate ImageList fields. It prepares the ground for
introducing a class that owns the three image lists as one unit.

Related to
eclipse-platform#3466
@github-actions

Copy link
Copy Markdown
Contributor

Test Results (win32)

   35 files  ±0     35 suites  ±0   5m 2s ⏱️ +24s
4 868 tests ±0  4 792 ✅ ±0  76 💤 ±0  0 ❌ ±0 
1 395 runs  ±0  1 371 ✅ ±0  24 💤 ±0  0 ❌ ±0 

Results for commit 82224f9. ± Comparison against base commit 9ca368d.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant