A feltételes formázási szabály az OOXML-ben két külön dolog, amely egy nevet visel. A feltétel (egy összehasonlítás, egy képlet, egy szövegilleszkedés) dönti el, mely cellák felelnek meg. A megjelenés (egy differenciális formátumrekord, ECMA-376 szóhasználatban dxf) dönti el, hogy ezek a cellák hogyan néznek ki. Az Excel párbeszédpanele elrejti a varratot azzal, hogy mindkettőt egyszerre tölteti ki Önnel. A HotXLS nem. Hozzon létre egy cellIs szabályt Delphiből, és hagyja ki a stílust: a szabály érvényes lesz, a tartomány helyes, a képlet pontosan a megfelelő cellákon értékelődik igazra, és semmi nem vált színt, mert a szabály utasítása az volt, hogy „igaz, ne fess semmit”. A feltétel és a következmény közötti rés az első dolog, amit el kell találni, és ez okozza a legtöbb olyan szabályt, amely a Szabályok kezelése panelen helyesnek látszik, mégsem emel ki semmit
A HotXLS natívan írja a feltételes formázást mind a BIFF8 .xls, mind az OOXML .xlsx fájlokba, és ugyanezt teszi a rich text futamokkal és a készletalapú cellastílus-modellel. A három képesség több vezetéken osztozik, mint amennyit a lapos API-felület sugall, és azok a helyek, ahol a kimenet elsodródik a szándéktól, rendszerint a közöttük lévő illesztések
A feltételhez következmény kell: a dxf stílus
Az XLSX munkalapon az összehasonlító szabályok az AddConditionalFormat hívásból származnak, amely egy tartományt, egy operátort a TXLSXCfOperator felsorolásból és egy képletet vagy literált vár, majd visszaadja az új szabály indexét a lap ConditionalFormats gyűjteményében. Az adott indexen álló szabályobjektum elérhetővé tesz egy Style tulajdonságot, és ott lakik a kiemelés. Állítson be rajta kitöltést, és a megfelelő cellák megkapják a kitöltést. Hagyja érintetlenül, és a fent leírt láthatatlan szabályt építette meg
var
Book: TXLSXWorkbook;
Sheet: TXLSXWorksheet;
Idx: Integer;
begin
Book := TXLSXWorkbook.Create;
try
Book.Open('kpi.xlsx');
Sheet := Book.Sheets[0];
// Negatív eltérés: világospiros kitöltés
Idx := Sheet.AddConditionalFormat('D2:D200', xlsxCfOpLessThan, '0');
Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($FFFFC7CE);
// Az ismétlődő rendelésazonosítók ugyanígy kapnak jelölést
Idx := Sheet.AddCondFormatDuplicateValues('A2:A200');
Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($FFFFEB9C);
// Egyedi képletszabály: azok a sorok kiemelése, ahol a tény a cél 90%-a alatt marad
Idx := Sheet.AddCondFormatExpression('B2:B200', '$C2<$B2*0.9');
Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($FFFFC7CE);
Book.SaveAs('kpi-flagged.xlsx');
finally
Book.Free;
end;
end;
A színek itt 32 bites ARGB értékek, tehát az $FFFFC7CE az a „világospiros”, amelyet a párbeszédpanelről ismer, egy teljesen átlátszatlan alfa-bájttal az RGB előtt. Minden cellánkénti feltételre tüzelő szabályfajta ugyanezt a létrehozás-majd-stílusozás alakot követi. A szövegilleszkedők (AddCondFormatContainsText, AddCondFormatBeginsWith, AddCondFormatEndsWith) olyan indexet adnak vissza, amelyet utólag stílusoz, és ugyanígy tesz az AddCondFormatTop10, az AddCondFormatAboveAverage, valamint az üres- és hibafelismerők is. Tanulja meg egyszer a mintát, és az egész szöveges és összehasonlító család ugyanúgy viselkedik
Az adatsávok, a színskálák és az ikonkészletek maguk festik magukat
A vizuális szabályfajták fordítva működnek. A megjelenésüket magában a szabálydefinícióban hordozzák, és teljesen figyelmen kívül hagyják a Style tulajdonságot. Rendeljen kitöltést egy adatsáv-szabályhoz, és semmi nem történik, ami hibának olvasódik, amíg a rendszertan a helyére nem kattan: az AddCondFormatDataBar a sáv színét közvetlen argumentumként veszi át, a két- és hárompontos színskálák ugyanígy kapják a végpontszíneiket, az AddCondFormatIconSet pedig 26 ikonkészlet-típus egyikét választja ki, például az icsTrafficLights3 értéket. Itt nincs külön stílusrekord, amelyet elfelejthetne, mert egyáltalán nincs külön stílusrekord
Az ezeken a hívásokon átgondolásra érdemes paraméterek az értékhorgonyok, amelyek típusa TXLSCfValueKind. Egy sáv vagy skála végpontja ülhet a tartomány minimumán vagy maximumán, egy konkrét számon, egy százalékos vagy percentilis értéken, vagy egy képlet eredményén. Az alapértékek, a tartomány minimuma és maximuma, rendben viselkednek a rendezett demóadatokon, aztán elárulják Önt a kiugró értékeket tartalmazó valódi adatokon: egyetlen elszabadult érték széthúzza a skálát, és minden más sávot csonkká lapít. Ha egy irányítópultot időszakok között kell összehasonlítani, a végpontokat inkább rögzített számokhoz vagy percentilisekhez horgonyozza, hogy a márciusi félsáv ugyanazt a mennyiséget jelentse, mint az áprilisi félsáv. Az automatikusan skálázott sáv csak önmagával összehasonlítható
Az XLS író négy szabályfajtát fed le, többet nem
A régi BIFF8 oldal nem az XLSX oldal kicsinyített tükre, hanem szándékos részhalmaz. Az XLS homlokzat pontosan négyféle feltételes szabályalakot tud létrehozni — adatsávokat, kétszínű skálákat, háromszínű skálákat és ikonkészleteket —, amelyeket CF12 rekordként bocsát ki az adatfolyamba. Nincs létrehozó API-ja a cellIs, a képlet- és a szövegszabályokhoz. Az ilyen fajtájú szabályok, amelyek már ott vannak egy megnyitott fájlban, beolvasódnak, megmaradnak, és változatlanul íródnak vissza, tehát egy ügyfél .xls fájljának megnyitása és újramentése soha nem rontja el a benne hozott formázást. Amit nem tehet meg, az a küszöbalapú kiemelés nulláról való generálása egy .xls fájlba. Itt a választás az, hogy kódban kiszámított közönséges cellakitöltésekkel utánozza, vagy .xlsx formátumot tesz a leszállítandó eredménnyé, ahol a teljes szabálycsalád az asztalon van
Ezt a megkötést az adatréteg megléte előtt kell eldönteni, nem utána, mert megváltoztatja a fájlformátumra vonatkozó döntést mindenben, aminek irányítópult alakja van. Az a csapat, amely kompatibilitás miatt választott .xls formátumot, majd cellIs küszöbökkel specifikál egy KPI-jelentést, két olyan dolgot választott, amelyek nem illenek össze, és olcsóbb ezt a formátumdöntésnél észrevenni, mint az építés harmadik hetében
Szabályok egymásra rétegzése, prioritás és átfedő tartományok
A valódi irányítópultok ritkán futtatnak egyetlen szabályt tartományonként. Egy eltérésoszlop hordozhat adatsávot a nagyságrendhez, cellIs szabályt a kemény küszöbhöz, és mindkettő fölött sorszintű képletszabályt az eszkalációkhoz. Minden TXLSXConditionalFormat elérhetővé tesz egy Priority értéket, és az Excel prioritási sorrendben oldja fel a versengő szabályokat. Amikor két szabály ugyanazt a cellát akarja festeni, a győztest egy Ön által beállított szám dönti el, nem az a sorrend, amelyben egy lektor éppen végiggörget a Szabályok kezelése párbeszédpanelen
Kezelje a prioritást úgy, ahogy egy rajzolóprogram a z-sorrendet. Adja meg szándékosan mindenütt, ahol két szabály elérheti ugyanazokat a cellákat, és hagyjon hézagokat az értékek között, hogy egy későbbi szabály beilleszthető legyen a többi átszámozása nélkül. Ahol a szabályok nem ütközhetnek — mondjuk egy E oszlopra korlátozott adatsáv és egy G oszlopra korlátozott szövegszabály —, ott a létrehozási sorrend megfelelő, és a prioritás nem éri meg a figyelmet. Azt a figyelmet inkább a tartományhatárokra fordítsa, mert az itteni drága hibák szinte soha nem prioritási inverziók. Hanem olyan tartományok, mint a B2:B200 egy 350 sorosra nőtt jelentésen, ahol a lefedetlen farok sima cellákként jelenik meg, amelyek pontosan úgy néznek ki, mint az egészséges adat. Minden szabálytartományt ugyanabból a végleges sorszámból származtasson, amely a munkafüzet más pontjain a diagram-adatsorokat és az érvényesítési tartományokat is hajtja, és a farok többé nem esik le
Egy ellenőrzési szokás megszolgálja a helyét. Generálás után nyissa meg a fájlt Excelben, jelölje ki a formázott tartományt, és minden sablonváltozásnál járja végig egyszer a Szabályok kezelése panelt. A feltételes formázás azon kevés terület egyike, ahol az egyetlen mérvadó renderelő maga az az alkalmazás, amely a fájlt fogyasztja, tehát az XML-re írt egységteszt azt bizonyítja, hogy a szabály kiíródott, nem azt, hogy az Excel úgy festi, ahogy Ön szerette volna. Egy percnyi szemrevételezés bezárja ezt a rést
Rich text: több formátum egyetlen cellán belül
Az XLSX modellben a rich text cella futamok listáját tartja, ahol minden futam egy szövegszakasz a saját betűtípus-attribútumaival. A listát félretéve építi fel egy TXLSXRichText objektumként, futamokat ad hozzá, majd az egészet egy cellához csatolja. A tulajdonjogi szabály az a rész, amely harap. A Cell.RichText tulajdonságnak való értékadás átadja az objektum tulajdonjogát a cellának, és a cella a saját megsemmisülésekor felszabadítja. Ha Ön is felszabadítja, dupla felszabadítást kap — azt a fajtát, amely csendben marad a kiváltó futás alatt, és jóval később, valahol egészen máshol bukkan fel összeomlásként
var
Rich: TXLSXRichText;
Run: TXLSXRichTextRun;
begin
Rich := TXLSXRichText.Create;
Rich.AddRunText('Status: ');
Run := Rich.AddRunText('OVERDUE');
Run.Bold := True;
Run.Color := $FFC00000;
Run.ColorIsAuto := False;
Run := Rich.AddRunText(' (escalated to regional manager)');
Run.Italic := True;
Sheet.Cells[2, 7].RichText := Rich; // a tulajdonjog a cellához kerül: ne hívjon Free-t
end;
A kifejezett ColorIsAuto := False nem elhagyható díszítés. A futam automatikus szín jelzőt hordoz, és a színbeállítás csak akkor érvényesül, ha ez a jelző törölve van. Állítsa be a Color értéket, és felejtse el a ColorIsAuto jelzőt, és a futam félkövéren, de makacsul feketén jön ki, minden olyan hibaüzenet nélkül, amely az okra mutatna. A futamok támogatják az áthúzást, az aláhúzás változatait, valamint a felső és alsó indexhez tartozó függőleges igazítást, míg a PlainText az egész listát egyetlen karakterlánccá lapítja vissza, amikor a szöveges tartalmat exportálnia vagy összehasonlítania kell
A cellaszintű rich text kizárólag XLSX. Az XLS homlokzatnak nincs nyilvános API-ja az írására, bár a futamok ott a megjegyzéseken és a szövegdobozokon a TextRuns gyűjteményen keresztül elérhetők, és a meglévő .xls fájlból beolvasott rich stringek épségben túlélik a körutat. A vonzás ugyanaz, mint a feltételes formázásnál: minden, ami egy cellán belül kever formátumokat, az XLSX íróba való
A stíluskészlet és az eggyel elcsúszás, amely kikerül a felhasználókhoz
Az XLSX modellben a sima cellastílusozás a munkafüzeten lévő készletgyűjteményeken keresztül fut. A Fonts.Add, a Fills.AddSolid és a Borders.Add mind regisztrál egy definíciót, és visszaadja annak indexét a készletben. Ezek az indexek 0-alapúak. Az őket fogyasztó cellaoldali tulajdonságok, például a FontIndex, a 0 értéket az „alapértelmezett” számára tartják fenn, tehát a cellához rendelt érték a készletindex plusz egy:
HeaderFont := Book.Fonts.Add('Calibri', 11, True, False); // készletindex, 0-alapú
for Col := 1 to 6 do
Sheet.Cells[1, Col].FontIndex := HeaderFont + 1; // cellaindex, 1-alapú
Hagyja el a + 1 tagot, és minden fejléc az alapértelmezett betűtípusra esik vissza. Nincs kivétel és nincs figyelmeztetés, csak egy olyan munkafüzet, amely úgy néz ki, mintha senki nem stílusozta volna. A másodlagos hiba a ciklusban rejtőzik: a Fonts.Add soronkénti meghívása. Az azonos betűtípus-definíciók deduplikálódnak, tehát a fájl nem sérül meg, de a munka kárba vész, és különösen az igazítási készlet ad vissza minden híváskor friss objektumot ahelyett, hogy összevonná a duplikátumokat. Építse fel azt a néhány stílust egyszer a ciklus előtt, és használja újra az indexeiket. Százezer soros jelentéseken ez az egyetlen változtatás azon karok egyike, amelyeket a HotXLS nagy munkafüzetekre szabott teljesítményhangolása tárgyal. Amikor csak egy készen kapott, jelentéshordozó megjelenésre van szüksége, mindkét homlokzat elérhetővé teszi tartományokon az ApplyBuiltinStyle metódust, amely az Excel beépített Good, Bad, Neutral és kiemelő stílusaira képez le anélkül, hogy a készletekhez hozzányúlna
A feltételes formázás, a rich text és a készletalapú stílusok egy jelentés utolsó métere, amely az adatmodell és az elrendezés lezárása után kerül alkalmazásra, és ezekkel a korábbi szakaszokkal a sablonalapú jelentésgenerálás a HotXLS-szel foglalkozik. A teljes szabály-, futam- és stílusreferencia a HotXLS Delphi Component termékoldalán található