/form-events

name: form-events
description: "Модуль управляемой формы 1С. Используй когда нужно написать или отревьюить обработчики формы, расставить директивы компиляции, сократить серверные вызовы и трафик, разобраться с параметрами формы, подключаемыми через УстановитьДействие обработчиками или клиент-серверной границей в модуле формы."

Form Module Events

MCP routing

• Preferred path: use MCP `unica` tools `unica.view {}`, `unica.view` on the form node, `unica.view` on the object node, `unica.search`, `unica.apply`, `unica.check`, and `unica.run`.
• Runtime идёт через `unica.run`: вызов без `op` отдаёт словарь операций и

контракт каждой — `argsSchema`, `execution`, `previewRequired`, `dryRunRequired`. Контракт вызова бери оттуда, а не из этого текста; при `implemented: true` используй опубликованную `argsSchema`; при `support.state: limited` разрешено только подмножество `support.supportedArgs`. При `support.state: unavailable` остановись; не выдумывай аргументов при `argsSchema: null`. Для плановой операции сначала проверь результат `dryRun: true`, затем исполняй запрос с `dryRun: false`. Preview не фиксирует входы между вызовами. Не обходи контракт прямым runner-ом.

• Use `unica.docs` with `source: "development-standard"` for the standards about form modules: 439, 455, 487, 492, 642, 724, 741, and diagnostics АПК:100, АПК:526, АПК:547, АПК:1410, АПК:1412, BSLLS:SeveralCompilerDirectives, BSLLS:ServerSideExportFormMethod. These are standards, not evidence of runtime behavior; confirm the wording before citing one.
• Do not call internal analyzer, runtime, standards, or package adapters directly. They are hidden behind MCP `unica`.

References

• Read `../../references/platform/form-events.md` for the client/server split, directives, the server-call budget, form parameters, and attached handlers.
• Read `../../references/platform/object-events.md` when the logic belongs to the object being written rather than to the form.
• Read `../../references/specs/form-patterns.md` and use `form-patterns` for layout, archetypes, and UX; this skill owns the module, not the arrangement.

Core model

A form module holds client and server code in one file, and the directive on each procedure decides which. Everything else follows:

• **Where it runs** — `&НаКлиенте`, `&НаСервере`, `&НаСервереБезКонтекста` belong in form and command modules; elsewhere use preprocessor instructions (std439). One directive per procedure, never zero and never two.
• **What it costs** — one user action must not produce extra server calls from configuration code, and a deviation needs a stated reason (std487).
• **What it receives** — form parameters are declared on the parameter tab, so `ПриСозданииНаСервере` reads them directly instead of probing with `Параметры.Свойство()` (std741).
• **How it is wired** — a handler assigned through `УстановитьДействие` carries the `Подключаемый_` prefix (std492).

Workflow

1. Decide which side the logic belongs to before writing it: needs the database or the object → server; needs the user or the form's visual state → client. 2. Inspect the form with `unica.view` on the form node for the declared events, parameters, and items, and `unica.view` on the object node for the object behind it. 3. Read the existing module with `unica.view` on the module node (its `Method` branch lists the methods) before adding to it. 4. Count the server calls the change adds on the path of a single user action. If it adds one, name the reason. 5. Declare any new form attribute through `unica.apply` (`attribute.add` at the form address) before reading it in the module. A form parameter is not an attribute and has no `unica.apply` operation yet: name that gap instead of adding an attribute in its place. 6. Apply module changes with `unica.apply`, one verifiable step at a time, giving every new procedure exactly one directive. A handler is wired at the event's own address from the `Event` branch of the form or its item, `…Form.<Form>[.Item.<Item>…].Event.<Event>`: `event.implement` writes the binding and the procedure, `event.bind` writes only the binding with `values: {handler[, callType]}`. The event and its item are named by the address, not by arguments. 7. Verify statically with `unica.check` on the module node (test runs are outside the v0.13 surface), and require separate evidence for runtime behavior and opening the affected form.

Command Availability

When a handler must disable, lock, or re-enable a form command in the UI, do not write `Команды[ИмяКоманды].Доступность`: the form command object is not the UI element whose availability is shown to the user. Inspect the form first with `unica.view` using its qualified `at` address (CTR.SOURCE.LOGICAL-NODE-VIEW-SHAPE). Example calls for the form and its item collection:

{"name": "unica.view", "arguments": {"at": "main:Catalog.Номенклатура.Form.ФормаЭлемента"}}

{"name": "unica.view", "arguments": {"at": "main:Catalog.Номенклатура.Form.ФормаЭлемента.Item"}}

A node returns `props` and `branches`; a collection page returns `items` with `at` addresses. Follow all nested `Item` branches using their returned addresses and all pages using the returned `cursor`, keeping the address and read parameters. The current view exposes only `tag`, `title`, `visible`, `enabled`, and `readOnly` in an item's `props` (`title` is `null` when no distinct title is set).

To establish a link, the item's `CommandName` must match `Form.Command.<ИмяКоманды>` or the relevant standard-command reference. However, the current view does not expose `CommandName` or `binding`: the item tree alone cannot prove command links or that every linked item has been found. Do not guess links from names or titles. For the missing data, use the emergency source bridge, which permits opening a file outside Unica:

{"name": "unica.resolve", "arguments": {"at": "main:Catalog.Номенклатура.Form.ФормаЭлемента"}}

The returned `path` is relative to t