HotPDF, harici bir PDF runtime kurmadan doğrudan PDF oluşturma ve düzenleme, formlar, notlar, şifreleme, dijital imzalar, Unicode yazı tipleri, standart odaklı çıktı ve preflight raporları gereken Delphi ve C++Builder uygulamaları için yerel bir VCL PDF kütüphanesidir.
Bu yazı developers replacing hand-edited PDF forms with deterministic Delphi form generation için hazırlanmıştır. AcroForm fields and action logic konusunu tek bir bileşen çağrısı olarak değil, üretim düzeyinde belge mühendisliği olarak ele alır.
Pratik risk şudur: field widgets can look correct while shared names, export values, JavaScript actions, tab order, or flattening rules break the receiving workflow. Bu nedenle akışın yazılı sözleşmeye, gözlemlenebilir tanılara ve gerçekçi regresyon dosyalarına ihtiyacı vardır.
Mimari kararlar
Treat the field map as an application contract. field naming rules for repeated widgets and grouped business values / allowed trigger actions, submit targets, and viewer-side script policy
- field naming rules for repeated widgets and grouped business values
- allowed trigger actions, submit targets, and viewer-side script policy
- required flags, default values, calculation order, and validation messages
- whether the output remains interactive or is flattened for archive delivery
Uygulama akışı
Build the form layer before assigning values. The order below keeps the workflow reviewable for Delphi and C++Builder teams.
- inventory the template fields and normalize names before binding application data
- apply values only after the allowed action profile has been selected
- refresh widget appearances with the same font and color policy used at design time
- validate exported values and tab order in the same viewer family used by customers
- flatten only after all required-field and calculation checks have passed
Doğrulama kanıtı
Evidence that proves the form is usable. Keep these fields with the output or support record.
- field name, widget bounds, page number, required state, and exported value
- action type, trigger event, destination, and whether the profile allowed it
- appearance stream status, font fallback decision, and calculated-field result
- remaining interactive fields after flattening and warnings for unsupported actions
Appearance streams, actions, and flattening order
A production form workflow separates field creation, value assignment, appearance refresh, action binding, and final flattening. Keeping those phases visible makes it possible to explain why a required field failed or why a submit action was suppressed.
Decision table for AcroForm fields and action logic
A decision table keeps product ownership visible when the same workflow is reused by a desktop tool, service job, and support utility.
| Decision | Engineering reason | Evidence |
|---|---|---|
| field naming rules for repeated widgets and grouped business values | inventory the template fields and normalize names before binding application data | field name, widget bounds, page number, required state, and exported value |
| allowed trigger actions, submit targets, and viewer-side script policy | apply values only after the allowed action profile has been selected | action type, trigger event, destination, and whether the profile allowed it |
| required flags, default values, calculation order, and validation messages | refresh widget appearances with the same font and color policy used at design time | appearance stream status, font fallback decision, and calculated-field result |
Engineering review notes for AcroForm fields and action logic
Use these review notes to make sure the feature has moved beyond a demo and can be defended during release, support, and customer escalation.
- Decision: field naming rules for repeated widgets and grouped business values. Implementation pressure point: apply values only after the allowed action profile has been selected. Acceptance evidence: appearance stream status, font fallback decision, and calculated-field result. Regression trigger: flattening before validation can permanently hide incomplete or inconsistent data
- Decision: allowed trigger actions, submit targets, and viewer-side script policy. Implementation pressure point: refresh widget appearances with the same font and color policy used at design time. Acceptance evidence: remaining interactive fields after flattening and warnings for unsupported actions. Regression trigger: checkbox captions do not always match the export values consumed by external systems
Sınır durumları
- checkbox captions do not always match the export values consumed by external systems
- identically named fields may intentionally share one value across several pages
- viewer security settings can block actions that worked during development
- flattening before validation can permanently hide incomplete or inconsistent data
Delphi / C++Builder notes
HotPDF Component should sit behind a small service boundary that receives files, streams, profiles, and credentials, then returns output paths, warnings, metrics, and validation status. Important terms include AcroForm, widget, field action, appearance stream, submit action, flattening.
Delphi kod örneği
Aşağıdaki Delphi taslağı bu konu için pratik bir servis sınırını gösterir. Politika kontrollerini, günlüklemeyi ve doğrulamayı dar ürün çağrısı bölümünün dışında tutarak akışı test edilebilir bırakın.
procedure BuildAcroFormPackage(const OutputFile: string; const Profile: TFormProfile);
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := OutputFile;
Pdf.BeginDoc;
AddCustomerFields(Pdf, Profile);
WireSubmitActions(Pdf, Profile.ActionMap);
ValidateRequiredFields(Profile.RequiredFields);
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;
Üretim kontrol listesi
- Run the workflow on an empty file, a normal customer file, and a worst-case file
- Open the generated PDF with the target viewer, validator, printer, or downstream application
- Log product version, profile version, input hash, output path, elapsed time, and warning count
- Keep passwords, certificates, temporary files, and customer data under explicit retention rules
- Add regression documents when a customer file exposes a new edge case