Version 1.2.0

What's Changed

Dependencies 📦

• Deps: Bump the microsoft-packages group with 2 updates by @dependabot[bot] in #7
• Deps: Bump the microsoft-packages group with 1 update by @dependabot[bot] in #8

Other Changes

• Record what the listening pass actually found by @Menelion in #6
• Add row images to NativeListView by @Menelion in #9

New Contributors

• @dependabot[bot] made their first contribution in #7

Full Changelog: v1.1.0...v1.2.0

Version 1.1.0

Added

• NativeListView.SetInsertionMark and ClearInsertionMark are back, and this time they draw.
  Removed in 1.0.0 because the control's own LVM_SETINSERTMARK is refused in report view - it
  returns FALSE and stores nothing - they are now an overlay painted in the control's post-paint
  stage, in SystemColors.Highlight so the line follows the theme including high contrast, and
  scaled by DPI.

  This belongs in the library rather than in an application because an application cannot do it:
  the list is a native child window that paints itself and covers the control, so a consumer
  never receives a paint event over it. Only the code already answering the control's draw
  notifications can put anything on top.

Changed

• Package validation is enabled against the 1.0.0 baseline, so a breaking change to the public
  surface now fails the build rather than reaching nuget.org.

Version 1.0.0

First stable release. The public API is settled; see the versioning note above.

Added

• NativeListView follows the system theme, which is a consequence of the above rather than a
  separate feature. Left alone the colors resolve through SystemColors, which WinForms remaps
  for the application's color mode, so the list now goes dark with the rest of a dark-mode
  application and honors a high-contrast theme. Previously nothing was pushed at all and the
  control fell back on the raw GetSysColor(COLOR_WINDOW), which stays white however the
  application is themed — a white list in a dark window. The visual style is chosen to match
  (DarkMode_Explorer rather than Explorer), without which the header, the scroll bars and
  the hover highlight stay light on an otherwise dark list, and both are re-applied on
  WM_SYSCOLORCHANGE so a theme switched while the application is running is followed.
• NativeListViewColumn.Alignment is settable rather than constructor-only, which is what
  every other column property already was. Assigning it preserves the sort arrow, which shares
  the same Win32 format word and a plain write would have cleared. Like Width, it reads back
  from the control while the column is in one, so it cannot drift from what the control holds.
• A runnable sample application under samples/, and a listening script beside it, so the
  claims this library makes about screen readers can be checked rather than taken on trust. It
  carries an English and a Hebrew catalog with a language switch, so the right-to-left support -
  previously the least verified part of the library - can be exercised against real
  right-to-left text and real non-Latin mnemonics rather than a mirrored English layout.
• Designer metadata on NativeListView: categories and descriptions on its properties and
  events, so they no longer land under Misc in the Properties window with no explanation.
• Parameter and return documentation across the public API. Every public member already had a
  summary, which is all the compiler checks; what a caller sees in a signature help popup is
  the parameter list, and that was blank.
• Package icon and package title.

Changed

• Breaking. ContextMenuRequest is now NativeContextMenuRequest, so every public type in
  the menu API carries the same prefix.
• Breaking. NativeListViewColumn rejects a null header text rather than silently treating
  it as empty, which is the policy the menu API already had.
• Breaking. NativeListView.SetInsertionMark and ClearInsertionMark are removed. They
  never worked: Win32 does not support an insertion mark in report view, which is the only view
  this control has, so LVM_SETINSERTMARK returned FALSE and the control stored nothing. A
  method that silently does nothing is worse than no method. Draw a drop indicator from
  GetItemBounds, which reports the row rectangle for exactly that purpose.
• NativeListViewColumn.Width, Alignment and SortOrder all read back from the control while
  the column is in one, so none of them can drift from what the control actually holds.
• Breaking. AccelConverter.ConvertKey returns a named AcceleratorEntry struct rather
  than a bare tuple, whose element names are compiler metadata a generic signature can lose.
• Breaking. MenuSpecValidator.Validate throws ArgumentException rather than
  InvalidOperationException for a malformed spec. The spec is the argument, and
  ArgumentException is what a caller's exception filter will be written against.
• AssemblyVersion is pinned to {Major}.0.0.0 rather than tracking the patch number, so a
  patch release no longer changes the binding identity. FileVersion and InformationalVersion
  still carry the full version.

Fixed

• Menu tracking is per-thread rather than per-process. TrackPopupMenuEx runs its nested loop
  on the calling thread and the HMENU it displays belongs to that thread, but the guard that
  stops a menu being rebuilt while it is on screen used a process-wide counter. WinForms allows
  more than one UI thread, each with its own pump, so a popup open on one of them made
  Rebuild throw on another that had no menu open at all. Found by a test run that failed on
  one machine and passed on another, which is what a race looks like.
• NativeListView.BackColor and ForeColor did nothing. The list window paints itself, and
  nothing was ever pushed across; they are now applied with LVM_SETBKCOLOR,
  LVM_SETTEXTBKCOLOR and LVM_SETTEXTCOLOR. Both default to the window colors rather than
  inheriting the parent's dialog gray, matching what a WinForms ListView does, and assigning
  Color.Empty resets them.
• Menu accelerators now decide whether a keystroke is theirs by asking whether the message is
  aimed at the owning form or anything inside it, rather than by consulting Form.ActiveForm.
  That property answers a different question and got this one wrong in two shipping cases: for
  an MDI child it names the MDI parent, so a child's own menu bar never fired; and it is null
  whenever the active window is not a WinForms Form, which is the normal state of a mixed WPF
  or native host. Modal dialogs are still excluded, because a dialog is owned by the form but is
  not a child of it. This removes the last of the limitations previously tracked for 1.0.
• A keyboard-invoked NativeContextMenu now anchors at the focused row of a NativeListView,
  as it already did for a WinForms ListView, TreeView and ListBox. NativeListView is a
  Control rather than a ListView, so it had been falling through to the control's top-left
  corner — the library's own list control was the one case its context menus did not know about.
• Clearing NativeListView.AccessibleName now reaches the list window. The name was only ever
  pushed when non-empty, so a reader went on announcing a name the application had taken away.
• NativeMenuSpec rejects a null item label at the builder call. It previously survived until
  validation walked the tree for mnemonics, and the exception then named a parameter of a
  formatter the caller never called.

v0.2.0

Full Changelog: v0.1.1...v0.2.0

v0.1.1

Full Changelog: v0.1.0...v0.1.1

Version 0.1.0

Full Changelog: https://github.com/Oire/winforms-native-controls/commits/v0.1.0