v1.1.5

This release fixes choose file on a Save dialog that offers a default name. Before, the case was
green while the application saved under the default name. One change is something an existing setup
may notice, and it is marked.

A Save dialog saves the name the case gave

{ "locator": "Button#ExportButton", "act": "invoke" },
{ "locator": "Window[class=\"#32770\"]", "act": "choose file", "with": "{files}/saved.png" },
{ "locator": "Window[class=\"#32770\"]", "act": "read", "absent": true, "named": "the dialog closed" },
{ "locator": "Text#ExportStatus", "act": "read", "reads": "name", "expect": "Saved saved.png" }

An application that sets FileName on its SaveFileDialog gets a dialog that keeps that name
until its name box is edited. choose file put the path in the box as its value, and a value set
from outside does not count as an edit. The box read the path back, the dialog confirmed with its
default name anyway, and both choose file and the absent read passed. If a file with the default
name already existed, the dialog asked whether to replace it instead. That question is a second
#32770, so the dialog's own locator was refused as ambiguous.

choose file now types the path into the name box, as characters sent to the box's own window. The
dialog takes that as an edit and saves under the name the case gave. It still needs no foreground.

(May notice.) The box is read back before the dialog is confirmed. If it does not hold the
path, the step is refused, naming what the box held, and nothing is confirmed. Before, that case
was a green over the wrong file. The trace line names the act's route as WM_CHAR, Invoke where it
used to say Value, Invoke.

Installing

<PackageReference Include="Winwright" Version="1.1.5" />
<PackageReference Include="Winwright.InApp" Version="1.1.5" />

Full Changelog: v1.1.4...v1.1.5