Just about everything here is about the Layout Editor in VSCode. We’re starting to get the visual constraint editor fleshed out so please play with it and get us some bug reports!
We’ve also made it possible to add event handlers inside View and Window block format so you can now do this without needing to subclass the window:
Window myWindow
Control button myButton
Handle Action()
// code referring to other controls on the layout...
End Handle
End Control
End Window
New Features
Nesting-aware End Handle scanner with per-control degradation
Preserve inline Handle blocks as keyed opaque spans
Badge and list inline Handle blocks in the layout editor
Warn before deleting a layout control that owns inline Handle code
Report inline Handle spans in buoy/layoutOutline and degrade per-control on a broken body
Lower window-level inline Handle blocks into the lowered Window class
Diagnose bad inline Handle blocks in Window Control bodies
Lower control-level inline Handle blocks into the synthesized _ hook
Accept inline Handle blocks in Window/View bodies; share one Handle parser
Stop Interface Sub/Function signatures from growing indent
Canvas no longer swallows Tab forever once focused (macOS + Linux)
Build macOS bundles and Windows/Linux exes in a temp dir, then atomically move into place
Don’t suppress user Quit/Hide menu shortcuts on macOS
Route Build/Run/Debug commands through the Build Graph
Detect mid-line Lambda/Block literals in document formatter
Stop UIControl Lock* properties crashing on a second same-axis lock
Clamp window resize to Auto Layout constraints
Control’s own Handle override no longer shadowed by declarative Window control block
Changes
Learning Buoy book has been updated to make sure all examples compile with the changes that have been made to the language thus far, with updates to the visual layout and constraint sections added. A PDF version and accompanying example projects are also in that folder.
We’re specifically looking for edge cases where the layout editor scrambles control positions when moving controls around in constraint-mode. You can change controls to using constraints just by right-clicking on a control and selecting “Convert to Constraints.”
New Features
Add a control context menu for stacking order in the Layout Editor
Add Inspector editing for the highest-impact property on each control
Render visual control skins in place of wireframe boxes
Report declared control properties in layout outline
This release is largely about getting Windows Dark Mode working. We still have a couple of unsolved gaps like DateTimePicker and TabPanel Tabs, but we’re getting there!
New Features
Set minimum supported Windows version to 10.0.19045 in installer
Apply dark chrome to ProgressBar, Slider, Stepper (Windows)
Native dark chrome for Button on Windows via uxtheme
Draw a themed border around TabView’s pane on Windows
Theme-aware Toolbar item text color on Windows
Theme-aware colors for ListBox/Splitter/GroupBox/Canvas/TabView/HtmlView on Windows
Theme-aware Label/TextField/TextArea/ComboBox colors on Windows
Dark title bar on Windows, live-updating on OS theme change
Show and edit GroupBox Caption in the Layout Editor
Bug Fixes
Windows quits on any window close, not just the last
Only quit on Windows when the last window closes
Give toolbar SearchField creation-time dark chrome; keep ProgressBar visual-style opt-out dark-mode-only
Theme-aware chrome for RadioButton/TextField/ProgressBar via explicit colors
Re-theme TextArea scrollbar chrome on live dark/light toggle
Keep Windows DisclosureTriangle’s glyph at native size
Dark-theme TextArea’s native scrollbar on Windows
Re-theme already-created Windows controls on live OS theme toggle
Apply dark chrome to Checkbox/ComboBox/TabView, mute DisclosureTriangle glyph
Recolor Toolbar icons in dark mode; fix README Button wording
Correct uxtheme ordinal-135 dispatch, app-mode init order, and chrome-apply call site
Why not making Buoy WinUI 3 ready since the design? Win32 controls are a dead tech. WinUI 3 is the current UI Framework for ages now, and even Windows 11 is right now updating the ENTIRE OS to use it everywhere updating legacy content IN THE OS.
Advantages of WinUI 3 over classic Win32 for modern desktop application development:
Advantage Category
Win32 C++
WinUI 3 (Windows App SDK)
Theme & Dark Mode Support
Flawed and incomplete. Requires stripping visual styles (SetWindowTheme), undocumented hooks, or tedious custom-drawing to prevent white backgrounds and unreadable text.
Native, automatic, and flawless. Automatically respects system themes (Light/Dark) and supports explicit app-level overriding with smooth transitions.
User Interface Aesthetic
Legacy look and feel (Windows Vista/7 style common controls). Lacks modern design language by default.
Fluent Design System. Features modern aesthetics out of the box, including rounded corners, drop shadows, and Mica/Acrylic materials.
High DPI & Scaling
Complex to manage. Requires handling WM_DPICHANGED messages, manually resizing fonts, re-calculating layouts, and swapping bitmapped assets.
Automatic scaling. Natively handles various monitor resolutions and dynamic DPI changes (e.g., moving a window between a 4K monitor and a 1080p laptop).
Layout & Responsiveness
Coordinate-based absolute positioning. Resizing windows requires manual pixel math via MoveWindow or DeferWindowPos.
Flexible layout panels. Uses dynamic, flow-based layout containers (like Grid, StackPanel, and RelativePanel) that automatically adapt to resizing windows.
While Win UI 3 is way MS would like everyone to move to its incomplete and there are missing controls
As of the current WinUI documentation, notable gaps in first party (MS built & supported controls) include:
Ink controls
InkCanvas
InkToolbar InkCanvas has appeared experimentally in Windows App SDK, but the inking controls are not partof the stable WinUI 3 channel. Microsoft
DataGrid
There is no first-party Microsoft DataGrid in the core WinUI 3 controls.
Use the Windows Community Toolkit, Uno Platform, or a commercial toolkit.
Charts and data visualization
No built-in chart controls such as line, bar, pie, or financial charts.
TreeView-related advanced controls
WinUI 3 has TreeView, but lacks several richer tree/grid variants commonly found in third-party frameworks, such as a hierarchical TreeGrid.
Color-selection controls
No comprehensive built-in color picker equivalent to those commonly available in WPF or third-partyUI suites.
Rich text editing
There is no full-featured built-in rich-text editor control comparable to a document editor.RichEditBox provides text editing, but it is not a complete word-processing control.
Scheduling and calendar views
Basic date and time controls exist, but controls such as Scheduler, Agenda, Timeline, andDateRangePicker are not part of the core WinUI 3 set.
Advanced input controls
Controls often expected from mature UI frameworks—such as NumericUpDown, masked input, autocomplete, range sliders, and advanced multi-select controls—generally require custom implementations or third-party libraries.
Specialized navigation and layout controls
Ribbon, dock panels, property grids, navigation drawers with advanced features, and document-tab interfaces are not core WinUI 3 controls.
Some of these may exist in the Windows Community Toolkit
Some controls are not truly “missing” but are provided outside the core framework. For example, DataGrid, charts, scheduler controls, autocomplete, color pickers, and tree grids are available through third-party WinUI libraries.
IMHO, MS has made a mess with Win32, WPF, WinForms and the plethora of UI MS own toolkits
No wonder Uno and Avalonia etc are as popular as they are
They fill the gaps in MS own toolkit
When I was researching which library to start with, i actually started going down the winui road. It became very clear that WinUI 3, is just Microsoft’s third failed attempt to unify their UI kit. Here’s one of the main reasons we haven’t gone that way yet.
WinUI 3 is COM/WinRT-only with no C ABI, so Declare can’t reach it directly. And WinUI 3 ships in the Windows App SDK, which is not in-box: you either self-contain it (you own the CVE cadence) or require the framework package (a deployment dependency on the end user’s machine). That cuts against the §24.4 security-update constraint in a way ComCtl v6 does not, since ComCtl is serviced by Windows Update.
Well… ComCtl v6 is already a dead man walking. Legacy that won’t be updated and set to go to the drains, day after day, as MS selected WinUI 3 as the official OS UI framework. That decision alone will make that death of WinUI3 very unlikely, more likely expanded towards some WinUI 4 in the future with easier migration.
But I won’t insist. You will go by your chosen paths, I’m just worrying about the very likely need of rewriting all the components and plumbing again for WinUI 3 (or something as Avalonia and its dependencies too) because the ComCtl UI will rot over time, and fast.
Yep… WinUI 3 demands C++/WinRT but MS has chosen such way as the “native way” and your user interface design may start already with tech debit using the ComCtl legacy
i get your point but i just cant get to a complete UI with any of the WinUI versions yet.
The problem i see is that to have a complete kit, i’d still have to support win32 plus all current and upcoming versions of WinUI. talk about application bloat! The Windows UI framework is already one of the biggest components in a desktop app.