Yhden laskentataulukon patchaus suuressa XLSX-tiedostossa Delphistä

HotXLS pystyy kirjoittamaan yhden laskentataulukon uudelleen olemassa olevan XLSX-paketin sisällä jäsentämättä tai pakkaamatta uudelleen tiedoston muuta osaa. TXLSDirectWriter.BeginPatch avaa lähdepaketin, kopioi jokaisen merkinnän kohdetaulukkoa lukuun ottamatta sellaisenaan pakattuine tavuineen, ja antaa kirjoittaa tämän yhden taulukon uudelleen tavallisten AddSheet-, AddRow- ja Write*-kutsujen kautta. Kaavioita, pivot-välimuisteja, teemoja, tyylejä ja jaettuja merkkijonoja ei koskaan puraeta

Työnkulku, jonka tämä ratkaisee, ilmenee raportoinnissa ja datan päivityksessä. Työkirja saapuu liiketoimintatiimiltä kantaen pivot-taulukoita, viipaloijia, ehdollisia muotoiluja ja vuosikymmenen kertynyttä muotoilua. Joka yö yksi datataulukko täytyy korvata tuorein luvuin. Koko työkirjan lataaminen ja uudelleentallentaminen maksaa minuutteja tiedostoa kohden, ja mikä tärkeämpää, vaarantaa uskollisuuden ominaisuuksissa, jotka latausmoottorin täytyy rakentaa uudelleen. Patchaus kiertää molemmat ongelmat koskematta siihen, mihin sen ei tarvitse koskea

Miksi pakattujen tavujen kopiointi on kiinnostava osa?

Zip-merkintä, joka kopioidaan pakatulla tasolla, maksaa vain virtakopion. Sama merkintä, joka kulkee tavallisen kirjoituspolun läpi, maksaa purun sisääntulossa ja pakkauksen ulostulossa, ja pakkaus on kallis puolisko. Työkirjassa, jossa on suuri pivot-välimuisti ja muutama tusina upotettua kuvaa, tämä ero on ero patchin, joka valmistuu siinä ajassa, joka kuluu uuden taulukon kirjoittamiseen, ja patchin, joka käyttää suurimman osan ajastaan pakatakseen uudelleen tavuja, joita se ei koskaan tutkinut

HotXLS käyttää tähän metodia CopyCompressedFrom, joka kirjoittaa lähdemerkinnän pakatut tavut suoraan kohdearkistoon. Kun merkintää ei voida kopioida tällä tavoin, koska se käyttää eri pakkausmenetelmää tai heikkoa salausta, kirjoitin palaa puretun virran kopiointiin epäonnistumisen sijaan. Hakemistomerkinnät ohitetaan, koska kirjoitin tuottaa omansa

Korvaa paikallaan tai kirjoita uuteen tiedostoon

Kaksi ylikuormitettua metodia kattavat kaksi muotoa, joita tämä tehtävä voi saada. Paikallaan tapahtuva muoto valmistelee tuloksen väliaikaistiedostoon alkuperäisen viereen, sulkee lähdekahvan, sitten poistaa ja nimeää uudelleen, joten kesken kirjoituksen tapahtuva kaatuminen jättää alkuperäisen koskemattomaksi. Nimenomaisen kohteen muoto jättää lähteen koskemattomaksi ja voi joko korvata taulukon tai liittää uuden:

var
  W: TXLSDirectWriter;
begin
  W := TXLSDirectWriter.Create;
  try
    W.BeginPatch('monthly-dashboard.xlsx', 'Data');   // paikallaan
    W.AddSheet('Data');
    W.AddRow(1);
    W.WriteString(1, 'Region');
    W.WriteString(2, 'Revenue');
    W.AddRow(2);
    W.WriteString(1, 'North');
    W.WriteNumber(2, 184320.55);
    W.AddRow(3);
    W.WriteFormula(1, '=SUM(B2:B2)');
    W.Close;
  finally
    W.Free;
  end;
end;

Lisäysmuunnelma ottaa lähde- ja kohdepolun sekä InsertSheet-lipun:

  // Lähde pysyy koskemattomana; kohde saa ylimääräisen laskentataulukon nimeltä Extra
  W.BeginPatch('template.xlsx', 'output.xlsx', 'Extra', True);
  W.AddSheet('Extra');
  W.AddRow(1);
  W.WriteString(1, 'appended by the nightly job');
  W.Close;

Lisääminen on osa, joka vaatii todellista kirjanpidollista kirurgiaa. Kirjoitin jäsentää taulukkorekisterin tiedostossa xl/workbook.xml ja suhdekartan, joka sitoo kunkin taulukon sen osaan, ja valitsee sitten seuraavan vapaan osanumeron, taulukkotunnisteen ja suhdetunnisteen. Suhdetyypit noudattavat lähdepaketin käytäntöjä, joten tiukan ISO 29500 -työkirjan patchaus tuottaa tiukkoja suhdetyyppejä ja siirtymäkauden työkirjan patchaus tuottaa siirtymäkauden tyyppejä

Mitä patch tarkoituksella pudottaa ja rajoittaa

Laskentaketju hylätään molemmissa tiloissa. Korvaustilassa sen merkinnät kuvaavat soluja taulukossa, jota ei enää ole olemassa tuossa muodossa; lisäystilassa taulukkoindeksin siirtymä mitätöi sen suoralta kädeltä. Excel rakentaa ketjun uudelleen seuraavassa uudelleenlaskennassa, joten sen pudottaminen on oikein, ei häviöllistä. Osa jätetään kopioinnin ulkopuolelle, ja sen suhdemerkintä sekä sisältötyypin ohitus poistetaan kirurgisesti

Kaksi kirjoitussemantiikkaa muuttuu patchin sisällä, ja molemmat seuraavat samasta periaatteesta: patch ei saa häiritä osia, joita se ei kirjoittanut uudelleen. Merkkijonot kirjoitetaan suoraan taulukkoon jaettuun merkkijonotauluun lisäämisen sijaan, koska lähdetaulu siirtyy koskemattomana. Ja StyleIndex viittaa merkintöihin lähdepaketin cellXfs-taulussa, ei tauluun, jonka kirjoitin rakentaa. Tämä tarkoittaa, että voit viitata muotoihin, jotka alkuperäinen työkirja jo määrittelee, mikä on yleensä juuri sitä, mitä datan päivitys haluaa, mutta se tarkoittaa myös, että sinun täytyy tietää, mikä indeksi kantaa mitäkin muotoa

// Patchin sisällä StyleIndex indeksoi LÄHDEPAKETIN cellXfs-taulua.
// Päivämäärä tarvitsee eksplisiittisen indeksin, joka kuvautuu siellä päivämäärämuotoon:
W.WriteDateTime(3, EncodeDate(2026, 8, 22), DateStyleIndexFromTemplate);

// Tyylitön WriteDateTime-ylikuormitus hylätään patch-tilassa,
// koska se olettaa kirjoittimen omaa tyylitaulua, jota patch
// ei koskaan luo

Kuusi kirjoituksen sisäänmenopistettä on portitettu: taulukoiden, kaavioiden, kuvien, kommenttien, nimettyjen alueiden ja solutyylien lisääminen nostavat kaikki poikkeuksen patch-tilassa, ja toinen varmuusverkko sulkemishetkellä epäonnistuu, jos jokin niiden laskureista on nollasta poikkeava. Jokainen näistä ominaisuuksista vaatisi sellaisten osien muokkaamista, jotka patch kopioi sellaisenaan, ja puoliksi muokattu paketti on pahempi kuin evätty toiminto. Täsmälleen yksi taulukko voidaan patchata yhtä toimintoa kohden

Milloin patchata ja milloin ladata

Patchaus on oikea työkalu, kun työkirja on suuri, muutos rajoittuu yhteen taulukkoon, ja tiedoston muun osan täytyy säilyä bitilleen samana. Se on väärä työkalu, kun muutos ulottuu useisiin taulukoihin, kun tarvitaan uutta muotoilua tai uusia objekteja, tai kun tiedosto on tarpeeksi pieni, jotta tavallinen lataus ja tallennus eivät maksa mitään. Tyhjästä tehtävään massatuotantoon suoratoistopolku, joka kuvataan artikkelissa suoratoistava suora kirjoitin, on edelleen parempi valinta, ja se jakaa saman AddRow- ja Write*-API:n, joten siirtyminen näiden kahden välillä on mekaanista

Taulukkotason käsittely ladatun työkirjan sisällä, kun todella haluat koko objektimallin, käsitellään artikkelissa laskentataulukoiden monistaminen XLSX-paketeissa. Ja jos syy patchin harkitsemiseen on se, että koko työkirjan käsittelystä on tullut hidasta, mittaukset ja muistikäyttäytyminen artikkelissa suuren työkirjan suorituskyky kannattaa lukea ennen lähestymistavan valintaa

Sen todentaminen, että patch todella teki, mitä luulit

Kolme tarkistusta poimivat lähes jokaisen virheen. Varmista, että osat, joiden odotit säilyvän, ovat yhä arkistossa, että xl/calcChain.xml on poissa, ja että tiedoston avaaminen uudelleen luokan TXLSXWorkbook kautta raportoi odottamasi taulukkomäärän, muuttumattomana korvauksessa ja yhdellä kasvatettuna lisäyksessä. Patchatun taulukon takaisinlukeminen ja muutamien arvojen sekä kaavojen vertaaminen sulkee silmukan

Yksi tämän ominaisuuden kehityksestä peräisin oleva toteutusyksityiskohta ansaitsee toistamisen, koska se voi puraista ketä tahansa, joka kirjoittaa vastaavaa zip-tason koodia. Laskentataulukko-osien nimet täsmätään etuliitteen perusteella, ja yhden verran väärä etuliitteen pituus tarkoittaa, ettei predikaatti koskaan täsmää, joten vastikään kirjoitettu osa törmää olemassa olevaan nimeen, ja lukijat, jotka ottavat viimeisen merkinnän tietyllä nimellä, valitsevat hiljaisesti väärän taulukon. Jos patch näyttää vaihtavan kahden taulukon sisällöt keskenään, katso ensin nimien täsmäytystä ennen XML:n tarkastelua

Paikallaan patchaus, suoratoistokirjoitukset ja koko työkirjan objektimalli toimitetaan samassa kirjastossa Delphille ja C++Builderille; ominaisuusluettelo on sivulla HotXLS Delphi -laskentataulukkokomponentin sivulla