TabControl enhancements

Create issue
Issue #82 resolved
Former user created an issue

Automatic migration. Original reporter: "zap"

Here's a patch that does the following:

  • Ability to switch tab button pane position to top/bottom at runtime. A single looknfeel for both positions.
  • Enhanced look, more in line with contemporan GUIs.
  • Ability to scroll the tab button pane. When needed, two special buttons are made visible with which you can scroll the tab button pane left/right. Additionaly, you can drag the tab button pane by grabbing it by pressing the middle mouse button and then moving the mouse to left/right. And finally, you can just use the scroll wheel over the tab button pane.
  • Enhanced the PropertyDim Falagard keyword so that you can now reference UDim values as well. For example: <PropertyDim name="TabHeight" type="Height" /> will transform the "Height" property (which is in the "{s,o}" format) to a floating-point value by multiplying it with window pixel height. If 'type' keyword is not specified, PropertyDim works exactly as before.
  • Fixed the FrameComponent drawing routines so that the pixmaps are clipped properly against the destination rectangle.
  • Fixed endianess issues with PropertyHelper. Now it could (should) work correctly on Big-Endian machines too (mostly 32-bit colours-related).
  • In PropertyHelper replaced %f format specifiers with %g which gives same effect as cout << float. sprintf/sscanf is about twice faster than std::ostringstream so I've replaced back ostringstream with sprintf.
  • ColourRect specifiers may now be written in short as a single hexadecimal colour if all four values are the same. For example, instead of "tl:FF112233 tr:FF112233 bl:FF112233 br:FF112233" you can now write just "FF112233". Of course, you can use the complete form too.
  • A discutable change: I removed the check in captureInput() so that only active widgets may capture input. In my case I had a "inactive" element (the tab control button) which still needed to capture the input, and, besides, I don't understand why only active widgets may capture the input. I don't foresee any potential problems with this patch, though.

Reproducibility: always

Comments (1)

  1. Log in to comment