HotXLS: Arkbeskyttelse, sideopsætning og udskrivning i Delphi

Tre grupper af regnearksindstillinger har intet at gøre med celleværdierne og alt at gøre med, hvordan filen opfører sig, når den forlader din kode. Arkbeskyttelse afgør, hvilke celler en bruger kan redigere, efter du har afleveret arbejdsbogen. Sideopsætning fastlægger retning, papirstørrelse og margener. Udskriftsindstillingerne (gentagne titelrækker, skalering og manuelle sideskift) styrer, hvordan et gitter af vilkårlig længde havner på papir. Ingen af de tre viser sig, når du kigger på dataene i en fremviser, og alle tre går stille i stykker ude i felten, når de er forkerte. HotXLS, et indfødt Delphi- og C++Builder-regnearksbibliotek, eksponerer hele overfladen for .xls og .xlsx, hvilket betyder, at det også genskaber enhver kontraintuitiv Excel-regel, der er bagt ind i den overflade

Den første af disse regler snubler næsten alle over, første gang de beskytter et genereret ark. Kald Protect, og pludselig kan ingen skrive i nogen celle, heller ikke de inputkolonner, arbejdsbogen er bygget op omkring. Intet i din kode rørte de kolonner, og det er netop derfor, det sker

Hver celle fødes låst

ECMA-376 definerer locked som en del af en celles formateringspost, ikke som en egenskab ved selve beskyttelsen, og standardværdien er true. Arkbeskyttelse er blot den kontakt, der gør flaget håndhæveligt. Så hele gitteret bærer et låseflag fra det øjeblik, det opstår, sovende, og kaldet til Protect aktiverer dem alle på én gang. Løsningen er at fastlægge rækkefølgen bevidst: byg layoutet, lås eksplicit de områder op, brugerne skal redigere, og beskyt til sidst

Book := TXLSXWorkbook.Create;
try
  Sheet := Book.Sheets.Add('Timesheet');
  // ... overskriftsrække, navnekolonne og satsformler skrevet her ...
  Sheet.Range['B2:B50'].SetLocked(False);         // medarbejdere indtaster timer her
  Sheet.Range['F2:F50'].SetFormulaHidden(True);   // hold satsberegningen privat
  Sheet.Protect('review-2026');                   // nu bider låseflagene
  Book.SaveAs('timesheet.xlsx');
finally
  Book.Free;
end;

SetFormulaHidden gør noget andet, som er let at overse: mens beskyttelsen er aktiv, viser cellen stadig sin beregnede værdi, men formellinjen viser intet. Det betyder noget, når en formel indlejrer faktureringssatser, marginer eller vægtninger, du hellere vil undgå at give videre til enhver modtager, der klikker på en sum. På XLS-facaden udtrykkes den samme hensigt pr. område via IXLSRange.Locked og FormulaHidden. Regnearket der bærer også femten Allow*-flag (AllowSort, AllowAutoFilter, AllowFormatCells og resten), så et beskyttet ark stadig kan sorteres og filtreres i stedet for at blive frosset til en forseglet udstilling

Hvad beskyttelsesadgangskoden rent faktisk beskytter

Begge formater gemmer adgangskoden til ark- og arbejdsbogsbeskyttelse som en ældre 4-cifret hex-hash. Seksten bit betyder, at utallige strenge kolliderer med en given adgangskode, og fjernelsesværktøjer er kun en søgning væk. Betragt beskyttelse som en sikkerhedssele mod utilsigtede redigeringer, ikke som adgangskontrol. Det er det rette værktøj til at forhindre reviewere i at skrive over formelkolonnen og det forkerte værktøj til alt, der involverer ordet fortroligt

Et niveau højere oppe låser ProtectWorkbook på XLSX-facaden arbejdsbogens struktur, hvilket forhindrer tilføjelse, omdøbning, sletning eller omrokering af ark. Sæt det, når arklisten i sig selv er en kontrakt med en downstream-parser, der indekserer ark efter navn eller position. Et omdøbt ark ødelægger importen i den anden ende lige så sikkert som en slettet kolonne gør. XLS-facaden spejler lagdelingen med TXLSWorkbook.Protect på arbejdsbogniveau og pr.-ark Protect-kald, plus en isProtected-egenskab til kode, der skal inspicere en arvet fil, før den ændrer noget som helst

Når kravet er reel fortrolighed, skifter mekanismen fuldstændigt. SaveAsEncrypted producerer en AES-krypteret pakke under ECMA-376 Standard Encryption-skemaet, som er dækket i dybden i guiden til AES-beskyttet XLSX-output, og den ældre XLS-facade skriver og læser RC4-krypterede .xls-filer via EncryptionPassword og den adgangskodebaserede overload af Open. Forskellen er ikke akademisk. Et beskyttet ark rejser i klartekst, så ethvert zip-værktøj kan læse dets celleværdier, mens en krypteret pakke er ulæselig uden adgangskoden. En revisionslinje, der siger "lønfilen skal beskyttes", betyder næsten altid kryptering, uanset hvilket ordforråd den bruger

Sideopsætning er en del af dokumentkontrakten

Udskriftsadfærd er usynlig på skærmen, hvilket er grunden til, at den så ofte leveres i stykker. I det øjeblik en kunde udskriver arbejdsbogen eller eksporterer den til PDF til en revisor, bliver margener, skalering og gentagne titler til funktionelle krav, som ingen har testet. På XLSX-facaden hænger disse indstillinger direkte på regnearket:

Sheet.PageLandscape := True;
Sheet.PaperSize := xlsxPaperA4;
Sheet.SetPageMargins(0.5, 0.5, 0.75, 0.75, 0.3, 0.3);
Sheet.CenterHeader := 'Monthly Timesheet';
Sheet.RightFooter := 'Page &P of &N';
Sheet.PrintArea := '$A$1:$F$60';     // ren reference: intet arknavn her
Sheet.PrintTitleRows := '$1:$1';     // overskriftsrækken gentages på hver side
Sheet.FitToWidth := 1;
Sheet.FitToHeight := 0;              // vokser nedad, efterhånden som dataene vokser
Sheet.PrintGridlines := False;

To af disse linjer skjuler fælder. Header- og footer-strengene bruger Excels formateringskoder: &P for den aktuelle side, &N for det samlede antal, med &L, &C og &R til at adressere de tre sektioner eksplicit. Den anden fælde er PrintArea, som med vilje tager en ren cellereference. HotXLS gemmer den ukvalificeret og sætter arknavnet foran, når filen skrives, så hvis du selv angiver 'Timesheet!$A$1:$F$60', opstår en dobbelt kvalificeret, fejlformet reference. Samme forsigtighed gælder et lag længere nede: udskriftsområder og -titler gemmes som de indbyggede definerede navne _xlnm.Print_Area og _xlnm.Print_Titles, så tilføj aldrig _xlnm.*-poster gennem DefinedNames manuelt, ellers vil de to mekanismer kæmpe om den samme plads

Skalering, der overlever produktionens datamængder

Kombinationen FitToWidth := 1 med FitToHeight := 0 læses som "tilpas altid kolonnerne på tværs af én side, og tag derefter lige så mange sider ned, som dataene kræver," og det er standardvalget for enhver rapport, hvor antallet af rækker varierer. Fælden er at justere en fast procentsats eller et fit-to-page-par mod en testfil med tredive rækker: fodrer man de samme indstillinger med seks hundrede produktionsrækker, eksploderer output enten til et par dusin beskårne sider eller krymper under læsbarhed. Skalér bredden, lad længden vokse, og gentag overskriftsrækken via PrintTitleRows, så side sytten stadig kan læses for sig selv

Manuelle sideskift følger den samme regenereringsdisciplin som alt andet i en genereret arbejdsbog. AddRowBreak(BeforeRow) starter en ny side før en sektionsgrænse, men når generatoren kører igen, og rækkerne rykker sig, havner et forældet sideskift midt i tabellen. Kald ClearAllPageBreaks først, og tilføj derefter sideskift beregnet ud fra generatorens egne rækketællere i stedet for at rette gamle positioner til. På XLS-facaden findes de tilsvarende kontroller på Sheet.PageSetup (retning, papirstørrelse, margener, header- og footer-strenge, fit-to-pages), med RepeatRows og RepeatColumns, der dækker udskriftstitlerne

Kontroller resultatet, før kunden gør det

Beskyttelses- og udskriftsfejl deler én egenskab: de er trivielle at verificere manuelt og bliver næsten aldrig verificeret. Åbn den genererede fil i Excel, og brug halvfems sekunder på den. Skriv i en inputcelle, og bekræft, at den accepterer tastetrykket; skriv i en låst celle, og bekræft, at beskyttelsespromptet vises; tjek, at en skjult formel efterlader formellinjen tom. Kør derefter Vis udskrift mod et datasæt i produktionsstørrelse, ikke en stikprøve på tredive rækker, og aflæs sideantallet, den gentagne titelrække og footer-nummereringen. Forhåndsvisningen er det trin, der betaler sig selv hjem, fordi udskriftsgeometrien afhænger af indstillinger uden nogen visning på skærmen, og uden en fysisk printer er det det eneste sted, en skaleringsfejl nogensinde bliver synlig

Én sidste indstilling runder gennemgangen af. FreezePane(ACol, ARow) holder headerblokken synlig, mens en reviewer scroller. Det er skærmadfærd snarere end udskriftsadfærd, men en reviewer bedømmer hele leverancen på én gang. Og en arbejdsbog, der starter livet som et designerholdt layout, får det meste af dette gratis: workflowet til skabelonbaseret rapportgenerering holder sideopsætningen i skabelonen, hvor et menneske har justeret den mod en rigtig printer, og overlader til koden at udfylde dataene og genanvende beskyttelsen, når layoutet har sat sig

HotXLS er et indfødt Object Pascal-regnearksbibliotek til Delphi og C++Builder; den fulde API-reference for beskyttelse og sideopsætning findes på HotXLS Delphi Component-produktsiden