pdfAddActionToObj

int32_t __stdcall pdfAddActionToObj(PPDF IPDF, int32_t ObjType, int32_t Event, uint32_t ActHandle, uint32_t ObjHandle);

function pdfAddActionToObj(const IPDF: PPDF; ObjType, Event: Integer; ActHandle, ObjHandle: Cardinal): Integer; stdcall;

Purpose. Attach an already-created action (Actions & Named Destinations) to an object's event slot (document open, page open/close, field on-focus/on-blur/ on-calculate, etc.) — the real mechanism populating the per-object action-attachment table that the pdfGetObjAction*/pdfGetActionTypeEx getters (Action Getters) read back from.

Description. Genuinely real, with a notable cross-feature side effect: ObjType = 0 (document) also drives the catalog /OpenAction on serialization (FOpenActHandle := ActHandle) — the document-open action isn't a separate dedicated setter, it's just this function called with ObjType = 0. ObjType = 4 (field) combined with Event = 11 (oeOnCalc, the field's Calculate event) also automatically registers the field in the AcroForm /CO calculation-order array (FCalcOrder, deduplicated against re-registration) — this is the actual real population mechanism behind FCalcOrder, the array pdfSetFieldCalcOrder/pdfGetFieldCalcOrder's verified split-brain bug (Field Calculation Order, Tooltips, Captions, and Rich Text) operates on: a field only ever joins calc order by having a Calculate action attached to it via this function (or indirectly via pdfSetFieldCalcOrder's own reordering, which operates on the same array once populated).

Parameters.

Return value. 0 on success; -1 if ActHandle doesn't resolve to a real action.

C# (P/Invoke)

public static extern int pdfAddActionToObj(IntPtr IPDF, int ObjType, int @Event, uint ActHandle, uint ObjHandle);