Adjusted computation of horizontal toolbar size.

[ShahzaibIbrahim]

The first part ensures the toolbar becomes tall enough to fit controls like Combo or Text, whose height is often larger than the native toolbar button height returned by TB_GETITEMRECT. Without this check, the toolbar height is based only on Windows’ button metrics, which are smaller, causing embedded controls to be clipped. By taking the max of the toolbar height and each control’s actual height, the final toolbar size always accommodates the tallest embedded control.

In the second part, the original code centered the control vertically, but when the control (like a combo box) was taller than the toolbar item height, the centering calculation produced a negative offset, shifting the control upward and causing clipping. Your fix uses Math.max(0, …) to prevent negative offsets, ensuring the control is never positioned above the item’s top. As a result, taller controls are aligned safely without being cut off.

To Reproduce

• Open ControlExample
• Open Toolbar Tab
• Enable ComboChild

Expected behavior
Combobox is displayed correctly

Result

---

Before Fix

After Fix

Fixes #935

[github-actions]

Test Results (win32)

   34 files  ±0     34 suites  ±0   4m 36s ⏱️ +24s
4 627 tests ±0  4 554 ✅ ±0  73 💤 ±0  0 ❌ ±0 
  167 runs  ±0    164 ✅ ±0   3 💤 ±0  0 ❌ ±0 

Results for commit dec0c6e. ± Comparison against base commit f005865.

♻️ This comment has been updated with latest results.

[tomaswolf]

If such a toolbar is used now in a view stack, do we get #936 (comment) again?

(If you need a view with such a toolbar, try EGit's staging view or history view. When the window is wide enough so that there is enough horizontal space to the right of the view stack's tabs to accomodate the toolbar's width, the toolbar should be on the same line as the tabs.)

If that layout issue re-appears: maybe the CTabFolder needs layout changes.

[HeikoKlare]

If you need a view with such a toolbar, try EGit's staging view or history view.

I also went through the EGit views when trying to find a toolbar that we might easily use for testing, but none of those seems to contain a combo, do they? We only notices this issue with combos so far, but they seem to be rarely used in toolbars. Only usage I know about is the zoom field of GEF.

[tomaswolf]

none of those seems to contain a combo, do they?

That's right. They do contain text input fields, though. If the issue occurs only with combos, that won't help then. IIRC the text inputs are also cut off at the bottom on Linux (but this change here is Windows only).

[laeubi]

In general Toolbar with controls are often work quite poor and the best "workaround" is to add a large enough image (what the would make the toolbar higher). A similar issue (and maybe easier to reproduce?) occurs when one adds buttons with images of different size, e.g. add a tool item with a 16x16 image and one with a 32x32 image then both are shrink to 16x16px.

By the way according to the image, the vertical (!) size is to small or do I misunderstand the issue?

[arunjose696]

I have tested this change and could see this fixes the issue in GEF zoom field. I have a question about the changes in the toolitem and the below statement in the description

In the second part, the original code centered the control vertically, but when the control (like a combo box) was taller than the toolbar item height,

I dont understand how this can happen as in the current code the height of tool item is the max height of all the controls, so why is the second part required in toolitem to adjust toolitems y?

[ShahzaibIbrahim]

I have tested this change and could see this fixes the issue in GEF zoom field. I have a question about the changes in the toolitem and the below statement in the description

In the second part, the original code centered the control vertically, but when the control (like a combo box) was taller than the toolbar item height,

I dont understand how this can happen as in the current code the height of tool item is the max height of all the controls, so why is the second part required in toolitem to adjust toolitems y?

@arunjose696 In the case of a combo box, its height can exceed the height of the toolbar. The existing logic vertically centers the control by computing an offset based on the height difference. When the combo box is taller than the toolbar, this calculation produces a negative Y offset, causing the control to be positioned partially outside the toolbar and resulting in the top being clipped. By using Math.max(0, itemRect.height - rect.height) / 2, we clamp the offset to a non-negative value, ensuring the control is never positioned at a negative Y coordinate and preventing the top portion from being cut off.