A button could be given a fixed input range for any macro name; pressing it then passed the range
to macro.run as `inputs`, which check_params refuses for a macro without inputs ("it takes no
inputs"), so such a button failed on every press. Now insert.button and control.assign refuse a
fixed input when the named macro exists and declares no inputs, naming the macro; a macro the
workbook does not have yet is not checked, and the assignment is kept as given. On open, a stored
fixed input for a macro without inputs becomes the selection: the file itself assigns the macro
on the selection, and the stored range would fail every press.
Tests: a_fixed_input_for_a_macro_without_inputs_is_refused_when_assigned (insert and assign are
refused with the reason in any letter case; a macro with an input and a macro not yet defined
take the range; a stored fixed input comes back as the selection). format_and_assign and
a_kept_button_action_comes_back_only_on_the_same_button give their macro an input.
write_link skipped the write only when the linked cell held a constant equal to the value; a cell
with a formula was always written, so Format Control's OK (which sends the value back every
time) replaced the formula with a constant even when the formula showed that value, and on a
protected sheet with the linked cell locked a rename was refused. The value the cell shows is now
compared whether or not it holds a formula: a write that changes nothing is skipped, and a real
change still replaces the formula with the constant, as in Excel.
Test: a_formula_in_the_linked_cell_survives_a_write_of_the_value_it_shows (insert and Format
Control with the value the formula shows keep the formula, also on a protected sheet with the
cell locked; a changed value writes the constant).
A button's command ran through the macro policy and the file sandbox, but not through the macro
runner's request filter, so a file-borne button assigned `link.open {url}` opened the page once
the generic trust question was answered. Now `link.open` is refused for buttons up front, when it
is assigned and when a file brings it in, with the wording of the other denied commands; and
after a press runs its command, the UI requests it queued are checked as the macro runner checks
a step's: a dialog or a web page makes the press fail with the reason and rolls the group back,
a cell edit is dropped, and messages for the person stay queued.
Tests: link.open joins a_denied_command_is_refused_when_assigned_and_when_a_file_brings_it_in
(assign, insert and a file-borne press refuse it; no OpenUrl request is left), and
a_button_command_that_would_open_a_dialog_or_a_page_is_refused_after_it_runs (insert.link with no
parameters is refused with the dialog wording and its request dropped; the filter refuses a page,
drops a cell edit and keeps messages). docs/macros.md says what a button's command may not do.
An entry of the hidden name without `name` or `at`, or with something other than text there,
skipped those checks (is_none_or) and could pin its action onto whatever button sat at the stored
index. The writer always stores both keys, so such an entry is now dropped like an unparsable one
(is_some_and); the doc comment says so.
Test: a_kept_action_without_the_buttons_name_or_anchor_is_dropped (an entry without `name`,
without `at`, with a number for `name` and with null for `at` gives the button no action and the
hidden name is removed; the writer's own entry still comes back).
load_action_names gave every kept action back to a button the file assigned no macro. A button
that ran a macro with a fixed input range or an output cell, whose macro another application
removed while keeping the button's name and place, so came back with the assignment. Now a kept
macro action comes back only onto a button the file still assigns that macro, and a kept command
only onto a button the file assigns no macro, as the function's comment already said.
Tests: a_macro_assignment_removed_in_another_application_stays_removed (the saved file with the
controlPr macro attribute and the VML FmlaMacro removed reopens with no action and no hidden name;
unedited, with the whole action), a_macro_assigned_in_another_application_replaces_a_stored_command
(the file's macro wins over a kept command), and the cleared case in
a_kept_button_action_comes_back_only_on_the_same_button. macros.md and file-format-parity.md
describe the hidden name and the reopen rule.
control.format and control.assign refused to change a locked control on
a protected sheet, but object.move, object.delete,
object.setAnchorMode, arrange.bringForward, arrange.sendBackward and
arrange.align changed it all the same. They now refuse it with the
same message; an unlocked control still moves, and other kinds of
objects are unchanged.
The button actions xlsx has no place for (commands, fixed inputs,
output cells) are kept in a hidden name keyed by sheet and the
control's place on the sheet. When another application added, removed
or reordered controls before saving, opening the file gave the action
to whichever button now had that place, and could replace a macro the
file itself gave that button.
Each entry now also holds the button's name and anchor cell, and is
restored only on a button with that name and cell whose own action from
the file does not contradict it: a stored macro action only on a button
that still runs that macro, a stored command only on a button the file
gives no macro.
Pressing a button whose command reads or writes a file asked "Run
file.exportCsv from 'Button 1'? It writes a file." without saying which
file, so the person could not tell what they were approving. The
question now ends with the command's `path` in parentheses; control
characters show as spaces and a path longer than 200 characters is
shortened in the middle.
Buttons, scroll bars (sliders) and spin buttons are written the three
ways the published formats describe: a control properties part
(xl/ctrlProps/ctrlPropN.xml, formControlPr with objectType, fmlaLink,
min, max, inc, page, val and horiz), a <control> in the sheet's
<controls> inside mc:AlternateContent with its anchor, print and locked
flags and a button's macro="[0]!Name", and a VML shape with
x:ClientData. Notes and controls share one VML drawing per sheet; shape
ids come from 1024-id blocks listed in the drawing's idmap (after the
blocks kept header and footer drawings use), notes first, so each
control's shapeId names its VML shape.
Reading prefers the properties part, takes the caption from the VML
text box and falls back to the VML alone for files that only have it.
Values are clamped to whole numbers 0..30000 and repaired to pass the
model's rules.
Form controls of other kinds (check boxes, list boxes, drop-downs) stay
with pass-through: the reader returns the shape numbers it modelled,
and pass-through keeps the rest of the <controls> element and VML
drawing without them. On save, modelled controls join the kept
<controls> element and take a fresh shape block in the kept drawing, so
a sheet with both round-trips without duplicates. Properties part names
are reserved so kept parts of other sheets don't collide with them.
Button actions xlsx has no place for (commands, fixed inputs, output
cells) travel in a chunked hidden name keyed by sheet and position, and
are taken back out on open. The streaming sheet parser now splits only
shallow <row> elements, so an anchor's <xdr:row> inside <controls> stays
in the tree.
A sheet holds form controls as floating objects of a new kind
(ObjKind::Control): buttons that run a macro or one command, and sliders
and spin buttons that hold a whole number from 0 to 30000 and write it
to a linked cell. They take part in everything other objects do: ids
from the workbook sequence, object.move, object.delete and
object.setAnchorMode, the Selection Pane and Bring Forward / Send
Backward, anchors that follow row and column edits, fresh ids on a
copied sheet, and links that follow inserts, deletes, cut-moves, sheet
renames and sheet deletes like chart series.
Commands (cmd/controls.rs): insert.button, insert.slider,
insert.spinButton, control.format, control.assign, control.setValue,
control.press and the control.list query. Each numeric rule (0 <= min <
max <= 30000, 1 <= step <= max - min, page >= step for sliders) is
refused with its own message, and values are clamped and snapped to the
step. control.setValue writes the linked cell through cell.set inside
one undo group, so dependents recalculate and one Undo restores both;
every commit moves linked controls to what their cells hold.
control.press runs a button's macro through macro.run, or its command
through the macro policy with the document's trust, so a button in a
workbook opened from a file asks before it runs anything. Like a macro
step, the command runs inside the scripts' file sandbox unless it is an
approved file command. Macros never press controls, and macro.rename
keeps buttons pointing at the renamed macro.
macro.run, macro.check and the debugger take `output`, which replaces
the macro's output anchor for that run (a button that sends the output
elsewhere). The policy and the approval go by the stored macro; the
footprint, the conflict rule and the per-step check work on the cells
`output` names. A value that isn't reference text of at most 1,024
characters, or names no cell, is refused before anything runs.
prxnvt