Notes de version HotXLS

Historique des versions pour les fonctionnalités visibles, les correctifs, les améliorations XLS/XLSX, les exports, la compatibilité et la documentation de HotXLS.

Langues : English (US)English (UK) Español (España) Español (Latinoamérica) Deutsch Français Italiano 日本語 Português Nederlands Svenska Polski Türkçe 한국어 العربية Русский 简体中文繁體中文

[Unreleased]

Version 2.88.111

Les feuilles Classic XLS prennent maintenant en charge les TextBox de dessin autonomes. Utilisez TXLSShapes.AddTextBox pour créer un TXLSTextBox avec son propre ancrage ligne/colonne, texte, text runs, mise en forme ligne/remplissage et suppression de shape normale sans créer de commentaire de cellule.

Version 2.88.110

Les demos ApiTour couvrent maintenant davantage de workflows d'automatisation de classeurs. Les exemples ApiTour Delphi et C++Builder montrent l'écriture de plages par callback avec WriteCells, le parcours des cellules chargées avec ForEachCell, les mises à jour de modèles avec FindText et ReplaceText, l'export HTML d'une plage sélectionnée vers ApiTour-Range.html, ainsi que les callbacks Delphi de formules personnalisées via OnUserFunction.

Version 2.88.109

Les démos QuickStart montrent désormais un premier classeur plus complet. Les exemples QuickStart Delphi et C++Builder créent une table de multiplication mise en forme avec formules de totaux par ligne et colonne, volets figés et actions XLS/XLSX alignées ; l'arborescence des démos inclut aussi des pages readme HTML soignées pour chaque exemple.

Version 2.88.108

Les plages XLSX disposent maintenant d'assistants d'export HTML directs. TXLSXRange.SaveAsHTML(FileName) et TXLSXRange.SaveAsHTML(Stream) exportent uniquement la plage XLSX sélectionnée sous forme de table HTML UTF-8, en partageant l'échappement, la sortie de style de base et la gestion des spans de cellules fusionnées du renderer HTML du workbook.

Version 2.88.107

Les feuilles de calcul XLSX disposent maintenant d'assistants de recherche et de remplacement de texte. TXLSXWorksheet.FindText et TXLSXWorksheet.ReplaceText parcourent les cellules texte chargées en ordre row-major, ignorent les formules et les valeurs non textuelles, et prennent en charge une correspondance optionnelle sensible à la casse pour les workflows de modèles.

Version 2.88.106

Les indicateurs de vue BIFF8 Window2 conservent désormais l'état de couleur de quadrillage personnalisée et de volets figés. HotXLS efface maintenant fDefaultHdr lorsque Window2.icvHdr stocke une couleur de quadrillage personnalisée, conserve fFrozenNoSplit écrit par Excel pendant open/save et écrit fFrozenNoSplit pour la sortie FreezePanes.

Version 2.88.105

Les seuils de formule CF12 sont maintenant conservés en round-trip dans les règles BIFF8 Data Bar, Color Scale et Icon Set. Les valeurs de seuil basées sur des formules sont compilées en CF12 formula token bytes lors de l'enregistrement et restaurées dans TXLSCfValue.Value à la réouverture d'un workbook.

Version 2.88.104

Les formules Classic XLS et les seuils de jeux d'icônes écrivent désormais des enregistrements BIFF8 plus compacts. Les constantes entières dans les formules utilisent le token compact tInt lorsqu'elles tiennent dans la plage BIFF unsigned-integer, et TXLSIconSetSpec.ThresholdEqualsInclude[Index] contrôle maintenant le CF12 icon-set threshold equals byte afin que l'appelant choisisse la sémantique de comparaison include ou exclude.

Version 2.88.103

Les feuilles Classic XLS disposent maintenant d'une aide de recherche de texte. IXLSWorksheet.FindText(SearchText, Row, Col[, MatchCase]) localise la première cellule texte chargée correspondante, ignore les formules et les cellules non textuelles, et remet les coordonnées renvoyées à zéro lorsqu'aucune correspondance n'est trouvée.

Version 2.88.102

Les feuilles Classic XLS disposent maintenant d'une aide de remplacement de texte. IXLSWorksheet.ReplaceText(SearchText, ReplacementText[, MatchCase]) remplace les correspondances dans les cellules texte chargées, ignore les formules et les cellules non textuelles, et renvoie le nombre de cellules modifiées pour les flux de remplissage de modèles.

Version 2.88.101

Les plages disposent maintenant d'aides directes pour l'export HTML. IXLSRange.SaveAsHTML(FileName) et IXLSRange.SaveAsHTML(Stream) exportent la plage sélectionnée avec le moteur HTML existant, ce qui évite de créer une instance TXLSHTMLExport ou de passer explicitement xlHTML pour les fragments de plage courants.

Version 2.88.100

TXLSWorkbook.GetSheetNames(Stream, AList) lit maintenant les flux de package XLSX ainsi que les flux Classic XLS. Les applications peuvent transmettre des flux mémoire, des flux BLOB de base de données ou des flux XLSX téléchargés à la façade classique et obtenir les noms de feuilles dans l'ordre sans d'abord enregistrer un fichier.

Version 2.88.99

Les APIs de recherche de feuille, de création d'hyperlien et de sélection multi-zone sont plus simples à utiliser. Les collections de feuilles Classic XLS et XLSX ajoutent TryGetSheetByName, les feuilles Classic XLS ajoutent des surcharges pratiques AddHyperlink, et IXLSWorksheet.SelectAreas peut écrire des sélections actives à plusieurs plages.

Version 2.88.98

Les classeurs Classic XLS exposent maintenant un alias UserName pour le champ d'utilisateur ayant enregistré le fichier. IXLSWorkbook.UserName pointe vers la même valeur WRITEACCESS que LastSavedBy, afin que le code utilisant la convention UserName puisse lire et mettre à jour directement le nom d'audit du classeur.

Version 2.88.97

Les feuilles XLSX partagent maintenant les helpers callback de scan de cellules et d'écriture de plage. TXLSXWorksheet.ForEachCell énumère les cellules chargées dans l'ordre des lignes avec valeur et texte de formule, tandis que TXLSXWorksheet.WriteCells remplit des plages numériques ou A1-style depuis un callback avec saut par cellule et annulation.

Version 2.88.96

Les feuilles Classic XLS prennent maintenant en charge l'écriture de plage pilotée par callback. IXLSWorksheet.WriteCells remplit une plage numérique en base 1 ou une plage A1-style dans l'ordre des lignes, laisse le callback fournir chaque valeur de cellule, prend en charge le saut cellule par cellule et peut annuler tôt les longues boucles d'écriture.

Version 2.88.95

Les feuilles Classic XLS peuvent maintenant énumérer les cellules chargées via un callback. IXLSWorksheet.ForEachCell parcourt les cellules existantes de la feuille dans l'ordre des lignes, transmet des coordonnées feuille, ligne et colonne en base 1 avec la valeur et le texte de formule, et permet au callback d'annuler rapidement les longs scans.

Version 2.88.94

Le calcul des formules peut maintenant appeler des fonctions definies par l'application. TXLSWorkbook.OnUserFunction et TXLSXWorkbook.OnUserFunction permettent a Calculate de deleguer les fonctions de feuille personnalisees ou non encore prises en charge au code applicatif, avec les arguments evalues et le resultat Variant renvoye lorsque l'appel est traite.

Version 2.88.93

La protection des feuilles Classic XLS expose maintenant des indicateurs d'autorisation par action. IXLSWorksheet ajoute AllowDeleteRows, AllowInsertRows, AllowFormatCells, AllowSort, AllowAutoFilter et les autres proprietes d'autorisation SheetProtect, avec des options BIFF8 ecrites et relues via les enregistrements de protection existants.

Version 2.88.92

Les payloads VBA Classic XLS disposent maintenant d aides explicites de chargement, sauvegarde et suppression. IXLSWorkbook.LoadVBAProjectFromFile, SaveVBAProjectToFile, HasVBAProject et ClearVBAProject exposent le payload de stockage OLE VBA conservé, tandis que VBAProject reste la vue de modules analysée en lecture seule.

Version 2.88.91

Les criteres Classic XLS AutoFilter peuvent maintenant etre inspectes via une collection de champs. IXLSWorksheet.AutoFilterColumns expose le nombre de champs BIFF8 AutoFilter courant et les elements de champ 1-based, avec active state, operator et valeurs DOPER stockees dans Criteria1 / Criteria2.

Version 2.88.90

Classic XLS worksheets peut maintenant configurer les criteres AutoFilter en un seul appel. IXLSWorksheet.ApplyAutoFilter definit une plage AutoFilter de worksheet et ecrit un critere de champ dans le meme appel, avec des surcharges de plage A1-style et numeriques 1-based ainsi que des operateurs optionnels a deux criteres.

Version 2.88.89

Classic XLS shapes peut maintenant etre supprime par plage de cellules. TXLSShapes.DeleteInRange supprime les images ou shapes ancrees dont les OfficeArt client anchors intersectent une plage de feuille 1-based, puis renvoie le nombre de shapes supprimees.

Version 2.88.88

Les table layout attributes de Classic HTML export sont maintenant configurables. TXLSHTMLExport.TableBorderWidth, CellPadding et CellSpacing controlent les attributs <table> generes pour styled et simple HTML output, avec les anciennes valeurs zero par defaut.

Version 2.88.87

Classic HTML export prend maintenant en charge minimal table output. TXLSHTMLExport.SimpleExport ecrit une table HTML simple sans CSS classes generees, hyperlink anchors ni comment title attributes, tout en conservant display text echappe et merged-cell spans.

Version 2.88.86

Classic HTML export peut maintenant ecrire un document title. TXLSHTMLExport.Title ecrit un element HTML <title> echappe avant le style block genere, tandis que la valeur vide par defaut conserve la sortie existante inchangee.

Version 2.88.85

Classic HTML export transporte maintenant les cell comments sous forme de tooltips. TXLSHTMLExport.Options inclut maintenant xhComments par defaut et ecrit cell comment text sous forme d attributs title echappes, tout en permettant aux appelants de retirer l option pour une cell output simple.

Version 2.88.84

La sortie hyperlink de l export Classic HTML est maintenant configurable. TXLSHTMLExport.Options vaut par defaut [xhHyperlinks] pour conserver le comportement existant, et les appelants peuvent retirer xhHyperlinks afin d exporter les cellules liees comme du texte echappe simple.

Version 2.88.83

L export Classic HTML conserve maintenant les hyperlinks de cellule. SaveAsHTML entoure les cellules liees avec des balises d ancrage HTML, emet les adresses hyperlink comme valeurs href echappees, conserve le texte ScreenTip comme attributs title echappes et garde le texte affiche de la cellule echappe dans le link.

Version 2.88.82

Les classeurs Classic XLS peuvent maintenant controler le nom utilisateur saved-by. IXLSWorkbook.LastSavedBy expose le champ saved-by WRITEACCESS afin que les classeurs generes ou modifies puissent enregistrer un nom d audit explicite, tandis que les classeurs source non modifies continuent de conserver leurs metadonnees d origine.

Version 2.88.81

Les feuilles Classic XLS peuvent maintenant controler l'indice de couleur des lignes de grille affichees. IXLSWorksheet.GridlineColorIndex expose le champ Window2 icvHdr, afin que les feuilles enregistrees se rouvrent avec une couleur de grille choisie sans modifier la visibilite des lignes de grille ni les parametres d'impression.

Version 2.88.80

Les workbooks classic XLS peuvent désormais définir l'active sheet par index. IXLSWorkbook.ActiveSheetIndex expose une propriété active-tab 1-based adossée au champ active sheet de WINDOW1, afin que les workbooks enregistrés se rouvrent sur un worksheet choisi sans modifier le first visible tab.

Version 2.88.79

Les worksheet outlines classic XLS peuvent désormais contrôler les styles de plan automatiques. TXLSOutline.ApplyStyles expose le drapeau outline style de WSBool, afin que les worksheets enregistrées conservent ou activent explicitement l'application des styles de plan Excel sans modifier les outline levels ni le placement des summary.

Version 2.88.78

La page setup classic XLS peut désormais contrôler les sauts de page automatiques. IXLSPageSetup.AutoPageBreaks expose le drapeau automatic page-break du WSBool de worksheet, afin que les worksheets enregistrées conservent les sauts de page automatiques activés ou les désactivent explicitement tout en préservant les sauts de page manuels.

Version 2.88.77

Les workbooks classic XLS peuvent désormais contrôler le groupement des dates AutoFilter. IXLSWorkbook.AutoFilterDateGrouping expose le drapeau de groupement des dates Window1 avec une API Boolean positive, afin que les workbooks enregistrés conservent le groupement des filtres de date Excel activé ou le désactivent explicitement.

Version 2.88.76

Les workbooks classic XLS peuvent désormais définir directement la position et la taille de la workbook window. IXLSWorkbook.XWindow, YWindow, WindowWidth et WindowHeight exposent les champs Window1 geometry afin que les workbooks enregistrés puissent se rouvrir avec un window rectangle choisi.

Version 2.88.75

Les workbooks classic XLS peuvent désormais enregistrer directement l'état hidden de la workbook window. IXLSWorkbook.WindowHidden correspond au drapeau hidden de Window1, permettant aux workbooks enregistrés de se rouvrir avec la workbook window hidden sans modifier la visibilité des worksheet.

Version 2.88.74

Les workbooks classic XLS peuvent désormais enregistrer directement l'état minimized de la workbook window. IXLSWorkbook.Minimized correspond au drapeau minimized de Window1, permettant aux workbooks enregistrés de se rouvrir avec la workbook window réduite.

Version 2.88.73

Les workbooks classic XLS peuvent désormais masquer ou afficher directement la barre de défilement verticale. IXLSWorkbook.ShowVerticalScroll correspond au drapeau Window1 fDspVScroll, permettant aux workbooks enregistrés de s'ouvrir avec la barre de défilement verticale masquée ou visible.

Version 2.88.72

Les workbooks classic XLS peuvent désormais masquer ou afficher directement la barre de défilement horizontale. IXLSWorkbook.ShowHorizontalScroll correspond au drapeau Window1 fDspHScroll, permettant aux workbooks enregistrés de s'ouvrir avec la barre de défilement horizontale masquée ou visible.

Version 2.88.71

Les workbooks classic XLS peuvent désormais masquer ou afficher directement la sheet tab bar. IXLSWorkbook.ShowSheetTabs correspond au drapeau Window1 fDspTabs, permettant aux workbooks enregistrés de s'ouvrir avec les sheet tabs masqués ou visibles sans modifier la visibilité des worksheet.

Version 2.88.70

Les workbooks classic XLS peuvent désormais définir directement le ratio de la workbook tab bar. IXLSWorkbook.TabRatio expose la valeur Window1 wTabRatio afin que les appelants puissent ajuster l'espace réservé aux sheet tabs par rapport à la barre de défilement horizontale.

Version 2.88.69

Les workbooks classic XLS peuvent désormais définir directement le premier sheet tab visible. IXLSWorkbook.FirstSheet expose la valeur Window1 itabFirst comme une propriété 1-based, afin que les appelants puissent choisir quel sheet tab apparaît au bord gauche quand Excel ouvre le workbook.

Version 2.88.68

Les worksheets classic XLS peuvent désormais conserver et définir la visibilité des outline symbols. IXLSWorksheet.DisplayOutlineSymbols correspond au drapeau BIFF WINDOW2 fDspGuts, permettant aux sheets enregistrées de masquer les symboles outline et grouping dans la vue de fenêtre.

Version 2.88.67

Les worksheets classic XLS peuvent désormais conserver et définir la visibilité des en-têtes de lignes et de colonnes. IXLSWorksheet.DisplayHeadings correspond au drapeau BIFF WINDOW2 fDspRwCol, permettant aux sheets enregistrées de masquer les numéros de ligne et les lettres de colonne dans la vue de fenêtre.

Version 2.88.66

Les worksheets classic XLS peuvent désormais conserver et définir l'affichage des formules. IXLSWorksheet.DisplayFormulas correspond au drapeau BIFF WINDOW2 fDspFmla, afin qu'Excel puisse ouvrir une sheet en affichant le texte des formules au lieu des résultats calculés.

Version 2.88.65

Les worksheets classic XLS peuvent désormais définir le zoom Normal view indépendamment. IXLSWorksheet.NormalViewZoom expose le WINDOW2 Normal zoom mis en cache afin que les appelants puissent enregistrer des niveaux de zoom distincts pendant qu'une sheet est en Page Break Preview.

Version 2.88.64

Les worksheets classic XLS peuvent désormais définir directement le zoom Page Break Preview. IXLSWorksheet.PageBreakPreviewZoom expose le WINDOW2 preview zoom mis en cache afin que les appelants puissent enregistrer des niveaux de zoom différents pour Normal et Page Break Preview.

Version 2.88.63

Les worksheets classic XLS exposent désormais des aides de volet fractionné. IXLSWorksheet.SplitPanes(Width, Height) crée un fractionnement mobile avec le BIFF pane writer existant, et UnsplitPanes efface le pane record avant l'enregistrement.

Version 2.88.62

Les worksheets classic XLS disposent désormais d'aides plus simples pour les volets figés. IXLSWorksheet.FreezePanes(Cols, Rows) fige les colonnes de gauche et les lignes du haut demandées, tandis que UnfreezePanes supprime le pane record avant l'enregistrement.

Version 2.88.61

La découverte des noms de feuilles classic XLS accepte désormais les flux. TXLSWorkbook.GetSheetNames(Stream, List) lit les noms de feuilles BIFF depuis un XLS stream fourni par l'appelant sans charger le contenu des worksheet, comme l'aide par nom de fichier pour les données de workbook en mémoire.

Version 2.88.60

Les collections de worksheet exposent désormais des aides de recherche directe par nom. IXLSWorkSheets.SheetByName(Name) et TXLSXSheets.SheetByName(Name) renvoient l'objet worksheet correspondant ou nil, ce qui évite de résoudre un index avant d'accéder à une feuille.

Version 2.88.59

La façade XLSX lit désormais les noms de feuilles directement depuis les flux. TXLSXWorkbook.GetSheetNames(Stream, List) lit les noms ordonnés depuis xl/workbook.xml sans charger worksheet XML, comme la surcharge par nom de fichier pour les classeurs en mémoire ou stockés en BLOB.

Version 2.88.58

La façade XLSX expose désormais la lecture rapide des noms de feuilles. TXLSXWorkbook.GetSheetNames(FileName, List) lit les noms ordonnés depuis xl/workbook.xml sans charger worksheet XML.

Version 2.88.57

TXLSWorkbook.GetSheetNames prend désormais en charge les packages XLSX. La méthode lit xl/workbook.xml depuis les fichiers .xlsx, .xlsm, .xltx et .xltm, puis renvoie les noms de feuilles ordonnés sans charger worksheet XML.

Version 2.88.56

Les classeurs XLS classiques peuvent désormais lire les noms de feuilles sans charger les feuilles. TXLSWorkbook.GetSheetNames(FileName, List) analyse le workbook globals stream et renvoie les noms de feuilles ordonnés depuis les fichiers Excel 97-2003 .xls.

Version 2.88.55

Les critères AutoFilter de plage XLS classique écrivent désormais les enregistrements de filtre BIFF8. TXLSRange.Autofilter(Field, Criteria) crée la plage de filtre si nécessaire et émet des conditions AUTOFILTER pour les critères simples de chaîne, numériques, Boolean, vides, non vides et préfixés par comparaison.

Version 2.88.54

Les feuilles de calcul XLS classiques disposent maintenant d'aides AutoFilter au niveau de la feuille. IXLSWorksheet.SetAutoFilter, ClearAutoFilter et AutoFilterRange gèrent directement les plages de listes déroulantes de filtre BIFF8 tout en réutilisant l'écriture existante de AUTOFILTERINFO et du nom de base de données de filtre.

Version 2.88.53

Les feuilles de calcul XLS classiques exposent maintenant la création de validation de données de liste. IXLSWorksheet.AddListValidation(Range, Items) écrit les enregistrements BIFF8 DVAL et DV, garde la liste déroulante visible par défaut, prend en charge les listes en ligne séparées par des virgules et conserve les règles après les allers-retours Open / SaveAs.

Version 2.88.52

Le calcul des formules fonctionne désormais de manière cohérente dans les points d’entrée XLS et XLSX. TXLSWorkbook.Calculate accepte désormais les formules commençant par le signe égal, comme dans Excel, par exemple =SUM(A1:B1)+C1. La façade XLSX ajoute TXLSXWorkbook.Calculate et TXLSXWorksheet.Calculate. Le chemin XLSX partage l’analyseur et l’évaluateur de jetons de formule HotXLS pour les références de cellules et de plages, les cellules référencées par des formules, les références entre feuilles et les plages nommées définies au niveau du classeur ou de la feuille.

Version 2.88.51

Les plages XLSX prennent maintenant en charge le merge across de style Excel. TXLSXRange.Merge(True) écrit une entrée <mergeCell> par ligne, comme le comportement XLS classique de Range.Merge(True), tandis que Merge sans argument et Merge(False) continuent de créer un seul rectangle fusionné couvrant toute la plage.

Version 2.88.50

BIFF8 HeaderFooter et HFPicture respectent maintenant les règles MS-XLS actuelles. HotXLS conserve les enregistrements HeaderFooter ($089C) écrits par Excel pour les en-têtes et pieds de page des pages paires / première page, puis réémet les enregistrements HFPicture ($0866) après les dimensions de feuille et les objets de dessin selon le worksheet ABNF, afin que les détails de mise en page survivent aux round-trips ouverture/enregistrement .xls.

Version 2.88.49

Les runs de texte enrichi des commentaires disposent maintenant d'une API typée. TXLSComment.TextRuns expose les entrées BIFF8 TXO FormatRun, afin que les appelants puissent inspecter ou définir les limites de police par caractère dans les commentaires .xls, tandis que HotXLS conserve les octets de run sous-jacents pour des round-trips sûrs.

Version 2.88.48

Les enregistrements SX supplémentaires des tableaux croisés dynamiques sont désormais exposés par l'API typée. HotXLS attache maintenant les enregistrements pivot BIFF8 chargés, tels que SXIVD, SXLI, SXFormat, SXEx, SXVDEx, SXRule, SXFilt et SXAddl, à TXLSPivotTable.SupplementalRecords pour inspection, tout en conservant les raw bytes d'origine pour les round-trips d'enregistrement.

Version 2.88.47

Les valeurs mises en cache des classeurs externes survivent désormais aux cycles ouverture/enregistrement .xls. HotXLS conserve maintenant les enregistrements BIFF8 XCT et CRN attachés aux entrées SUPBOOK chargées, afin que les cached cell values des liens vers des classeurs externes ne soient plus supprimées lors de l'enregistrement.

Version 2.88.46

Les niveaux de plan des styles intégrés survivent désormais aux cycles ouverture/enregistrement .xls. HotXLS lit et conserve maintenant l'octet iLevel de STYLE BIFF8 pour les styles intégrés, afin que les métadonnées Excel RowLevel_1..7 et ColLevel_1..7 ne soient plus réinitialisées à la valeur par défaut lors de l'enregistrement.

Version 2.88.45

Les métadonnées des noms définis survivent désormais aux cycles ouverture/enregistrement .xls. HotXLS conserve maintenant les bits d'option et les octets de raccourci des enregistrements BIFF8 NAME chargés tant que le nom défini n'est pas modifié, afin que les métadonnées function, object, procedure, calculated-expression et binary-name écrites par Excel ne soient plus effacées lors de l'enregistrement.

Version 2.88.44

Les marqueurs de classeur ObProj survivent maintenant aux cycles ouverture/enregistrement .xls. HotXLS conserve désormais les enregistrements BIFF8 ObProj chargés même lorsqu'aucun stockage VBA n'est exposé par le modèle objet, afin que les marqueurs de projet VBA au niveau du classeur et les métadonnées tierces ne soient plus supprimés à l'enregistrement.

Version 2.88.43

Les indicateurs d'options de feuille survivent maintenant aux cycles ouverture/enregistrement .xls. HotXLS conserve désormais les bits BIFF8 WSBOOL non modélisés, comme feuille de dialogue, sauts de page automatiques, application des styles et affichage des gouttières de plan, tout en continuant à mettre à jour via l'API publique les réglages existants d'ajustement à la page et de résumé de plan.

Version 2.88.42

Des enregistrements de métadonnées de classeur supplémentaires survivent maintenant aux cycles ouverture/enregistrement .xls. HotXLS conserve désormais les corps des enregistrements BIFF8 COUNTRY, BOOKBOOL, BACKUP, FNGROUPCOUNT, USESELFS et RECALCID chargés au lieu de les réécrire avec des valeurs par défaut, ce qui stabilise les métadonnées de compatibilité et de calcul du classeur.

Version 2.88.41

Les sélections multizones et le focus du volet actif survivent maintenant aux cycles ouverture/enregistrement .xls. HotXLS conserve désormais les enregistrements BIFF8 SELECTION chargés et la valeur du volet actif dans PANES, sauf si la sélection ou les volets sont modifiés via l'API, afin que le focus des volets fractionnés/figés Excel et les sélections multizones ne soient plus réduits à l'enregistrement.

Version 2.88.40

Les noms de classeurs externes survivent maintenant aux cycles ouverture/enregistrement .xls. HotXLS conserve désormais les enregistrements BIFF8 EXTERNALNAME chargés et rattachés aux entrées externes SUPBOOK, y compris les métadonnées DDE/OLE/de lien et les queues de formule, afin que les noms externes et définitions de liens ne soient plus supprimés à l'enregistrement.

Version 2.88.39

Les fichiers BIFF8 .xls proteges par mot de passe ecrivent et lisent maintenant les enregistrements FILEPASS RC4 CryptoAPI. HotXLS ecrit desormais des metadonnees FILEPASS vMajor=2 de type Excel 2007/2010 pour les classeurs .xls chiffres et lit a la fois l'ancien RC4 vMajor=1 et RC4 CryptoAPI vMajor=2/3/4, afin que les classeurs proteges par mot de passe n'echouent plus sur cet en-tete de chiffrement et ne retombent plus sur l'ancien en-tete.

Version 2.88.38

Les métadonnées de liens hypertexte .xls écrites par Excel survivent maintenant aux cycles d'ouverture/enregistrement. HotXLS conserve désormais le HLink record body BIFF8 pour les liens chargés tant que le lien n'est pas modifié, gardant stables streamVersion, les hlstmf option bits comme fIcon, les données moniker et les métadonnées de cible associées lors des enregistrements.

Version 2.88.37

L'état de fenêtre du classeur survit maintenant aux cycles d'ouverture/enregistrement .xls. HotXLS lit et conserve désormais la position, la taille, les flags de visibilité/iconic, le premier onglet de feuille affiché, le nombre d'onglets sélectionnés et le ratio onglets/barre de défilement du record BIFF8 WINDOW1, au lieu de les réécrire avec des valeurs par défaut à chaque enregistrement.

Version 2.88.36

Les utilisateurs saved-by BIFF8 WriteAccess survivent maintenant aux cycles d'ouverture/enregistrement .xls. HotXLS lit et conserve désormais le $005C WRITEACCESS record body au lieu de remplacer l'utilisateur saved-by écrit par Excel par HotXLS, ce qui garde les métadonnées d'audit du classeur stables après l'enregistrement.

Version 2.88.35

Les auteurs des commentaires Excel survivent désormais aux round-trips ouverture/enregistrement .xls. Le champ stAuthor de l'enregistrement BIFF8 Note est maintenant analysé et transmis au drawing note model au lieu d'être remplacé par une chaîne vide, de sorte que l'auteur "Created by" du commentaire écrit par Excel est conservé lorsque HotXLS réenregistre le workbook.

Version 2.88.34

Les options FOPT OfficeArt des formes sont maintenant exposées via un option bag bas niveau. TXLSShape.OfficeArtOptions permet aux appelants avancés d'inspecter, définir et supprimer n'importe quel PID FOPT stocké sous forme de LongWord ou de WideString, tandis que les API haut niveau existantes pour Line, Fill, les couleurs et la visibilité restent inchangées.

Version 2.88.33

D'autres enregistrements de règles du conteneur solver OfficeArt sont maintenant conservés au round-trip. En plus de msofbtConnectorRule ($F012) typé, HotXLS préserve désormais les solver children qui ne sont pas des folders, comme OfficeArtFArcRule ($F014) et OfficeArtFCalloutRule ($F017), sous forme d'enregistrements OfficeArt bruts dans msofbtSolverContainer ($F005), afin que les dessins Excel avancés ne perdent plus les relations solver non liées aux connecteurs lors de l'enregistrement.

Version 2.88.32

Les marqueurs OfficeArt ClientData ne sont plus dupliqués après la préservation des enregistrements inconnus. MS-XLS définit OfficeArtClientData ($F011) comme un marqueur de longueur nulle dont l'enregistrement Obj suivant reste un enregistrement BIFF séparé. v2.88.32 reconnaît ce marqueur au lieu de le capturer comme un leaf SpContainer inconnu; les formes parsées émettent donc exactement un marqueur $F011 à la sauvegarde. Les hypothèses container-style non conformes restent hors du chemin XLS.

Version 2.88.31

Les règles de connecteurs OfficeArt font désormais un round-trip. Les dessins .xls créés par Excel stockent les liaisons de connecteurs dans msofbtSolverContainer ($F005) avec des enregistrements enfants msofbtConnectorRule ($F012). v2.88.31 lit et écrit cette paire $F005/$F012 via TMsoConnectorRules, en préservant la forme de départ, la forme d'arrivée, la forme connecteur et les points de connexion lors d'une sauvegarde/relecture. La note d'audit précédente indiquait $F121, mais MS-ODRAW définit OfficeArtFConnectorRule comme $F012.

Version 2.88.30

Les enregistrements leaf OfficeArt SpContainer non reconnus font désormais un round-trip. Les fichiers .xls créés par Excel contiennent souvent dans le SpContainer de chaque forme des Fbts leaf tels que msofbtClientTextbox ($F00D), OfficeArtFPSPL ($F11D), and OfficeArtUDefProp ($F122). v2.88.30 capture les leaf inconnus de niveau forme comme TMsoFbtUnknown et les réémet dans l'ordre parsé entre ClientAnchor et le marqueur final msofbtClientData à corps nul.
Portée et suite. Les autres leaf inconnus de niveau dessin restent différés; le cas SolverContainer des règles de connecteur est traité par v2.88.31. Les unknowns sous forme de conteneur, comme msofbtClientData ($F011) utilisé comme conteneur au lieu de sibling marker, restent pour le Slice 3 de l'audit.

Version 2.88.29

Sous-enregistrements OBJ inconnus de ComboBox et ListBox font maintenant round-trip. TMSOShapeComboBox.ParseObj et TMSOShapeListBox.ParseObj analysaient deja typed FtSbs ($000C), FtSbsFmla ($000E) et FtLbsData ($0013) dans des champs dedies, mais tout autre sous-enregistrement du fichier source (FtMacro $0004, ObjLinkFmla, FtNts $000D, etc.) apparaissant entre CMO et FtLbsData etait abandonne silencieusement au case fall-through. v2.88.29 ajoute la meme branche else que v2.88.28 Picture, capturant l en-tete de 4 octets + corps du sous-enregistrement inconnu dans FObjTailRaw. Les deux methodes AddObj emettent les octets captures entre le corps CMO et le sous-enregistrement FtSbs pour correspondre a l ordre des sous-enregistrements de la spec BIFF8.
Le comportement "avaler tout" de FtLbsData limite la portee. Le case existant $0013 ecrase RecLen := Len - offs pour absorber tous les octets apres l en-tete FtLbsData dans le blob de FObjRec_LBSData, donc les sous-enregistrements apparaissant APRES FtLbsData (typiquement juste FtEnd) font toujours round-trip a travers ce mecanisme sans changement. La nouvelle integration FObjTailRaw cible specifiquement la lacune avant FtLbsData ou FtMacro et ObjLinkFmla vivent typiquement. Les combo / list boxes nouvellement crees via Drawing API ont FObjTailRaw vide → sortie identique octet par octet a v2.88.28.

Version 2.88.28

Sous-enregistrements OBJ inconnus de forme Picture font maintenant round-trip. TMSOShapePicture.ParseObj analysait deja typed FtCf ($0007), FtPioGrbit ($0008) et FtPictFmla ($0009) dans des champs dedies, mais tout autre sous-enregistrement du fichier source (FtMacro $0004, FtNts $000D, etc.) etait abandonne silencieusement au case fall-through. v2.88.28 ajoute une branche else qui ajoute l en-tete complet de 4 octets + corps des sous-enregistrements non reconnus a FObjTailRaw ; TMSOShapePicture.AddObj emet alors ces octets verbatim apres sa sortie de sous-enregistrements types et avant le marqueur FtEnd. Les objets picture du fichier source avec des hooks macro survivent a la sauvegarde.
Motif de coexistence typed + raw. Contrairement a PictureFrame (v2.88.27) qui utilisait un echange if/else entre emission typee et brute, Picture combine les deux : les champs types preservent la surface API (les appelants peuvent encore ajuster ftCfValue etc.), tandis que la queue brute preserve seulement les octets inconnus. Les images nouvellement creees via Drawing API ont FObjTailRaw vide, donc la sortie est identique octet par octet a v2.88.27.

Version 2.88.27

Round-trip des sous-enregistrements finaux OBJ etendu aux formes PictureFrame. TMSOShapePictureFrame.AddObj n emettait auparavant que les sous-enregistrements legataires codes en dur FtCf ($0007, corps $FFFF) et FtPioGrbit ($0008, corps $0000) entre CMO et FtEnd. Pour les cadres d image nouvellement crees, le nouveau code emet toujours ces valeurs par defaut ; pour les cadres d image analyses depuis un .xls source, les octets FObjTailRaw captures sont emis verbatim a la place, preservant tout FtPictFmla du fichier source / FtCf non par defaut / FtPioGrbit non par defaut a travers le cycle de sauvegarde.
Note d enquete — Flush corrige sz automatiquement. TMsoShapeContainer.Flush reecrit l en-tete de taille de l enregistrement Obj au moment du commit via Data.SetWord(Data.DataLength - 4, 2), ce qui signifie que les valeurs codees en dur sz := $1A qui ont vecu dans les implementations AddObj de HotXLS pendant des annees n etaient pas des bugs de spec apres tout — Flush les corrige automatiquement. v2.88.27 calcule encore sz avec precision pour la clarte du code source, mais le comportement d execution est inchange de ce point de vue.

Version 2.88.26

Round-trip des sous-enregistrements finaux OBJ etendu aux formes Chart et CheckBox. v2.88.25 a introduit la preservation des octets bruts entre le CMO ($0015) d un enregistrement Obj et son marqueur FtEnd ($0000), mais seul TMSOShapeTextBox.AddObj emettait la queue capturee. Cette version applique le meme motif a TMSOShapeChart.AddObj et TMSOShapeCheckBox.AddObj — les deux partagent la structure simple d emission "CMO + FtEnd" de TextBox, donc le changement est une substitution de variable d une ligne (sz := $1A + Word(Length(FObjTailRaw))) plus une boucle d emission verbatim d octets avant le marqueur FtEnd.
Les sous-enregistrements finaux de Chart (par exemple FtMacro pour macros d objets chart embarques) et les sous-enregistrements d etat de checkbox (FtCbls + FtCblsData + ObjLinkFmla, MS-XLS §2.5.140-141 / §2.5.149) survivent maintenant au cycle sauvegarde/rechargement HotXLS. Les charts et checkboxes nouvellement crees via Drawing API emettent toujours un CMO+FtEnd par defaut de 26 octets (identique octet par octet a v2.88.25), donc les appelants existants ne voient pas de changement de comportement. Les formes Picture / ComboBox / ListBox / PictureFrame ont leur propre emission dynamique de sous-enregistrements types qui entre en conflit avec FObjTailRaw — leur integration est differee a des commits futurs.

Version 2.88.25

Sous-enregistrements finaux de l enregistrement OBJ maintenant preserves a travers le cycle de sauvegarde pour les commentaires. L enregistrement BIFF8 Obj ($005D) enchaine une sequence de sous-enregistrements types apres le CMO obligatoire ($0015), termine par un marqueur FtEnd ($0000), selon MS-XLS §2.4.181. Pour les formes Note (commentaire) le bloc final est typiquement un FtNts (§2.5.149) de 26 octets portant un GUID et le drapeau fSharedNote — les deux essentiels lorsqu Excel fusionne ulterieurement les commentaires entre utilisateurs dans des classeurs partages. HotXLS abandonnait auparavant chaque octet apres CMO a la lecture et emettait seulement un FtEnd vide a l ecriture, donc tout FtNts du fichier source etait perdu a chaque sauvegarde HotXLS.
Capture base generique, emission TextBox uniquement (R5-3 premiere tranche). TMsoShapeContainer.ParseObj capture maintenant la plage d octets entre la fin du corps CMO et le marqueur FtEnd dans un nouveau champ interne FObjTailRaw: TBytes ; TMSOShapeTextBox.AddObj insere ces octets entre son emission CMO et le marqueur FtEnd, avec la taille de l en-tete d enregistrement Obj ajustee en consequence. Les commentaires nouvellement crees (sans octets source) conservent une sortie identique octet par octet a v2.88.24. Les autres classes de forme (Picture / CheckBox / ComboBox / ListBox / Chart) heritent de la capture, mais leurs remplacements AddObj types conservent le comportement heritant "synthetiser de zero" — l emission d octets bruts pour ces types de forme est differee a des commits futurs.

Version 2.88.24

Commentaires de cellule multi-polices et multi-couleurs survivent maintenant au cycle de sauvegarde. Le bloc d executions de formatage de l enregistrement BIFF8 TXO (rgTxoRuns + TxOLastRun selon MS-XLS §2.5.272) porte les remplacements de police et de couleur par execution qui donnent au commentaire son style de texte enrichi. HotXLS abandonnait auparavant le bloc entier a la lecture et emettait une seule execution vide par defaut + LastRun a l ecriture — ecrasant tout "Important!" surligne en rouge, ou mot en gras dans le texte du commentaire, a un formatage uniforme par defaut a chaque sauvegarde HotXLS.
Preservation octet par octet dans TMSOShapeTextBox. ParseTXO capture les octets Continue apres le texte verbatim dans un nouveau champ interne FFormatRunsRaw: TBytes ; Store les emet en retour comme Continue d executions de formatage et ajuste l en-tete cbRuns de l enregistrement de base en consequence. Les commentaires nouvellement crees (via AddComment) conservent la sortie heritee d execution unique par defaut inchangee, donc la sortie octet par octet identique est preservee pour les classeurs par defaut. L acces de type API Excel aux executions de formatage individuelles est toujours differe — l API de commentaire WideString unique existante est inchangee.

Version 2.88.23

Resolution d impression et nombre de copies survivent maintenant au cycle de sauvegarde — enregistrement Setup entierement couvert. Trois champs Word de l enregistrement Setup (iRes a l offset 12, iVRes a l offset 14, iCopies a l offset 32, selon MS-XLS §2.4.257) portent les choix "Mise en page → Page → Qualite d impression" et "Nombre de copies" d Excel. HotXLS abandonnait auparavant les trois a la lecture et emettait des valeurs codees en dur (600 DPI / 600 DPI / 1 copie), donc toute resolution ou nombre de copies modifie par l utilisateur revenait silencieusement apres chaque sauvegarde HotXLS.
Trois nouvelles proprietes TXLSPageSetup. PrintResolution: LongWord, PrintVResolution: LongWord et Copies: LongWord — toutes par defaut aux valeurs que l ecrivain codait en dur (600 / 600 / 1), donc les classeurs qui ne les touchent jamais produisent une sortie identique octet par octet a v2.88.22. Les setters contraignent a High(Word) pour qu une valeur d appelant trop grande ne deborde pas a l emission.
Travail de round-trip de l enregistrement Setup acheve. Avec ce correctif, chaque champ visible par l utilisateur de l enregistrement BIFF8 Setup ($00A1) survit au round-trip de bout en bout — taille papier / echelle / numero de premiere page / ajuster a la largeur et hauteur / orientation / ordre d impression / noir et blanc / brouillon / impression commentaires / erreurs cellules / resolution / copies. Seuls restent non exposes les deux bits de hint spec (fNoPls, fNoOrient) — HotXLS ecrit les deux a zero, correspondant au comportement par defaut d Excel.

Version 2.88.22

Le "Numero de premiere page" personnalise de la Mise en page survit maintenant au cycle de sauvegarde. L enregistrement BIFF8 Setup porte le choix du classeur Mise en page → Page → "Numero de premiere page" sous deux champs relies: le bit 7 du grbit (fUsePage) selectionne entre le defaut "Auto" d Excel et un numero de page de depart explicite, et le Word signe a l offset 4 (iPageStart) detient cette valeur personnalisee, selon MS-XLS §2.4.257. HotXLS abandonnait auparavant les deux a la lecture et emettait iPageStart = 1 avec le bit efface, donc un "Numero de premiere page: 100" tape par l utilisateur revenait silencieusement a "Auto" apres chaque sauvegarde HotXLS.
Deux nouvelles proprietes TXLSPageSetup. UseFirstPageNumber: Boolean reflete le bit (False = "Auto", par defaut) ; FirstPageNumber: Integer porte la valeur iPageStart (par defaut 1, contrainte par le setter a la plage signed-Word de la spec -32768..32767). HotXLS fait un round-trip de iPageStart verbatim meme lorsque UseFirstPageNumber est False, donc basculer entre Auto et personnalise dans Excel preserve la derniere valeur tapee par l utilisateur.

Version 2.88.21

Le choix "Imprimer les commentaires a la fin de la feuille" survit maintenant au cycle de sauvegarde. Le bit 9 (fEndNotes selon MS-XLS §2.4.257) du champ grbit de l enregistrement BIFF8 Setup porte la distinction de la liste deroulante Mise en page → Feuille → Commentaires entre "Comme affiches sur la feuille" (par defaut) et "A la fin de la feuille". HotXLS faisait deja un round-trip de PrintNotes (bit 5) pour controler si les commentaires s impriment, mais le bit 9 etait abandonne a la lecture et emis a zero a l ecriture — donc un "A la fin de la feuille" choisi par l utilisateur revenait silencieusement a "Comme affiches sur la feuille" apres chaque sauvegarde HotXLS.
Nouvelle propriete booleenne TXLSPageSetup.PrintNotesAtEnd. Par defaut False correspond au defaut de l interface Excel. Le lecteur et l ecrivain font un round-trip du bit verbatim (meme lorsque PrintNotes = False), donc un classeur avec commentaires temporairement desactives conserve la preference "a la fin de la feuille" pour quand l utilisateur les reactive — reflechi sur le comportement propre d Excel.

Version 2.88.20

Le choix "Definir le calcul avec la precision au format affiche" survit maintenant au cycle de sauvegarde. L enregistrement BIFF8 CalcPrecision ($000E) porte la case a cocher au niveau du classeur Fichier → Options → Options avancees → "Definir le calcul avec la precision au format affiche", selon MS-XLS §2.4.35. HotXLS n avait auparavant aucun cas dispatcher pour $000E et TXLSWorkbook.StorePrecision emettait un 1 code en dur (= precision complete conservee). Une "precision au format affiche" cochee par l utilisateur revenait silencieusement a "precision complete" apres chaque sauvegarde HotXLS — cachant l intention deliberee de l utilisateur qu un recalcul ulterieur tronque definitivement les valeurs de cellule a leurs decimales formatees.
Nouvelle propriete booleenne TXLSWorkbook.UseFullPrecision. Par defaut True (correspond au defaut BIFF8 et au defaut UI Excel non coche). Mettre a False equivaut a cocher l option destructrice "precision au format affiche" — HotXLS lui-meme ne tronque aucune valeur de cellule pendant le round-trip, mais l indicateur est maintenant fidelement reecrit pour que le prochain recalcul d Excel le respecte. Avec ce correctif, chaque enregistrement BIFF8 de calcul (CalcCount / CalcMode / CalcPrecision / CalcDelta / CalcIter / CalcSaveRecalc) survit au round-trip de bout en bout.

Version 2.88.19

La case "Recalculer le classeur avant l enregistrement" survit maintenant au cycle de sauvegarde. L enregistrement BIFF8 CalcSaveRecalc ($005F) porte le booleen du classeur Fichier → Options → Enregistrer → "Recalculer le classeur avant l enregistrement", selon MS-XLS §2.4.37. HotXLS n avait auparavant aucun cas dispatcher pour $005F et StoreCalculationSettings emettait un 1 code en dur — donc "recalculer a l enregistrement" desactive par l utilisateur se reactivait silencieusement a chaque sauvegarde HotXLS, ce qui importait surtout pour les classeurs en mode de calcul manuel ou l utilisateur avait deliberement fige les valeurs de cellules sur disque.
Nouvelle propriete booleenne TXLSWorkbook.RecalcOnSave. Par defaut True (correspond au defaut de l interface Excel et a la valeur codee en dur heritee), donc les classeurs qui ne touchent jamais la propriete conservent une sortie identique octet par octet a v2.88.18. Le setter accepte n importe quel booleen ; le lecteur normalise des octets source non nuls arbitraires en True.

Version 2.88.18

Les parametres de calcul iteratif (activer + nombre maximal d iterations + changement maximum) survivent maintenant au cycle de sauvegarde. Les enregistrements BIFF8 CalcIter ($0011), CalcCount ($000C) et CalcDelta ($0010) portent ensemble le trio d options "Activer le calcul iteratif" d Excel (Fichier → Options → Formules), selon MS-XLS §2.4.33 / §2.4.31 / §2.4.32. Aucun des trois n avait de case dans le dispatcher auparavant, et StoreCalculationSettings les emettait avec des valeurs codees en dur (desactive / 100 / 0.001). Une boucle de 1000 iterations configuree par l utilisateur avec un delta de convergence de 0.0001 se reinitialisait silencieusement a "iteration desactivee, 100, 0.001" apres chaque sauvegarde HotXLS — cassant les formules a reference circulaire et les modeles financiers sensibles a la convergence.
Trois nouvelles proprietes TXLSWorkbook. EnableIteration: Boolean reflete la case a cocher ; MaxIterations: LongWord est le plafond d iteration (le setter le contraint a la plage legale de la spec 1..32767) ; MaxIterationChange: Double est le delta de convergence (entree negative bascule sur le defaut de la spec 0.001). Les valeurs par defaut correspondent a celles que l ecrivain codait en dur, donc les classeurs qui ne touchent jamais les nouvelles proprietes produisent une sortie identique octet par octet a v2.88.17.

Version 2.88.17

Le mode de calcul du classeur (Manuel / Automatique / Automatique sauf tableaux) survit maintenant au cycle de sauvegarde. L enregistrement BIFF8 CalcMode ($000D) porte le choix au niveau du classeur "Formules → Options de calcul" selon MS-XLS §2.4.36. HotXLS n avait auparavant aucun cas dispatcher pour $000D, donc la valeur du fichier source etait jetee au chargement, et l ecrivain emettait toujours un $0001 code en dur (Automatique). Un mode Manuel choisi par l utilisateur revenait silencieusement a Automatique apres chaque sauvegarde HotXLS — mauvais pour les gros classeurs ou Manuel est defini exprès pour la performance. Le nouveau gestionnaire ParseCalcMode stocke la valeur source sur le classeur et StoreCalculationSettings emet maintenant la valeur stockee au lieu de la constante.
Nouvelle propriete TXLSWorkbook.CalculationMode. Propriete LongWord en lecture/ecriture acceptant xlCalcManual (0), xlCalcAutomatic (1, par defaut) ou xlCalcAutomaticExceptTables (0xFFFF) — trois nouvelles constantes exportees depuis lxTNC.inc. Le setter contraint les valeurs inconnues au defaut de la spec, donc un fichier source corrompu ne peut pas laisser le classeur dans un etat indefini. Le code existant qui ne touche jamais la propriete conserve la valeur par defaut heritee ("Automatique"), la sortie precedente est identique octet par octet pour les classeurs par defaut.

Version 2.88.16

Le choix "Erreurs de cellule comme" de la Mise en page survit maintenant au cycle de sauvegarde. L enregistrement BIFF8 Setup ($00A1) emballe la liste deroulante Mise en page → Feuille "Erreurs de cellule comme: affichees / <blanc> / <tiret> / <N/A>" dans les bits 10-11 de son mot grbit sous le nom iErrors, selon MS-XLS §2.4.257. HotXLS jetait auparavant ces bits a la lecture et les emettait a zero a l ecriture, donc un classeur que l utilisateur avait configure pour imprimer #DIV/0! comme #N/A revenait silencieusement a "affichees" apres chaque sauvegarde HotXLS. Le lecteur decode maintenant iErrors dans une nouvelle propriete TXLSPageSetup.PrintCellErrors et l ecrivain reconstruit le champ a partir d elle.
Nouvelle propriete TXLSPageSetup.PrintCellErrors. Propriete LongWord en lecture/ecriture acceptant xlPrintErrorsDisplayed (0, par defaut), xlPrintErrorsBlank (1), xlPrintErrorsDash (2) ou xlPrintErrorsNA (3) — quatre nouvelles constantes exportees depuis lxTNC.inc. Les appelants PageSetup existants qui ne touchent jamais la propriete conservent la valeur par defaut ("affichees"), la sortie d impression precedente reste inchangee.

Version 2.88.15

L alignement et l orientation des commentaires de cellule sont maintenant preserves a travers le cycle de sauvegarde. L enregistrement de base TXO BIFF8 ($01B6) porte cinq drapeaux types dans son mot grbit (hAlignment, vAlignment, fLockText, fJustLast, fSecretEdit) plus un mot rot separe pour l orientation du texte, selon MS-XLS §2.4.329. Le lecteur les laissait tous tomber et l ecrivain fixait grbit a la valeur codee en dur 0x0012 (gauche + haut) avec une rotation toujours 0, donc chaque sauvegarde ramenait un commentaire centre ou tourne a gauche+haut+horizontal quelle que soit la source. Le lecteur decode maintenant les champs types au chargement et l ecrivain compose grbit a partir d eux, donc la mise en page survit au cycle sauvegarder/recharger.
Six nouvelles proprietes de TMSOShapeTextBox pour styler explicitement les commentaires. HAlignment, VAlignment, Rotation, LockText, JustLastLine et SecretEdit sont exposees comme proprietes de lecture/ecriture sur chaque forme de commentaire ; AddComment s initialise par defaut a gauche+haut+horizontal+non verrouille, donc les appelants qui n y touchent pas conservent l apparence anterieure.
L ecrivain TXO dispose maintenant reserved4 / reserved5 selon les frontieres de champ de la spec. Le code precedent emettait les offsets 2-9 de l enregistrement de base sous forme de deux ecritures Long (rot + reserved4 puis reserved5) ; l ecrivain les divise maintenant en Word rot, Word reserved4, Long reserved5 — le contenu en octets est inchange (toujours tout zero pour les formes Note), mais la structure du code correspond maintenant aux offsets de champ de MS-XLS §2.4.329, ce qui rend les futurs correctifs TXO plus difficiles a mal aligner.

Version 2.88.14

Offset cchText de TXO corrige — le correctif de longueur de commentaire de v2.88.13 se declenche enfin vraiment. La version precedente a introduit une verification de coherence du record de base TXO en lisant cchText a l offset 8, mais MS-XLS §2.4.329 place cchText a l offset 10 (apres grbit, rot et les 6 octets reserved / controlInfo). L offset 8 tombe a l interieur du long reserved5 qui est toujours zero sur les objets de forme Note, donc chaque commentaire glissait silencieusement dans la voie defensive de repli — restaurant en fait le comportement d avant v2.88.13. Le correctif ramene l offset a 10, les longs commentaires s assemblent vraiment a travers les enregistrements Continue et les courts commentaires ne ramassent plus de padding final. Aucun autre changement de comportement au-dela de ce que v2.88.13 etait cense livrer.

Version 2.88.13

Les longs commentaires de cellule se relisent maintenant a leur pleine longueur. L enregistrement TXO BIFF8 ($01B6) divise son corps de texte entre l enregistrement de base et un ou plusieurs enregistrements Continue, le nombre de caracteres etant publie dans l enregistrement de base a l offset 8 sous cchText. Le lecteur de commentaires precedent ignorait entierement l enregistrement de base, traitait DataList[1] comme la totalite du texte et s y arretait — un commentaire de plus d environ 4100 caracteres larges etait silencieusement tronque, et un commentaire plus court dont l enregistrement Continue portait du padding final ramassait ces detritus en fin de chaine. Le lecteur consomme maintenant cchText comme nombre de caracteres faisant autorite, parcourt chaque segment Continue conforme a MS-XLS §2.4.329 (la coupure rgb se trouve sur une frontiere de caractere donc aucune comptabilite de caracteres partiels n est requise) et s arrete des que le budget est rempli, afin que le bloc de runs de formatage qui suit le texte ne deborde jamais dans la chaine. Les commentaires aux enregistrements de base corrompus ou manquants continuent d emprunter le chemin legacy "consommer tous les octets restants".

Version 2.88.12

Les chaines mises en cache de plus d environ 4100 caracteres provenant de formules retournant une chaine se conservent maintenant en aller-retour a travers les enregistrements Continue. v2.88.11 a branche le cote lecture de l enregistrement String BIFF8 ($0207) mais ne consommait que le corps du premier enregistrement. Une chaine en cache dont les octets UCS-2 depassaient la limite BIFF de 8224 octets et debordaient dans un ou plusieurs enregistrements Continue ($003C) etait silencieusement tronquee. Le gestionnaire parcourt maintenant l ensemble du DataList de la couche de repartition : il lit cch et fHighByte du record de base, copie le corps qui y entre, puis concatene chaque segment Continue suivant comme des octets bruts conformement a la garantie de frontiere de caractere de MS-XLS §2.5.293 — XLUnicodeString ne reemet jamais fHighByte au milieu d une chaine. Chaque segment est borne par le budget de caracteres restant, donc un Continue inutilement surdimensionne ne peut pas rendre le resultat plus long que cch. Les chaines a enregistrement unique (le cas courant) empruntent exactement le meme chemin rapide qu auparavant.

Version 2.88.11

Les formules qui renvoient une chaine conservent maintenant le texte mis en cache calcule par Excel lors d un aller-retour. La version precedente couvrait les variantes nombre, booleen, erreur et vide du cache BIFF8 FormulaValue (MS-XLS §2.5.133), mais laissait la variante chaine en suspens car sa valeur en cache reside dans un enregistrement String separe ($0207) qui suit immediatement l enregistrement Formula. ParseFormula se souvient maintenant des coordonnees de la cellule quand il voit une formule de variante chaine, et le nouveau gestionnaire ParseString decode l enregistrement $0207 qui suit conformement a MS-XLS §2.4.268 et achemine la WideString vers FCachedFormulaValue. GetCellValue peut maintenant se rabattre sur le texte calcule par Excel quand l evaluateur HotXLS ne peut pas le reproduire. Une reinitialisation defensive en tete de ParseFormula abandonne tout ancrage en attente obsolete afin qu un fichier source malforme avec un enregistrement String manquant ne puisse pas en mal acheminer un ulterieur. Les enregistrements plus longs que 8224 octets debordant en blocs Continue continuent de se rabattre sur la sortie de l evaluateur comme limitation connue.

Version 2.88.10

Les enregistrements de formules BIFF8 conservent maintenant la valeur en cache calculee par Excel lors d un aller-retour. ParseFormula sautait auparavant entierement la charge utile FormulaValue de 8 octets a l offset 6, donc le resultat en cache de chaque formule dans un .xls charge (nombres, booleens, erreurs, vide) etait jete et HotXLS devait reevaluer chaque cellule via son propre moteur de formules. Quand ce moteur ne pouvait pas correspondre a Excel (fonctions XLM non prises en charge, liens externes casses, formules pas encore implementees), la cellule devenait silencieusement vide ou affichait 0. Le lecteur decode maintenant les quatre variantes nombre / booleen / erreur / vide conformement a MS-XLS §2.5.133 et les stocke dans un nouveau champ TXLSCellRef.FCachedFormulaValue; GetCellValue ne se rabat sur ce cache que lorsque l evaluation echoue, donc les formules nouvellement creees passent toujours par l evaluation. La variante chaine continue de s en remettre a l evaluateur car le parseur de l enregistrement String ($0207) qui suit n est pas encore branche.

Version 2.88.9

Les enregistrements de formules BIFF8 avec des valeurs irresolubles activent maintenant fAlwaysCalc au lieu du bit reserved1. Quand l evaluateur HotXLS ne pouvait pas calculer une formule lors de l enregistrement, l ecrivain mettait grbit = 0x0002 — bit 1, que MS-XLS §2.4.127 reserve et demande aux lecteurs d ignorer. Excel l ignorait conformement, traitait la valeur 0 en cache comme reference et affichait silencieusement 0 au lieu de recalculer. L ecrivain met maintenant grbit = 0x0001 (fAlwaysCalc, bit 0), donc Excel relance la formule au prochain recalcul et la cellule affiche le bon resultat.

Version 2.88.8

PageSetup.PrintTitleColumns et PrintTitleRows levent maintenant une exception sur entree invalide. Affecter ces proprietes avec une chaine de plage mal formee (tout ce que ColDiapasonToValues ou RowDiapasonToValues ne pouvait pas analyser) abandonnait auparavant l affectation en silence — le classeur conservait la plage Print_Titles existante ou restait sans plage, et l appelant n avait aucun moyen de savoir que quelque chose avait echoue. Les setters levent maintenant Exception.Create avec un message descriptif nommant la valeur fautive, conformement au style raise existant sur les chemins d index invalide de TXLSRange.

Version 2.88.7

Le champ miyRw de Row reste maintenant dans la plage de la specification MS-XLS. Les versions pre-BIFF8 d Excel encodaient "utiliser la hauteur de ligne par defaut du classeur" en faisant un OR du bit 15 dans miyRw, et HotXLS a porte cet idiome dans son ecrivain BIFF8 alors meme que MS-XLS §2.4.221 plafonne miyRw a 8192 twips. Excel moderne emet un simple 255 (12.75 pt par defaut) dans le meme cas et signale les surcharges manuelles via le bit fUnsynced du grbit, donc le hack du bit 15 faisait diverger la sortie HotXLS des fichiers .xls de reference (une valeur de 32 959 = 0x80FF pour "par defaut" etait techniquement hors specification). L ecrivain laisse maintenant tomber le OR et ecrit 255 directement; le lecteur depouille encore le bit 15 en entree pour assurer la compatibilite ascendante avec HotXLS v2.88.6 et les fichiers anterieurs ainsi que les rares generateurs tiers qui ont copie l idiome BIFF5.
Note d errata pour le tour 2 d audit de la specification BIFF8 ajoutee. Une nouvelle verification des frontieres de champ [MS-XLS] a clarifie que deux conclusions signalees P2 dans le rapport original (dev-notes/XLS-BIFF8-Spec-Audit-Round2.md) ne sont pas des bugs reels : le bit 15 mis dans le drapeau d historique BOF $000080C9 appartient au champ verXLHigh (bits 14-17, valeur 2 = "Excel 2002"), et non a la queue reserved1 (bits 19-31); et l utilisation par ParseFormula d un token PtgExp en tete pour detecter les formules partagees / matricielles correspond a ce que la specification implique et leve l ambiguite correctement via le ShrFmla / Array suivant. Les deux items sont maintenant annotes comme retires.

Version 2.88.6

Les feuilles de macros et les modules VBA conservent maintenant leur emplacement ordinal BoundSheet8. Le lecteur abandonnait auparavant les enregistrements BoundSheet8 dont le champ dt valait 1 (feuille de macro) ou 6 (module VBA), donc la collection Sheets de HotXLS perdait ces entrees. Toute reference croisee XTI dans ExternSheet pointant en ordre de fichier vers une position de feuille au-dela d une feuille de macro se resolvait sur la mauvaise feuille HotXLS apres un SaveAs. Le lecteur ajoute maintenant une feuille marqueur pour chaque enregistrement BoundSheet8 et stocke l octet brut dt dans une nouvelle propriete Sheet.SheetTypeRaw; l ecrivain re-emet l octet original. Les enregistrements BOF de substream macro ($0040) sont aussi traites comme substream de feuille de calcul pendant l analyse, donc les cellules dans les feuilles de macros sont preservees au lieu d etre silencieusement absorbees par la feuille precedente.

Version 2.88.5

L'enregistrement Row BIFF8 conserve maintenant fCollapsed, fExAsc, fExDes et fPhonetic. Le lecteur abandonnait auparavant fCollapsed (grbit bit 4), et l'ecrivain l'inferait depuis les transitions de niveau de plan des lignes voisines, mal classant les lignes que le fichier source avait repliees ou marquees comme limites. Les trois bits superieurs (fExAsc en 28, fExDes en 29, fPhonetic en 30) n'etaient pas lus et toujours emis a zero car l'ecrivain tronquait le grbit de 4 octets a un ixfe de 16 bits. Le lecteur consomme desormais les quatre bits selon MS-XLS §2.4.221 et fixe fCollapsed comme explicite. L'ecrivain place ExAsc, ExDes et Phonetic dans les bits 12-14 du mot ixfe, masquant ixfe a la plage 12 bits autorisee. Les indications de bordure superieure epaisse ou inferieure moyenne pilotees par ExAsc et ExDes survivent maintenant a HotXLS SaveAs, et la visibilite phonetique sur les feuilles japonaises ne se reinitialise plus.

Version 2.88.4

Le bit fPaged de BIFF8 Window2 ne marque plus que la feuille active. Les versions précédentes positionnaient fPaged (MS-XLS §2.4.346 bit 10) sur toutes les feuilles visibles, ce qui faisait diverger la sortie HotXLS de ce qu'Excel écrit lui-même (selon la spécification, le bit signifie "cette feuille est actuellement affichée dans la fenêtre du classeur", donc seul le sous-flux de la feuille active devrait le porter). Les lecteurs Excel se rabattaient de toute façon sur Window1.itabCur pour identifier la véritable feuille active, donc cet abus était toléré ; Apache POI en mode strict et les autres outils qui font confiance à fPaged comme signal principal voient maintenant la bonne feuille marquée.

Version 2.88.3

Le zoom Window2 BIFF8 et la couleur des lignes de quadrillage sont désormais conservés lors d'un aller-retour. Les versions précédentes abandonnaient à la lecture tous les champs WINDOW2 au-delà de l'offset 6 et émettaient des zéros en dur à l'écriture, donc tout zoom de feuille enregistré dans Excel (75 pourcent, 125 pourcent, etc.) et toute personnalisation de couleur de quadrillage revenaient aux valeurs par défaut après un HotXLS SaveAs. Le lecteur consomme désormais icvHdr, wScaleSLV et wScaleNormal conformément à MS-XLS §2.4.346 : le zoom de la vue active alimente Sheet.Zoom et la valeur de la vue opposée se loge dans un emplacement de cache afin que basculer entre Normal et Aperçu des sauts de page dans Excel restaure le zoom précédent. L'écrivain émet le Sheet.Zoom actif dans l'emplacement de vue correspondant et la valeur mise en cache dans l'autre, plus l'index de couleur des lignes de quadrillage préservé.

Version 2.88.2

Correction de l'opcode de l'enregistrement BIFF8 HFPicture. Les fichiers .xls enregistrés émettent désormais les enregistrements d'image d'arrière-plan d'en-tête / pied de page avec le bon rt = 0x0866 conformément à MS-XLS §2.4.138. Les versions précédentes utilisaient 0x086C — l'opcode de CellWatch — ce qui amenait Excel à analyser le BLIP OfficeArt intégré comme une référence de cellule surveillée et à supprimer silencieusement l'image (refusant parfois d'ouvrir le classeur quand les octets de l'image violaient par hasard la structure 16 octets attendue par CellWatch). Les classeurs avec images d'en-tête / pied de page conservent désormais l'image lors d'un aller-retour via HotXLS.

Version 2.88.1

Correction de l'opcode de l'enregistrement BIFF8 Theme. Les fichiers .xls enregistrés émettent désormais l'enregistrement Theme avec le bon frtHeader.rt = 0x0896 conformément à MS-XLS §2.4.326. Les versions précédentes utilisaient 0x0892 — l'opcode de StyleExt — ce qui amenait Excel à interpréter la charge utile du thème OOXML intégré comme une extension de style de cellule et à se rabattre silencieusement sur le thème Office intégré. Les classeurs comportant des couleurs de thème personnalisées conservent désormais leur palette lors d'un aller-retour via HotXLS.

Version 2.88.0

**[MS-XLSX] quatrième cycle d'audit croisé — partie thème + définition du nom de la feuille.** Deux corrections ultérieures visant les problèmes restants après les cycles 1 à 3 (v2.51.0 / v2.52.0 / v2.54.1). Aucune de ces corrections n'affecte un emplacement d'appel existant ; l'une étend le comportement d'un paramètre, tandis que l'autre ajoute une nouvelle partie toujours émise.
**Les fichiers .xlsx enregistrés incluent désormais une partie `xl/theme/theme1.xml`.** Bien que `styles.xml` ait toujours généré des références `` pour toute couleur de police/remplissage/bordure/onglet définie via le chemin du thème (et pour les couleurs de thème héritées d'un fichier .xlsx d'entrée), aucune partie de thème n'était écrite, ce qui rendait ces références inutiles. Excel tolérait cette omission en revenant silencieusement à son thème intégré "Office", mais la validation des fichiers Office signalait chaque référence comme "partie de thème manquante", et le mode strict d'Apache POI rejetait le classeur lors de la première vérification. `SaveAs` génère désormais le thème Office (2007+) standard : un schéma de couleurs à 12 emplacements (couleurs système `windowText` / `window`, quatre couleurs par défaut Excel, six accents, deux couleurs de lien), le schéma de polices Calibri Light / Calibri, et le schéma de format valide minimal (trois entrées de remplissage/ligne/effet/remplissage d'arrière-plan par `CT_StyleMatrix`). `[Content_Types].xml` gagne une balise `Override` correspondante ; `xl/_rels/workbook.xml.rels` gagne une relation `theme/theme1.xml` qui se trouve à la fin de la plage d'identifiants, de sorte que les décalages `XlsxFirstExternalLinkRid` existants pour les feuilles/sst/styles/vba/liens externes restent inchangés.
**L'affectation directe de `Sheet.Name := '...'` effectue désormais également une validation et une déduplication.** Dans la version 3 (v2.54.1), le respect des règles de nommage Excel a été ajouté dans `TXLSXSheets.Add(AName)`, mais le setter de la propriété `TXLSXWorksheet.Name` était une simple écriture de `FName`, ce qui signifiait que le chemin de mutation le plus courant n'était pas pris en compte : `lxXlsxExport.pas:122 Target.Name := Source.Name` lors de la conversion XLS vers XLSX. Cela permettait de conserver n'importe quel nom présent dans la source BIFF8 (caractères interdits `: \ / ? * [ ]`, longueur > 31, guillemets simples, nom réservé `History`, doublons insensibles à la casse d'une feuille existante). Le setter de la propriété utilise désormais une nouvelle méthode `SetName` qui réexécute la même logique de validation `XlsxSanitizeSheetName` et de déduplication avec suffixe `' (N)'` (insensible à la casse, exclut l'entité elle-même) par rapport à la collection de feuilles du classeur parent. Les feuilles détachées (sans encore de pointeur `FWorkbook`) ignorent l'étape de déduplication et effectuent uniquement la validation. `TXLSXSheets.Add` appliquera l'unicité lorsque la feuille sera attachée. Cela est idempotent pour les noms déjà valides, de sorte que `FSheets.Add(names[i])` côté lecteur reste une opération de conversion pure.

Version 2.87.4

Les formules partagées XLS écrivent maintenant un corps ShrFmla valide. La sortie BIFF8 ajoute l'octet cUse requis avant la formule partagée, ce qui évite le décalage d'un octet avec UseSharedFormulas.
Les métadonnées de style et de filtre des tables XLS suivent maintenant la disposition MS-XLS actuelle. AddTable écrit LIST12 en List12TableStyleClientInfo, active les indicateurs AutoFilter dans Feature11 et émet les blocs vides Feat11FdaAutoFilter par colonne.
Les règles BIFF8 CF12 Data Bar / Color Scale / Icon Set n'écrivent plus de DXF interdit. HotXLS garde le bloc DXF vide comme l'exige MS-XLS et conserve les réglages dans la partie spécifique au type CF12.

Version 2.87.3

Les métadonnées de la table de la feuille de calcul XLS suivent désormais la disposition de la table `Feature11` spécifiée dans MS-XLS. La fonction `AddTable` pour les fichiers .xls écrit maintenant un en-tête de table `FeatHdr11` ainsi que les données `TableFeatureType` / `Feat11FieldDataItem` de `Feature11`, supprime le marqueur de table `FeatHdr` obsolète `$0867` et stocke les noms de table et de colonne sous forme de valeurs `XLUnicodeString`.
HotXLS prend désormais en charge la lecture correcte des tableaux XLS, conformément aux spécifications. HotXLS analyse les noms de tableaux, les plages, l'état de la ligne de totaux et les légendes des champs, tout en conservant une compatibilité avec les anciens enregistrements de tableaux générés par HotXLS.

Version 2.87.2

Les enregistrements de continuation BIFF8 pour les fichiers XLS ont maintenant les longueurs de base correctes. Les enregistrements XLS de grande taille, divisés par l'outil, mettent maintenant à jour la première longueur d'enregistrement à 8224 octets au lieu de conserver la longueur d'origine dans l'en-tête BIFF.
**Les grandes tables de feuilles de calcul XLS utilisent désormais des blocs ContinueFrt11 conformes à la spécification.** Les sorties AddTable larges avec de grandes charges utiles Feature11 sont maintenant enregistrées avec des enregistrements de continuation $0875 ContinueFrt11 et sont rouvertes avec les métadonnées de la table préservées, ce qui correspond à la disposition Feature11 / ContinueFrt11 de [MS-XLS].

Version 2.87.1

La limite de la grille de la feuille de calcul XLSX inclut désormais la dernière ligne et la dernière colonne d'Excel. `TXLSXRange`, `RCRange`, `EntireRow` et `EntireColumn` permettent désormais la ligne 1048576 et la colonne 16384 (XFD), ce qui correspond aux limites de numéro de ligne et de numéro de colonne définies dans [MS-XLSX]. Auparavant, la limite interne utilisait des maxima basés sur zéro, de sorte que `XFD1048576` et les plages touchant la dernière ligne ou la dernière colonne étaient silencieusement tronquées à la ligne/colonne précédente.
La documentation et les tests de chiffrement XLSX correspondent désormais au chemin d'écriture implémenté. Les pages d'aide et la suite de tests indiquent maintenant que `SaveAsEncrypted` génère une sortie de chiffrement conforme à la norme ECMA-376 pour les mots de passe non vides, tandis que `OpenEncrypted` lève toujours une exception pour les fichiers chiffrés et utilise une méthode alternative pour les fichiers .xlsx non chiffrés.

Version 2.87.0

**La sauvegarde avec mot de passe pour les fichiers XLSX fonctionne désormais (phase 2 de la vague J, tâche #29).** La méthode TXLSXWorkbook.SaveAsEncrypted(FileName, Password) écrit maintenant un fichier .xlsx protégé par chiffrement conforme à la norme ECMA-376 (format Office 2007+). L'ensemble du pipeline [MS-OFFCRYPTO] §2.3.4 est en place : la dérivation de mot de passe par itération SHA-1 de la phase 1, les blocs de vérification AES-128 et le corps de chiffrement AES-CBC, ainsi que le sérialiseur binaire EncryptionInfo, sont maintenant complétés par les quatre flux de métadonnées \005DataSpaces de la phase 2 (Version / DataSpaceMap / DataSpaceInfo / TransformInfo) et l'outil d'écriture de fichiers binaires OLE qui place tout dans un conteneur CFB. Excel ouvre le fichier avec le mot de passe de l'utilisateur. Flux de travail : l'appelant invoque SaveAsEncrypted avec un mot de passe non vide → HotXLS sérialise le classeur dans un fichier .xlsx zip en texte clair en mémoire → il est chiffré via AES-128 CBC avec un sel aléatoire de 16 octets et un vérificateur → la sortie CFB est écrite via StgCreateDocfile. Ouverture dans Excel 2007+ : saisissez le mot de passe → le contenu s'ouvre. Mot de passe incorrect : rejeté. La méthode OpenEncrypted (côté déchiffrement) est toujours une tâche distincte et continue de générer une exception EXlsxEncryptionNotImplemented lorsqu'elle reçoit un fichier chiffré.

Version 2.86.1

**Chiffrement standard XLSX — fondation cryptographique (phase 1 de la vague J, backlog #29).** Deux nouvelles unités internes implémentent la partie chiffrement et dérivation de clé de la voie d'écriture du chiffrement standard ECMA-376. `lxAES.pas` encapsule l'AES de Brian Gladman (lié depuis `thirdparty/Win32/aes*.obj` + `thirdparty/Win64/aes*.obj`) et expose les points d'entrée de chiffrement AES-128 ECB en bloc unique et AES-128 CBC. `lxXlsxStdEncrypt.pas` implémente SHA-1 en pur Pascal (FIPS-180-4), la dérivation de mot de passe en 50000 itérations selon [MS-OFFCRYPTO] §2.3.4.10, les blocs de vérification §2.3.4.7 (`EncryptedVerifier` + `EncryptedVerifierHash`), le chiffrement AES-CBC (préfixe de taille de 8 octets en ordre faible, remplissage avec des zéros jusqu'à une limite de 16 octets + vecteur d'initialisation de zéros) et le sérialiseur binaire `EncryptionInfo` §2.3.4.6. `TXLSXWorkbook.SaveAsEncrypted` lève toujours `EXlsxEncryptionNotImplemented` — la phase 2 de la vague J ajoutera l'écrivain de fichier binaire OLE (`\005DataSpaces` conteneurs) et connectera la pipeline à `SaveAsEncrypted`. En attendant, ces nouvelles unités sont une infrastructure interne de la bibliothèque dont les appelants ne doivent pas dépendre.

Version 2.86.0

**Synchronisation des tableaux de requêtes et des connexions de données externes (première phase, tâche en attente #28).** Les tableaux de requêtes et les connexions de données externes créés dans Excel (Données -> Obtenir des données externes à partir du Web / SQL / OLEDB) survivent désormais à un cycle d'enregistrement/ouverture de HotXLS. Auparavant, le lecteur BIFF8 ignorait silencieusement les balises QsiSXTag ($0802), QsiSXTagExt ($0810) et DConn ($0876), ce qui faisait que les métadonnées décrivant la requête source étaient perdues lors de l'enregistrement et que la table se dégradait en simples valeurs de cellules. Le lecteur capture désormais ces enregistrements sous forme d'octets opaques, et l'enregistreur les renvoie dans le flux de la feuille de calcul (ainsi que le bloc PIVOTVIEW conformément à [MS-XLS] §2.1.7.20.5) et dans les informations globales du classeur (ainsi que le bloc des informations globales tardives avant la fin de fichier conformément à §2.1.7.20.3). HotXLS ne modélise toujours pas la structure QSI/DConn typée de manière programmatique ; la création de nouveaux tableaux de requêtes à partir du code de l'appelant est reportée à une phase ultérieure ; cependant, les classeurs qui en contiennent déjà ne perdent plus les métadonnées de rafraîchissement. Uniquement pour BIFF8 (.xls) ; BIFF5 n'est pas affecté.

Version 2.85.1

**Restaurer la compilation de la bibliothèque Win32 / Win64.** Deux variables auxiliaires de ligne et d'élément dans l'émetteur de données multiples SXLI H5.3 ont été déclarées comme des types anonymes distincts `array of array of Word`, ce que le compilateur Delphi considère comme des types non nommés distincts et rejette lors de l'affectation directe avec `E2008 Types incompatibles`. La bibliothèque HotXLS n'a pas pu être compilée depuis la version v2.84.1 sur RAD Studio 12.0 jusqu'à la version 37.0. Les deux variables sont maintenant déclarées ensemble afin qu'elles partagent un seul type anonyme, ce qui corrige l'affectation et restaure les fichiers .dcu / .bpl pour les cibles Win32 et Win64. Aucun changement de comportement au moment de l'exécution ; les octets SXLI générés sont identiques à la version v2.85.0.

Version 2.85.0

**API pour les sous-totaux pivot typés (vague H5.4).** L'objet TXLSPivotField typé expose désormais une propriété d'ensemble Subtotals: TXLSPivotSubtotals, en plus de la propriété brute SubtotalMask: Word existante. Les appelants peuvent affecter, par exemple, Field.Subtotals := [xlpsSum, xlpsAverage]; au lieu de manipuler manuellement le champ SXVD grbitSub. Douze types de sous-totaux sont disponibles (xlpsDefault, xlpsSum, xlpsCount/CountA, xlpsAverage, xlpsMax, xlpsMin, xlpsProduct, xlpsCountNums, xlpsStdDev, xlpsStdDevP, xlpsVar, xlpsVarP), chacun correspondant à un bit unique selon [MS-XLS] §2.4.279. La propriété brute SubtotalMask reste la source de vérité pour la compatibilité ascendante ; les bits réservés 12 à 15 sont préservés lors de la lecture/écriture. Cela résout la limitation connue de la vague H4.3 "configuration du sous-total de champ de ligne SXVD.grbitSub indisponible via l'API" et complète les améliorations de la vague H5 pour les tableaux croisés dynamiques.

Version 2.84.1

**Extension de SXLI pour plusieurs champs de données (vague H5.3).** Lorsqu'un tableau croisé dynamique possède plus d'un champ de données ET que l'axe des champs de données correspond à un axe SXLI donné (DataFieldAxisIsRow = True et axe des lignes, ou DataFieldAxisIsRow = False et axe des colonnes), l'outil d'écriture réplique désormais chaque combinaison cartésienne DataFieldCount fois avec iData = 0 .. DataFieldCount - 1, plus DataFieldCount lignes de totaux généraux, de sorte que chaque champ de données ait son propre total. L'axe non hôte reste inchangé. Excel et autres lecteurs rendent désormais les tableaux croisés dynamiques avec plusieurs champs de données dans la disposition souhaitée par l'appelant, au lieu de recourir à l'approximation précédente consistant à afficher "un seul iData = 0 par combinaison". Les tableaux croisés dynamiques avec un seul champ de données produisent une sortie bit-identique à la version 2.84.0. La compression delta (H5.1) réduit les combinaisons répétées à environ 8 octets par réplique, de sorte que l'extension ajoute un faible surcoût en octets. Corrige la limite connue de la vague H4.3 "l'extension SXLI pour plusieurs champs de données n'est pas effectuée correctement".

Version 2.84.0

**API de pré-sélection de l'axe de la page pivot (vague H5.2).** Le type `TXLSPivotField` possède désormais une propriété `PageItemIndex` que les tableaux croisés dynamiques créés par programmation peuvent définir pour pré-sélectionner un élément de cache spécifique sur le filtre de l'axe de la page. La valeur par défaut `xlPageItemAll` (= $7FFD) conserve le filtre à la valeur "(Tout)", de sorte que les appels qui n'affectent jamais `PageItemIndex` se comportent de manière identique à la version v2.83.2. L'écrivain SXPI ($00B6) lit `Field.PageItemIndex` au lieu de coder en dur $7FFD, et le lecteur typé remplit maintenant `PageItemIndex` à partir de SXPI lors de l'ouverture, afin que les appelants puissent inspecter la sélection de page enregistrée. Cela résout la limitation connue de la vague H4.3 : "la pré-sélection de l'appelant du filtre de page n'est pas disponible via l'API".

Version 2.83.2

**Réduction de la taille des enregistrements SXLI de tableaux croisés dynamiques grâce à la compression delta (vague H5.1).** L'outil de création de tableaux croisés dynamiques compresse désormais les éléments de ligne SXLI en utilisant la compression delta, en tirant parti du champ `cSic` de la spécification : les indices des éléments de cache au début de chaque ligne qui correspondent à la ligne précédente dans le même enregistrement SXLI sont regroupés dans un compteur de préfixe partagé, et seuls les indices restants sont émis. Les enregistrements SXLI typiques de l'axe des lignes (quelques champs de ligne multipliés par des dizaines d'éléments) sont réduits de 30 à 60 % sans modification de la sémantique. La sortie est toujours divisée en blocs pour rester en dessous de la limite de 8224 octets des enregistrements BIFF. La première ligne de chaque enregistrement SXLI émet toujours `cSic = 0` (locale à l'enregistrement, sans référence croisée entre les enregistrements), et la ligne du total général n'est jamais compressée.

Version 2.83.1

**Les couleurs de remplissage, de police et de bordure des cellules, définies via RGB, sont maintenant correctement conservées lors de la sauvegarde et de la réouverture des fichiers .xls.** L'enregistreur XFExt (0x087D) de BIFF8 utilisait la position du tableau XF en mémoire pour le champ ixfe de chaque enregistrement, mais les enregistrements de cellules correspondants sur le disque utilisaient l'ordre SaveIndex après la suppression. Chaque fois qu'un XF antérieur dans le tableau était supprimé lors de la sauvegarde (ce qui se produit généralement lorsqu'une cellule passe d'un XF temporaire à un XF final), le champ ixfe de chaque XFExt était incorrect de la quantité de slots supprimés, et la couleur associée à chaque cellule se décalait vers une cellule voisine lors du rechargement. L'enregistreur résout maintenant SaveIndex pour chaque XF avec plusieurs slots et génère le ixfe correspondant sur le disque, de sorte que les couleurs RGB des cellules enregistrées par HotXLS (remplissage intérieur, couleur de la police, couleurs de bordure) sont conservées lors d'un cycle de sauvegarde/rechargement. Les enregistrements XFExt pour les XF qui ont été complètement supprimés sont maintenant ignorés au lieu d'être générés avec un ixfe incorrect.

Version 2.83.0

**Éléments de ligne de tableaux croisés dynamiques + état des éléments de page (vague H4.3).** Les tableaux croisés dynamiques créés par programmation émettent désormais des SXLI ([MS-XLS] §2.4.275, $00B5) pour les axes de ligne et de colonne, ainsi que des SXPI ($00B6) pour l'axe de la page. Cela garantit la fidélité de la mise en page de la vue du tableau croisé : les lecteurs autres qu'Excel affichent l'ordre exact que l'auteur a prévu, les grands tableaux croisés s'ouvrent plus rapidement (Excel n'a pas à recalculer la mise en page des lignes à partir de zéro), et les filtres de page persistent avec une sélection par défaut "(Tout)" pour chaque champ de page.
**Énumération de lignes et de colonnes SXLI.** L'outil énumère le produit cartésien des éléments de cache des champs d'axe (le champ le plus interne varie le plus rapidement, ce qui correspond à la disposition imbriquée des lignes d'Excel) et génère une ligne par combinaison, plus une ligne de total général à la fin, marquée par le bit `SXLI nTypes fGrandTotal`. Chaque ligne utilise `cSic = 0` (pas de compression delta, ce qui est plus simple mais au prix de quelques octets supplémentaires par ligne). La sortie est divisée en plusieurs enregistrements SXLI lorsque le nombre de lignes dépasse la limite de 8224 octets de BIFF ; une limite de sécurité de 16384 lignes empêche une expansion excessive sur des entrées problématiques.
**État de l'axe de la page SXPI.** Émis uniquement lorsqu'au moins un champ a Axis = xlpfaPageField. Chaque entrée fait 10 octets (isxvd + iCache + ipos + objId), avec iCache = $7FFD, ce qui indique "(Tout)". L'API pour la pré-sélection d'éléments de page spécifiques est reportée à la version H5. Les pivots sans champs de page n'émettent pas de SXPI (la feuille de calcul ABNF le liste comme optionnel).
**Corrige le problème H3 connu concernant la limite "SXLI / SXPI non émis".** Combiné avec H4.1 (formats de nombres pour les champs de données) et H4.2 (flux par enregistrement pour SXDBB), la version H4 corrige les trois limites connues dans le générateur de tableaux croisés dynamiques H3. Les tableaux croisés dynamiques créés via `IXLSWorksheet.AddPivotTable` incluent désormais des caches autonomes avec toutes les métadonnées de mise en page.

Version 2.82.0

**Cache de tableaux croisés autonome, flux par enregistrement (vague H4.2).** Les caches de tableaux croisés créés par programmation émettent désormais des enregistrements SXDBB ([MS-XLS] §2.4.272, $00C5 dans le contexte du cache) qui contiennent les indices champ-valeur par enregistrement, en utilisant l'encodage compactifié spécifié. Sans les enregistrements SXDBB, Excel devait actualiser le cache à partir de la plage source lors de l'ouverture, ce qui fonctionnait lorsque les données sources étaient présentes et inchangées, mais qui échouait lorsque la source était renommée/supprimée ou avait été modifiée depuis la création du tableau croisé. Le cache est maintenant autonome.
**Encodage compact par bits, conformément aux spécifications.** Chaque champ utilise `ceil(log2(itemCount + 1))` bits par enregistrement (y compris l'espace de contrôle). Les enregistrements sont alignés sur les octets, chaque nouvel enregistrement commençant sur une nouvelle limite d'octet. L'outil d'écriture divise le flux en plusieurs enregistrements SXDBB pour respecter la limite de taille de 8224 octets de BIFF, ce qui permet de traiter correctement les caches contenant des dizaines de milliers de lignes source.
**Le chemin de sauvegarde et de relecture reste inchangé.** Les caches pivot lus depuis le disque (FromRawBlobs = True) continuent d'utiliser le chemin d'accès aux octets bruts H1 pour la sauvegarde et la relecture, et le nouveau writer SXDBB ne s'active que pour les caches typés créés par `IXLSWorksheet.AddPivotTable`. Les classeurs mixtes (un cache sauvegardé et relecture, et un nouveau cache) génèrent les deux chemins d'accès de manière propre.

Version 2.81.0

**Format numérique des champs de données pivot (vague H4.1).** Les champs de données pivot peuvent désormais inclure une chaîne de format numérique Excel, de sorte que les données monétaires, en pourcentage ou de date s'affichent avec les glyphes corrects dans Open au lieu d'afficher des valeurs brutes au format général. La nouvelle méthode `IXLSWorksheet.PivotSetDataFieldFormat(DataField, FormatStr): Word` enregistre le format dans la table NumFormats du classeur (ajout automatique ou réutilisation) et écrit l'index ifmt résultant dans `TXLSPivotDataField.NumberFormat`. Cette méthode complète le processus, car le compilateur générique émet déjà SXDI.ifmt.
**Ajout d'une fonction d'aide `Public NumFormats` à la classe `TXLSWorkbook`.** `Workbook.RegisterNumFormat(FormatStr): Word` expose le même comportement d'ajout automatique au niveau du classeur pour les utilisateurs qui ont besoin des index `ifmt` dans des contextes autres que les tableaux croisés dynamiques. Si `FormatStr` est vide, la fonction renvoie l'index 0 ('Général').

**Utilisation par l'appelant.**

df := pivot.AddDataFieldByName('Revenue', xlpaSum);
Sheet.PivotSetDataFieldFormat(df, '$#,##0.00');
df := pivot.AddDataFieldByName('GrowthPct', xlpaAverage);
Sheet.PivotSetDataFieldFormat(df, '0.00%');

Version 2.80.1

Les formats conditionnels d'ensembles d'icônes sont maintenant correctement pris en charge lors de la sauvegarde et de l'ouverture avec HotXLS. La version v2.49.0 a modifié l'écriture de CF12 pour générer `ct=$06` pour les règles d'ensembles d'icônes conformément à [MS-XLS] §2.4.43 (la valeur correcte selon la spécification ; `0x05` est réservé pour les règles de filtre), mais le lecteur correspondant ne reconnaissait toujours que la valeur héritée `0x05`. Par conséquent, les fichiers .xls créés par HotXLS v2.49.0 à v2.80.0 perdaient leurs règles d'ensembles d'icônes lors du rechargement ; le type de règle était dégradé en une simple règle de cellule et les indicateurs de type d'ensemble d'icônes / Inversé / Afficher uniquement étaient réinitialisés aux valeurs par défaut. Le lecteur accepte désormais à la fois `0x05` (hérité de HotXLS avant la version v2.49.0) et `0x06` (spécification / v2.49.0+), de sorte que les classeurs de n'importe quelle version s'ouvrent correctement.

Version 2.80.0

Programmatic pivot table creation API (wave H3, MAJOR). New IXLSWorksheet.AddPivotTable(SourceRangeA1, DestRow, DestCol, Name): TXLSPivotTable method walks the supplied source range, infers each column's data type from the cell values, auto-builds a TXLSPivotCache (or reuses an existing one bound to the same range), and creates a typed pivot table on the destination sheet with one TXLSPivotField per cache field (axes initially unset).
Caller wires axes / data via convenience methods. pivot.AddRowField('Region'), pivot.AddColumnField('Quarter'), pivot.AddPageField('Year'), pivot.AddDataFieldByName('Revenue', xlpaSum). SetFieldAxis + AddDataField are exposed for finer control. Field axis enum: xlpfaRowField / xlpfaColumnField / xlpfaPageField / xlpfaDataField / xlpfaNone. Eleven aggregation functions: Sum, Count, Average, Max, Min, Product, CountNums, StdDev, StdDevP, Var, VarP.
Typed writer emits SX* records + cache substream. When pivot.FromRawBlobs = False (the default for programmatically created tables), the writer serialises the typed model into SXView ($00B0) + SXVD ($00B1) per field + SXVI ($00B2) per item + SXIVD ($00B4) row/col index arrays + SXDI ($00C5) per data field + SXEx ($00C6) into the worksheet footer. The matching pivot cache (cache.FromRawBlobs = False) emits a fresh BOF (dt=$0006) + SXDB ($00C6) header + SXFDB ($00C8) + SXFDBType ($00FB) + per-item SXSTRING / SXNUM / SXBOOLEAN / SXERR / SXDATETIME / SXEMPTY + EOF substream appended after the worksheet bodies.
Round-trip safety preserved. Pivot tables and caches read from disk keep their wave H1 FromRawBlobs = True flag and continue to round-trip via the raw-byte path. Only the new programmatically created pivots flow through the typed writer. Mixed workbooks (one round-tripped pivot + one new pivot via AddPivotTable) emit both paths cleanly.
Wave H3 limitations. Source range types other than rectangular A1 (named ranges, external workbook refs) are out of scope. SXLI / SXPI (line items / page items) are not emitted for typed pivots — Excel computes them on Open. Formatting customisation (data field number format beyond per-field NumberFormat) is exposed as a field but the writer treats it as 0 (general). Multiple pivots sharing a cache are supported but caller must wire the same source range string each time.

Version 2.70.0

**Modèle de lecture structuré pour les tableaux croisés dynamiques (vague H2).** En s'appuyant sur la préservation des octets bruts de la vague H1, le lecteur remplit désormais un modèle d'objet structuré afin que les appelants puissent inspecter la structure du tableau croisé dynamique sans analyse du code bytecode. De nouveaux types — TXLSPivotTable, TXLSPivotField, TXLSPivotItem, TXLSPivotDataField, TXLSPivotCache, TXLSPivotCacheField, TXLSPivotCacheItem, TXLSPivotCaches, TXLSPivotTables — sont accessibles via les nouvelles propriétés IXLSWorksheet.PivotTables et TXLSWorkbook.PivotCaches.
**Ce que le modèle capture.** Pour chaque tableau croisé dynamique : position (PremièreLigne / Colonne / DernièreLigne / Colonne / PremièreLigneDeDonnées / PremièreColonneDeDonnées), Nom, LégendeDesDonnées, CacheId, et une liste ordonnée d'Fields (chaque champ avec Nom, Axe ∈ {xlpfaRowField, xlpfaColumnField, xlpfaPageField, xlpfaDataField, xlpfaNone}, Items[], SubtotalMask, CacheFieldIndex). L'axe des données génère une liste parallèle de DataFields, chacun contenant une Aggregation provenant de l'énumération TXLSPivotAggregation à 11 valeurs (xlpaSum / Count / Average / Max / Min / Product / CountNums / StdDev / StdDevP / Var / VarP).
**Modèle de cache.** Chaque objet `TXLSPivotCache` contient un identifiant de cache, une plage source (feuille + limites de ligne/colonne basées sur 0), un nombre d'enregistrements et une liste de `Fields`. Chaque champ de cache contient son type de données (xlpcftNumber / String / Boolean / Error / Empty / DateTime / Mixed), son nom, son index de format numérique et une liste d'éléments uniques `Items[]`. Les indices par enregistrement pour chaque champ `Items[]` sont accessibles via `Cache.RecordIndices[Record, Field]` pour les caches créés par programme ; les caches chargés depuis le disque laissent ces indices non renseignés et s'appuient sur le chemin des octets bruts pour garantir l'intégrité.
**Sécurité des allers-retours.** Les tableaux croisés dynamiques provenant de données brutes ont `FromRawBlobs = True` ; l'outil d'écriture continue de réécrire les données brutes H1 telles quelles. Le modèle typé est rempli comme une projection optimisée pour l'introspection par l'appelant. L'outil d'écriture de modèle typé qui génère les données binaires à partir du modèle est limité à la version H3 (API AddPivotTable).
**Nouvelle unité lxPivot.pas.** Tous les types de tableaux croisés dynamiques sont regroupés dans leur propre unité, aux côtés de lxChart, lxFormula et lxNames. lxHandle réexporte les types publics afin que les importations existantes continuent de fonctionner.

Version 2.69.0

**Préservation des tableaux croisés dynamiques lors des opérations aller-retour (vague H1).** HotXLS conserve désormais chaque enregistrement qui constitue un tableau croisé dynamique lorsqu'un fichier .xls créé dans Excel est ouvert, puis enregistré. Avant cette version, le lecteur ignorait silencieusement les enregistrements SX* non reconnus (SXView, SXVD, SXVI, SXIVD, SXLI, SXPI, SXDI, SXAddl, etc.) et ignorait l'ensemble du sous-flux de cache du tableau croisé dynamique, ce qui entraînait des tableaux croisés dynamiques corrompus dans Excel lors de la réouverture d'un fichier de tableau croisé dynamique Excel. Le lecteur capture désormais tous ces éléments sous forme d'octets opaques, et l'enregistreur les réécrit tels quels, de sorte que le tableau croisé dynamique de la feuille de calcul principale s'affiche toujours correctement dans Excel après un cycle d'enregistrement/rechargement.
**Bloc PIVOTVIEW de la feuille de calcul.** Les enregistrements de vue SX* ($00B0–$00B2, $00B4–$00B6, $00C5–$00C8, $00D0–$00D2, $00D5, $00E3, $00F0, $00FB, $0100, $0864) sont capturés dans l'ordre du flux et émis dans le pied de page de la feuille par l'outil d'écriture (entre le bloc Tables et la fin de fichier), conformément à la position ABNF de la feuille de calcul [MS-XLS] §2.1.7.20.1 pour PIVOTVIEW. Les charges utiles SXAddl de taille excessive sont transmises via le séparateur Continue existant ($003C), de la même manière que les HFPicture.
**Sous-flux de cache de tableaux croisés.** Un enregistrement BOF (dt=$0006) est suivi par des enregistrements SXDB / SXFDB / SXFDBType / SXSTRING / SXNUM / SXBOOLEAN / SXERR jusqu'à l'enregistrement EOF correspondant, et l'ensemble est considéré comme un seul bloc de cache. Chaque classeur contient plusieurs caches, et chacun reçoit son propre bloc. Lors de la sauvegarde, le programme réécrit le sous-flux BOF / enregistrements / EOF complet pour chaque bloc de cache et l'ajoute au flux OLE du classeur après les sections spécifiques à chaque feuille, comme spécifié dans [MS-XLS] §2.1.7.20.
**Portée :** conservation des octets bruts uniquement (H1). Wave H1 ne traite pas intentionnellement les données de tableaux croisés dynamiques pour les convertir en un modèle structuré — les classes TXLSPivotTable, TXLSPivotField, TXLSPivotCache et l'API AddPivotTable sont prévues pour les versions futures H2/H3. En attendant, les utilisateurs de HotXLS ne peuvent pas inspecter ou modifier la structure des tableaux croisés dynamiques, mais les tableaux croisés dynamiques créés dans Excel peuvent être importés et exportés via HotXLS sans perte de données.

Version 2.68.0

**Fonctionnalité 3 de la sous-fonctionnalité F du backlog des graphiques : barres d'erreur des séries.** `TXLSChartSeriesInfo` a maintenant un champ `ErrorBars: array of TXLSChartErrorBarsInfo`. Chaque entrée génère un enregistrement SerErrBar ([MS-XLS] §2.4.105, $105B) dans le bloc Series parent, après les lignes de tendance et avant la fin de la série, dans l'ordre de l'appelant. Un graphique en colonnes typique avec des barres d'erreur Y utilise deux entrées (Sertm=1 Y+ et Sertm=2 Y-); les graphiques de dispersion/bulles ajoutent des paires X+/X- (Sertm=3 / 4).
**Cinq sources de valeurs.** `Ebsrc` sélectionne 1=pourcentage, 2=valeur fixe, 3=écart type, 4=erreur standard, 5=personnalisé. `NumValue` contient la magnitude (10,0 = 10% lorsque `Ebsrc=1`, valeur scalaire brute pour la valeur fixe, multiplicateur pour l'écart type). Pour la valeur personnalisée (`Ebsrc=5`), le champ `Cnum` contient le nombre de points de données personnalisés ; la spécification indique que DOIT=0 pour les autres sources, donc le générateur force les entrées non personnalisées à `Cnum=0`, quel que soit l'entrée de l'appelant.
**Bouton de commutation pour l'affichage des "T-caps".** `FTeeTop` contrôle si Excel affiche des "T-caps" en forme de T aux extrémités des barres (par défaut visuel d'Excel = activé). Utile lorsque l'appelant souhaite un style plus minimaliste, avec uniquement les "tiques".
**Avertissement concernant les séries de valeurs personnalisées (Ebsrc=5).** Le générateur minimal émet l'enregistrement SerErrBar avec le Cnum choisi, mais ne génère pas encore le cluster BRAI associé qui pointe vers le tableau de valeurs personnalisées. Par conséquent, les barres d'erreur personnalisées s'affichent avec une magnitude par défaut jusqu'à ce qu'une version ultérieure établisse la liaison avec le cluster BRAI. Les pourcentages, les valeurs fixes, les écarts types et les écarts types standard (Ebsrc 1 à 4) sont entièrement fonctionnels dans cette version.

Version 2.67.0

**Fonctionnalité secondaire F, vague de retard de fonctionnalités des graphiques, sous-fonctionnalité 2 : Lignes de tendance des séries.** `TXLSChartSeriesInfo` a maintenant un champ `Trendlines: tableau de TXLSChartTrendlineInfo`. Chaque entrée génère un enregistrement de ligne de tendance ([MS-XLS] §2.4.328, $2050) dans le bloc Series parent, après SerToCrt et avant la fin de la Series, dans l'ordre de l'appelant. Il est légal d'avoir plusieurs lignes de tendance sur une seule série, et Excel les affiche toutes.
**Six types de régression.** `Regt` sélectionne 0=polynomial, 1=exponentiel, 2=logarithmique, 3=puissance, 4=moyenne mobile, 5=linéaire. Pour les polynômes, le champ `NOrder` définit le degré (2..6) ; pour les moyennes mobiles, il définit la période (2..N). Pour les autres types, `NOrder` est ignoré, mais la spécification exige une valeur entre 1 et 6, donc le générateur remplace les valeurs nulles ou hors plage par 1 ou 6, respectivement.
**Affichage de l'équation et du R² + prévision.** `FDispEq` / `FDispRSqr` permettent d'afficher les étiquettes de l'équation et du R² directement sur le graphique. `NumForecast` / `NumBackcast` définissent les périodes d'extrapolation vers l'avant / vers l'arrière (Double, ≥ 0). `NumIntercept` définit l'ordonnée à l'origine ; utilisez NaN ($7FF8000000000000) pour "automatique".
**Étiquette de la ligne de tendance en tant que chaîne LPWide intégrée.** Le champ `Name` est écrit dans le champ sName de l'enregistrement de la ligne de tendance ([MS-XLS] XLUnicodeString : cch:2 + grbit:1 + corps UTF-16). Si le nom est vide, Excel génère automatiquement une entrée de légende, comme "Linéaire (Série1)".
**Refactorisation interne de `AddSeries`.** L'utilitaire interne `AddSeries` prend désormais un seul objet `TPreparedSeriesInfo` au lieu du triple précédent (Name, CatArea, ValArea), afin que les enregistrements associés à la série (prochaine phase : barres d'erreur) puissent être transmis via un seul paramètre, sans nécessiter de modifications ultérieures de l'interface.

Version 2.66.0

**Fonctionnalité 1 de la série de corrections de bogues F pour les graphiques : types de graphiques 3D.** Les feuilles de graphique créées par programmation peuvent maintenant demander les types de graphique 3D `xlsChartType3DColumn`, `xlsChartType3DBar`, `xlsChartType3DLine` ou `xlsChartType3DPie` via `AddChartSheet(Name, ChartType, ...)`. Les variantes 3D réutilisent le même enregistrement de type de graphique BARCHART/LINECHART/PIECHART que les variantes 2D, mais le bloc CHARTFORMAT environnant émet également un enregistrement Chart3d conformément à [MS-XLS] §2.4.46, ce qui permet à Excel de passer à son pipeline de rendu 3D.
**La géométrie 3D par défaut reflète la fonctionnalité "Insérer > Colonne 3D" d'Excel.** Rotation de 20°, élévation de 15°, perspective désactivée, regroupement activé, mise à l'échelle automatique activée, hauteur et profondeur égales à 100 % de la largeur, espacement de 150 %. Les murs et les axes à angle droit correspondent aux paramètres par défaut d'Excel. La géométrie est actuellement codée en dur (sans option de configuration pour l'utilisateur) ; la prochaine étape permettra de la transformer en un paramètre configurable.
**La forme Chart3DBarShape ($105F) est rétablie de manière conditionnelle.** Dans la version v2.55.0, l'émission inconditionnelle de Chart3DBarShape a été supprimée car [MS-XLS] §2.4.47 stipule que "DOIT être ignorée si le sous-flux actuel ne contient pas d'enregistrement Chart3d" et que les graphiques 2D n'en contiennent pas. Wave F la rétablit uniquement pour les graphiques à barres/colonnes 3D (avec un rectangle comme "riser" et sans "taper"), et elle est émise à côté de Chart3d dans CHARTFORMAT, de sorte que la relation avec la spécification est visible dans la disposition des données. Les graphiques linéaires 3D et les graphiques circulaires 3D continuent de ne pas l'utiliser (car il n'y a pas de concept de "riser/taper").
**Les diagrammes circulaires 3D ignorent les deux axes.** Le nombre d'axes utilisés et les chemins d'émission des axes traitent désormais `xlsChartType3DPie` de la même manière que `xlsChartTypePie` : le nombre d'axes utilisés est égal à 0, aucun axe de catégorie ni de valeur n'est émis. Sans cette modification, Excel affichait un diagramme circulaire 3D avec des lignes d'axes parasites qui traversaient le diagramme.

Version 2.65.0

Formula array constants round-trip with their data. PtgArray tokens ($20 / $40 / $60 — V / R / A class) in formula streams now carry their PtgExtraArray payload through both read and write paths. SUM({1,2,3}), =MMULT(...), {=COUNTIF(...)} and other array-literal formulas preserve the literal values in .xls files written by HotXLS instead of round-tripping with empty rgcb sections.
Array data hangs off the syntax tree. TXLSSyntaxItem grew ArrayCols / ArrayRows / ArrayValues properties (with the matching TXLSArraySerVal record describing num / str / bool / err / empty cells per [MS-XLS] §2.5.198.122 SerAr). Tools that walk the syntax tree can introspect array constants directly without needing the separate external-data container.
Programmatic array-literal construction. Code that builds TXLSSyntaxItem trees via the API can populate SA_ARRAY items with SetArrayDimensions + ArrayValues[i] and HotXLS emits the matching PtgExtraArray in the rgcb section automatically. The wire ordering matches the [MS-XLS] §2.5.198.59 rule that PtgExtraArray entries are sequenced by the position of their PtgArray token in the rgce stream.
Existing read path stays correct for mixed rgcb. The new code only consumes PtgExtraArray entries that correspond to PtgArray tokens it parsed; any other extra data (e.g. PtgExtraMem from PtgMemArea / PtgMemFunc, still unsupported) is left alone for downstream handling, and a malformed rgcb falls back to leaving array values empty rather than discarding the parsed tree.

Version 2.64.0

Chart backlog wave D phase 7: drawing theme color get / set round-trip within a process. Phase 5 introduced XlsApplyThemeColorToDrawing as a set-only helper because BIFF8 OfficeArt is a pre-Office-2007 binary format with no theme color slot on disk. The setter still down-casts to RGB for the on-disk OfficeArt opt blob, but the workbook now also keeps an in-memory side-table that remembers the original theme idx + tint per (TMsoShapeContainer, OfficeArt property id) pair. A new XlsGetDrawingThemeColor reader consults that side-table so the same process can pull back the theme intent it just wrote — useful for in-app render code that wants to highlight theme-driven colors or expose them in property panes. After Save / Open the side-table starts empty again and the getter returns False, falling through to ColorFormat.RGB.
New caller API. XlsGetDrawingThemeColor(ColorFormat, Workbook, out ThemeIdx, out Tint): Boolean joins the existing XlsApplyThemeColorToDrawing. The setter signature is unchanged; it now also records the entry into TXLSWorkbook.FDrawingThemeColors (a dynamic array of records keyed by container pointer + property id). Subsequent XlsApplyThemeColorToDrawing calls on the same slot overwrite the entry, so the table tracks the latest intent rather than accumulating history.
Stable identity through new internal properties. TXLSColorFormat grew read-only _Container and _Pid accessors so the helpers can compose the side-table key without the caller fishing private fields out of the class. Underscore prefix marks them as the same internal-API tier as _StringTable / _XFList / _BiffTheme: stable enough for library glue code, not part of the public contract.
Why this is "single-process round-trip" only. The BIFF8 OfficeArt format only stores indexed / RGB / scheme / sysColor in its 4-byte ColorRef; there's no extension record analogous to XFExt $087D where the theme idx + tint could live. So the disk round-trip cap is structural, not a HotXLS gap. The Phase 7 side-table bridges the in-process gap so app-internal code can pretend the format supports theme colors as long as it lives within one workbook session.

Version 2.63.0

Chart backlog wave D phase 6: compound border selectors round-trip RGB / theme through XFExt. The last theme-color known-limit is closed: Border[xlAround], Border[xlInsideVertical], Border[xlInsideHorizontal], and Border[xlInsideAll] now register the same RGB or theme color against every physical edge slot they target instead of falling back to the indexed-palette path. The new TXLSXfRichSlotSet (set of TXLSXfRichSlotID) lifts the pending-rich stash from a single slot to a set, so one cell-loop pass on SetRangeXFBordersProperty registers up to four XFExt slots in one go.
Compound selector mapping. The new BorderEdgeSlotSet(BorderIndex): TXLSXfRichSlotSet helper centralises the selector → slot translation: xlEdgeLeft / Right / Top / Bottom → singleton sets (unchanged from phase 2); xlDiagonalDown / Up → [rsDiag]; xlAround → [rsTop, rsBottom, rsLeft, rsRight]; xlInsideVertical → [rsLeft, rsRight]; xlInsideHorizontal → [rsTop, rsBottom]; xlInsideAll → [rsTop, rsBottom, rsLeft, rsRight]. Border.SetColor and Border.SetThemeColor share the same mapping, so RGB and theme paths behave identically across all selectors.
TXLSBorders.SetColor restored to a single dispatch. Phase 2 had to fan Borders.Color := V out to four per-edge GetBorder(edge).Color := V calls because the pending-rich stash only carried one slot at a time. With the set form, Borders.SetColor now stashes the full {rsTop, rsBottom, rsLeft, rsRight} set and calls SetColorIndex once — SetBordersColorIndex takes the optimal wire path (single cells loop with BorderMask=15), and ConsumePendingRichSlot registers all four XFExt slots on each touched XF in the same pass. ~4x fewer cell-loop iterations than the phase-2 fan-out, byte-identical XFExt result.
ConsumePendingRichSlot iterates the set. The slot-registration loop walks the eight enum members and dispatches each one present in FPendingRichSlot through RegisterXFExtSlot. Boundary cells whose XF didn't actually change during a compound-selector update still fire the callback — that's harmless because the XFExt slot is only visually relevant when the cell genuinely has the matching border line, and the indexed wire is set by the per-cell BorderMask Excel already understands.

Version 2.62.0

**Onde de travaux en cours sur les graphiques, phase 5 :** prise en charge des thèmes personnalisés en XML (aller-retour) + utilitaire de thème pour les graphiques. Trois améliorations comblent les derniers lacunes en matière de couleurs de thème que la phase 4 avait laissées en suspens. Les palettes de thèmes personnalisées définies dans Excel via "Mise en page" -> "Couleurs" sont désormais conservées lors du chargement : l'analyseur parcourt l'élément <a:clrScheme> intégré dans l'enregistrement de thème BIFF8 $0892 et met à jour le FBiffTheme de 12 emplacements du classeur. L'outil d'écriture correspondant génère le même enregistrement lorsque la palette s'écarte du schéma Office par défaut, de sorte que les thèmes personnalisés par l'utilisateur sont conservés lors de l'utilisation de HotXLS, sans revenir aux valeurs par défaut. Un nouvel utilitaire XlsApplyThemeColorToDrawing permet aux programmes qui utilisent des graphiques/formes de spécifier les couleurs des graphiques à l'aide du même vocabulaire d'index de thème + nuance que celui déjà utilisé pour les cellules.
**Lecteur : Analyse du XML de thème OOXML.** La fonction `ParseTheme` assemble le corps de l'enregistrement (frtRefHeaderU + dwThemeVersion + charge utile XML de longueur variable, qui peut s'étendre sur plusieurs enregistrements) dans un tampon unique et effectue une recherche de sous-chaîne ciblée pour les douze éléments enfants `<a:clrScheme>` (dk1, lt1, dk2, lt2, accent1..6, hlink, folHlink). Pour chaque emplacement, elle privilégie `<a:srgbClr val="RRGGBB"/>` et, si ce n'est pas disponible, utilise `<a:sysClr ... lastClr="RRGGBB"/>`, puis convertit `RRGGBB` dans le format COLORREF de HotXLS et appelle `FBiffTheme.SetThemeRGBColor`. Si le contenu ne ressemble pas à du XML OOXML (absence de l'indicateur `<a:clrScheme>`, variantes compressées ZIP, etc.), la palette conserve son schéma par défaut afin de garantir un rendu correct.
**Auteur :** Émission de l'enregistrement de thème avec saut lorsque la valeur par défaut est utilisée. La fonction `TXLSWorkbook.StoreTheme` émet un enregistrement `$0892` uniquement lorsque `IsBiffThemeDefault` indique que la palette s'est écartée du schéma par défaut d'Office. Le corps OOXML est construit à partir d'un modèle déterministe : douze entrées `` (choisies par rapport à la forme sysClr native d'Excel pour dk1/lt1 car elle permet une conversion sans nécessiter un résolveur de nom de couleur système), ainsi que les blocs `` / `` minimaux requis par le schéma. Les classeurs non modifiés n'émettent aucun enregistrement et restent compatibles en termes de taille de fichier avec les résultats antérieurs à la phase 5.
**Ajout d'une fonction d'assistance pour les couleurs de thème.** La nouvelle fonction gratuite `XlsApplyThemeColorToDrawing(ColorFormat, Workbook, ThemeIdx, Tint)` détermine l'index de thème et la teinte à partir de la palette du classeur et écrit la valeur RGB résultante dans un objet `TXLSColorFormat` (remplissage/contour/couleur du graphique de la forme). BIFF8 OfficeArt est un format binaire antérieur à Office 2007 qui ne prend pas en charge l'encodage natif des couleurs de thème, donc cette fonctionnalité est en écriture seule : la lecture renvoie la valeur RGB résolue plutôt que l'emplacement du thème, et la référence de thème aller-retour est perdue sur le disque. Pour une gestion complète des thèmes, utilisez `IXLSInterior.SetThemeColor` / `IXLSFont.SetThemeColor` / `IXLSBorder.SetThemeColor` pour les cellules, qui utilisent XFExt $087D.
**La fonctionnalité Wave D a été entièrement implémentée en cinq phases.** La phase 1 (v2.58.1) a ajouté la prise en charge des tableaux de cas, la phase 2 (v2.59.0) a implémenté XFExt pour les couleurs RGB des cellules, la phase 3 (v2.60.0) a finalisé le lecteur RGB, la phase 4 (v2.61.0) a ajouté le chemin des couleurs de thème aux cellules, et la phase 5 (celle-ci) complète le processus avec la gestion des fichiers XML de thème personnalisés et un module d'assistance pour le rendu. Les cellules correspondent désormais au rendu d'Excel pixel par pixel lors de la conversion, pour n'importe quelle combinaison de palettes de couleurs, de couleurs RGB ou de thèmes que la spécification BIFF8 peut exprimer ; les dessins conservent l'intention visuelle grâce au module d'assistance, mais utilisent le format OfficeArt, qui ne prend en charge que les couleurs RGB lors de la lecture.

Version 2.61.0

Chart backlog wave D phase 4: BIFF8 theme color support (theme idx + tint via XFExt $087D). Office's 12-slot theme palette (lt1, dk1, lt2, dk2, accent1..6, hlink, foHlink) now round-trips on the .xls side: callers can address theme colors directly with the new Interior.SetThemeColor(themeIdx, tint) / Interior.SetPatternThemeColor / Font.SetThemeColor / per-edge Border.SetThemeColor APIs, and the cell color getters resolve the same theme idx + tint back through the workbook's BIFF theme palette when reading. The XF record still receives a best-match indexed icv (so legacy readers like Excel 2003 keep rendering an approximate color), while Excel 2007+ recovers the exact theme intent through the XFExt FullColorExt (xclrType=3) future-extension record — same backward-compatibility trick Microsoft uses when "Save As" downgrades a theme-styled .xlsx to .xls.
New caller API. Five new SetThemeColor entry points join the existing RGB / index setters: IXLSInterior.SetThemeColor(ThemeIdx, Tint), IXLSInterior.SetPatternThemeColor(ThemeIdx, Tint), IXLSFont.SetThemeColor(ThemeIdx, Tint), and IXLSBorder.SetThemeColor(ThemeIdx, Tint) on each border edge. ThemeIdx is the 0-based theme slot (0=lt1, 1=dk1, 2=lt2, 3=dk2, 4..9=accent1..6, 10=hlink, 11=foHlink); Tint is the spec-style -1.0..+1.0 lighter/darker adjustment that gets encoded into FullColorExt.nTintShade as Q15 signed integer.
Workbook BIFF theme palette. TXLSWorkbook now carries an FBiffTheme: TXLSThemeColors initialised to the default Office theme scheme that the XLSX side has used for years through TXLSColorManager.FTheme. Cell color getters resolve theme idx + tint through this palette via GetThemeRGBColor(idx, tint) (which already applies HSL-based tint adjustment in lxRgb.GetRGBTInt). Internal _BiffTheme property exposes the palette for parser-side updates.
Theme record ($0892) acknowledged on read. lxRead.ParseTheme takes $0892 out of the default-skip path so the workbook-globals case table treats it as a known record. The embedded OOXML theme XML body itself is left unparsed for now — the 12 default Office theme colors already match the most common source and Excel-set theme cells render correctly through them. Workbooks with a fully customised theme will surface theme cells through the default palette here (documented known limit; XML-based theme parsing is a follow-up wave).
Why no Theme record on write. HotXLS-saved .xls files don't emit a Theme record. Excel 2007+ falls back to the default Office theme when no $0892 is present, which exactly matches HotXLS's FBiffTheme default scheme, so cells using SetThemeColor render with the right color in Excel without us having to ship the embedded XML. Files therefore stay smaller and the writer side has no XML-emit dependency.

Version 2.60.0

Chart backlog wave D phase 3: XFExt ($087D) read-side RGB / theme recovery closes the round-trip. The Phase 1 acknowledgement and Phase 2 emitter are now joined by a parser that actually consumes each $087D record into the workbook XF rich-color side-table. Files saved by Excel with RGB cell colors (fill, font, individual borders) now surface through cell.Interior.Color / Interior.PatternColor / Font.Color / per-edge Border.Color at the exact RGB Excel wrote, instead of the indexed-palette approximation HotXLS used to return for the same cells. Wave D is now fully closed in both directions.
Reader: ParseXFExt walks ixfe + cexts + rgExt. The parser handles the eight color ExtProp extTypes ($0004 fillFg, $0005 fillBg, $000D font, $0007/$0008/$0009/$000A/$000B for top / bottom / left / right / diagonal borders) and decodes each one's FullColorExt body (xclrType, nTintShade as signed Q15, xclrValue). xclrType 2 (RGB) and 3 (theme) get registered on the workbook side-table against the record's ixfe; other extTypes ($0006 FillGradient, $000E FontScheme, $000F TextIndent) skip cleanly so a future wave can add them without disturbing this code path. Defensive bounds checks on cb mean a malformed record terminates parsing of its tail without reading past the declared length.
Cell color getters consult the side-table first. The eight color getters that previously routed straight through the indexed-palette path (GetCustomColor(GetColorIndex)) now resolve their XF index, query TlxFormatList.TryGetRichSlot for the matching rich-color slot, and apply nTintShade via the existing GetRGBTInt helper when the slot carries an RGB value. xclrType=3 (theme) falls through to the indexed path: the BIFF workbook has no theme model on this call chain, so the palette approximation remains the best available answer for theme cells. Cells whose XF was never touched by a Phase 2 setter or a parsed XFExt produce the same byte-identical read result as before.
Wave D is closed. Save preserves caller-set RGB (Phase 2). Load preserves Excel-set RGB (Phase 3). Workbooks with no rich color information emit the same byte stream as before. The only remaining caveats stay documented as known limits: theme colors still down-grade through the BIFF palette because there is no theme color manager on this side of the codebase, and compound border selectors (xlAround / xlInside*) tag a single ambiguous side-table slot rather than per-edge — both rare enough to leave for a future wave.

Version 2.59.0

Chart backlog wave D phase 2: XFExt ($087D) emission for BIFF8 cell colors. When application code sets cell.Interior.Color := $00FF6633 (or any other RGB) on the BIFF8 path, the writer now emits a $087D XFExt record alongside the indexed-palette XF entry so Excel reopens the workbook with the exact RGB the caller passed in, rather than the closest 56-color palette approximation HotXLS used to fall back to. Covers all four cell color surfaces: Interior.Color / Interior.PatternColor / Font.Color / per-edge Border.Color (top / bottom / left / right / diagonal) and the convenience Borders.Color which now distributes to the four primary edges so each gets its own XFExt slot.
How the round-trip stays safe. The BIFF8 cell setter chain still produces the indexed-palette XF wire output it always did — readers (HotXLS or anything else) that ignore $087D see the legacy approximation. The XFExt record sits next to the XF and carries the original RGB as a 16-byte FullColorExt (xclrType=2, xclrValue=$00BBGGRR, nTintShade=0) wrapped in an ExtProp with the spec-correct extType for each slot ($0004 fillFg, $0005 fillBg, $000D font, $0007/$0008/$0009/$000A/$000B for top/bottom/left/right/diagonal borders). Cells that never took the color-setter path still emit no XFExt — workbooks with no rich colors produce the same byte stream as before.
Storage and bookkeeping. A new per-XF rich-color side-table in TlxFormatList holds the original RGB / theme info the cell setter passed in, keyed by the workbook's hash-resolved XF index. TXLSRange.SetXFProperty / SetRangeXFBordersProperty grew an optional OnNewIndex callback so the cell setter can register the rich color against every XF index the cell ends up on (multi-cell ranges that hash to multiple distinct XFs all get tagged). The side-table is consulted in StoreWorkbook right after STYLES and before PALETTE, matching the *XFExt position in [MS-XLS] §2.1.7.20.3 Workbook Globals ABNF. xlExcel5 output is untouched (BIFF5 has no XFExt record).
Known limit. The reader side stays at the wave-D-phase-1 acknowledgement: ParseXFExt consumes $087D records from the input stream but does not yet feed the recovered RGB back into the workbook's style objects, because doing so in the hash-keyed style model risks invalidating existing XF entries. Files saved by HotXLS now look correct in Excel; files coming in from Excel still surface the indexed-palette approximation when read back through cell.Interior.Color. Closing that read-side gap is a separate follow-up (Phase 3) that requires reworking the style hash to admit per-XF rich color before the first hash anchor.

Version 2.58.1

Chart backlog wave D (read-side acknowledgement only): XFExt ($087D) no longer routed through the default-skip path. A new ParseXFExt branch in the BIFF8 workbook-globals case table consumes $087D records that Excel writes alongside RGB and theme-colored cell styles. The reader still leaves the indexed-color XF record unchanged — full RGB / theme precision recovery onto the workbook's hash-key style model is deferred to a separate wave because it would require the BIFF writer-side style classes to grow an RGB / theme color field that doesn't exist today. Files coming from Excel with rich colors continue to load with the indexed approximation HotXLS has always produced, but the spec-conformance gap of "treating $087D as unknown" is closed.
Why not the full wave-D scope. The plan envisioned a paired write + read implementation, but exploration found that the BIFF write pipeline (TXLSWorkbook.FXFList: TlxFormatList) encodes XF style data as a string-key with hex-packed indexed color slots and has no analogue of the XLSX-side TXLSStyleColor (which carries ColorType / ColorValue / TintAndShade). Adding XFExt emission would mean either bridging the two style models or extending TlxFormatList with per-XF rich color side-tables, both of which are larger refactors than a single wave can absorb. The change here therefore stays surgical: lxRead recognises the record, lxStyleXf and lxHandle are unchanged.

Version 2.58.0

Chart backlog wave C: SST rich-text and phonetic round-trip (BIFF8 XLUnicodeRichExtendedString). Rich-text formatting set in Excel (a cell whose individual characters carry their own font / color, the "two colors in one cell" effect from the Format Cells dialog) sits in the shared string table as an XLUnicodeRichExtendedString with an attached rgRun FormatRun array. Far-East phonetic info (the furigana / hiragana annotation above kanji) attaches as an rgExtRst block on the same record. HotXLS previously dropped both on load and re-emitted the string as plain text on save, so opening then resaving a workbook flattened every multi-format cell to a single font / color. The shared-string parser now preserves both trailing blocks per unique string, and the writer re-attaches them when the string fits a single SST record.
Reader walks Continue boundaries without re-reading flag bytes. A new CollectRawTail helper inside ParseSST pulls the raw rgRun bytes (cRun × 4 bytes per FormatRun) followed by the raw rgExtRst bytes, spilling across Continue ($003C) records as needed — neither block is re-prefixed with the string's flag byte at a Continue boundary per [MS-XLS] §2.4.58, which the old per-byte skip logic could not preserve correctly when rt or sz overshot the current record. The preserved tails are registered against the workbook SST through the new TXLSStringTable.AddWithExtras, which deliberately does not bump the cell-reference counter so subsequent LabelSST parsing still produces correct cstTotal on save.
Writer attaches fRichSt / fExtSt + cRun / cbExtRst + rgRun + rgExtRst when the whole record fits in one BIFF chunk. AddSSTItem now factors the rich / phonetic tail size into its overflow check; strings whose body + tails fit a single 8224-byte SST chunk emit the full preserved layout, and Excel re-opens the workbook with the original formatting intact. Strings that overflow fall back to plain text without formatting (the splitter would otherwise need to interleave Continue flag bytes with the still-running rgRun byte stream, a state machine the current writer doesn't have); this is the explicit known limitation documented in the wave-C plan and affects only very long rich-formatted strings (> ~4000 wide chars).
Continue flag byte corner case fix (carried over from the v2.54.0 SST audit). Per [MS-XLS] §2.4.58 the leading flag byte of an SST Continue record carries only the fHighByte bit (bit 0); bits fExtSt (bit 2) and fRichSt (bit 3) MUST be ignored because those structures exist exactly once at the head of the first record. ParseSST now masks the Continue flag byte with $01, preventing a stray high bit from making the reader skip ahead 2 or 4 bytes looking for cRun / cbExtRst fields that aren't there and misaligning every byte that follows.

Version 2.57.0

**Amélioration de la gestion des images d'en-tête/pied de page (BIFF8 HFPicture).** Lorsqu'Excel enregistre une feuille de calcul avec une image d'arrière-plan dans l'en-tête ou le pied de page (Insertion → En-tête et pied de page → Image, puis le style du logo de l'entreprise), l'image est stockée dans un enregistrement `HFPicture` ($086C) qui contient un objet OfficeArt. Auparavant, HotXLS ne gérait pas ce type d'enregistrement, ce qui entraînait la suppression de l'intégralité des données lors du chargement, et donc la perte de l'image d'en-tête/pied de page lors de l'enregistrement du classeur. Désormais, le lecteur conserve l'intégralité de l'enregistrement (tous les blocs de continuation concaténés) par feuille, et l'enregistreur le réécrit à la position correcte selon les spécifications, afin qu'Excel rouvre le fichier avec les images d'origine.
**Le lecteur concatène tous les blocs "Continue" avant de stocker la charge utile.** La nouvelle branche `ParseHFPicture` dans `ParseWorksheetRecord` parcourt chaque élément de la `DataList` (le corps `$086C` dans le slot 0, plus un nombre quelconque de corps `$003C` qui suivent) et stocke les octets combinés sous forme d'un seul `TBytes` dans la feuille. Une feuille peut contenir plusieurs entrées — jusqu'à six dans l'interface utilisateur d'Excel (pages par défaut / première / paire × gauche / centre / droite) — donc le stockage est un tableau plutôt qu'un seul champ.
**L'outil Writer insère des enregistrements HFPicture immédiatement après PageSetup, puis laisse le séparateur Continue existant gérer le dépassement de capacité BLIP.** Une nouvelle étape, `StoreHFPictures`, s'insère dans la séquence de stockage par feuille immédiatement après `StoreSetup`, correspondant à la position `*HFPicture` dans [MS-XLS] §2.1.7.20.2, la définition ABNF de la feuille de calcul. Chaque corps préservé est enveloppé dans un nouvel en-tête $086C et acheminé via `AppendData` ; l'utilitaire `AddContinue` existant prend le relais lorsque le BLIP dépasse la limite BIFF de 8224 octets, de sorte qu'une image JPEG de 30 à 50 Ko se retrouve répartie sur un enregistrement $086C plus quatre à six enregistrements $003C, exactement comme Excel l'écrit.
**Aucune nouvelle API publique n'a été ajoutée.** Wave G est une fonctionnalité de préservation bidirectionnelle ; le contenu de HFPicture est opaque pour le code de l'application (il n'y a pas de méthode publique pour injecter une nouvelle image d'en-tête). Les classeurs qui n'avaient jamais de record HFPicture produisent une sortie identique à celle d'avant. La fonction auxiliaire interne `TXLSWorksheet._AddHFPictureBlob` est réservée au lecteur ; le préfixe souligné indique qu'elle est similaire à `_Drawing` / `_Autofilter`.

Version 2.56.0

**Onde de travaux en cours pour les graphiques B : synchronisation bidirectionnelle de la couleur de l'onglet (SheetExt BIFF8).** Les couleurs des onglets définies dans Excel via le menu contextuel "Couleur de l'onglet" sont désormais à la fois lisibles et modifiables via le chemin BIFF8. `TXLSWorksheet.TabColor` est une nouvelle propriété publique qui accepte une couleur `LongWord` de HotXLS (octet de poids faible = R, milieu = G, élevé = B, octet de poids fort = 0, même convention que `Font.Color` / `Interior.Color`); la valeur par défaut `0` signifie "automatique / pas de couleur d'onglet" et supprime complètement l'enregistrement.
**Le module Writer génère un enregistrement `SheetExt` (0x0862) par feuille.** Un enregistrement de 48 octets est ajouté au flux global du classeur juste avant la fin de fichier (EOF) pour chaque feuille dont la propriété `TabColor` est différente de zéro. La disposition suit [MS-XLS] §2.4.282 SheetExt v1 + §2.5.108 FullColorExt : le bloc de 12 octets `frtRefHeaderU` + 4 octets `cb` + 4 octets réservés `flagsTab1` + un bloc FullColorExt de 16 octets (xclrType=2 pour RGB, nTintShade=0, xclrValue=couleur de l'onglet) + 4 octets `iTabId` (ordre de flux basé sur zéro de la `BoundSheet8` correspondante) + 4 octets réservés `flagsTab2`. `iTabId` utilise le même ordre d'itération que le bloc `BoundSheet`, ce qui permet de maintenir l'alignement dans les classeurs multi-feuilles. La sortie xlExcel5 n'est pas modifiée (aucun enregistrement `SheetExt` dans BIFF5).
**Le lecteur restaure la couleur de l'onglet à l'ouverture.** Une nouvelle branche `ParseSheetExt` dans la table de cas de `ParseWorkbookRecord` lit `iTabId` et le bloc FullColorExt, puis écrit la valeur RGB résolue dans `Sheets[iTabId + 1].TabColor`. `xclrType=2` (RGB) stocke la valeur brute ; `xclrType=1` (indexé icv) la convertit via la palette du classeur (`Colors[icv, 0]`) afin que l'application voie une valeur RGB concrète, quel que soit la façon dont Excel l'a encodée ; `xclrType=0` (automatique) et `xclrType=3` (thème) laissent `TabColor` à sa valeur par défaut de `0`, ce qui correspond à la sémantique "pas de couleur d'onglet" du côté de l'écriture.
**Exemple de conversion aller-retour.** Définir `Workbook.Sheets[1].TabColor := $00FF00` (vert : B=0, G=$FF, R=$00) avant d'utiliser SaveAs pour enregistrer au format .xls crée un classeur qui s'ouvre dans Excel avec un onglet vert ; enregistrer ce même classeur et le rouvrir restaure la propriété à `$00FF00`. Les fichiers provenant d'Excel et contenant une ou plusieurs couleurs d'onglets sont maintenant ouverts sans perdre les couleurs, au lieu d'avoir chaque onglet par défaut sur automatique.

Version 2.55.1

**Restaurer la version principale.** Deux erreurs d'identification préexistantes qui empêchaient HotXLS de compiler sur RAD Studio 12+ ont maintenant été corrigées. Ces erreurs étaient présentes dans les versions précédentes, mais n'avaient pas de mécanisme de vérification de la compilation, de sorte que les problèmes n'ont été détectés que lorsque le prochain contributeur a essayé de reconstruire le package.
**Le module d'écriture de formules partagées multi-colonnes ne fait plus référence à un champ d'enregistrement manquant.** La correction du format de fil d'Ariane SHRFMLA dans la version v2.50.0 a ajouté `Data.AddByte(Group.LastCol)` dans `WriteShrfmla`, mais n'a pas étendu `TXLSShrfmlaGroup` avec ce nouveau champ, ce qui a empêché la compilation du package avec l'erreur "Identificateur non déclaré : LastCol". L'enregistrement contient désormais `LastCol` en plus du `FirstCol` existant, et `CollectSharedFormulas.OpenGroup` le remplit avec la colonne d'ancrage du groupe. Le comportement des groupes de formules partagées à une seule colonne (le seul type que le collecteur produit actuellement) reste inchangé ; le byte `colLast` correct, conformément aux spécifications, est maintenant une valeur réelle au lieu d'un alias de `colFirst`.
**Le module d'écriture de cellules XLSX fait référence à `XlsxFloatToStr` via une déclaration anticipée.** La correction de sécurité locale introduite dans la version v2.51.0 incluait un appel à `XlsxFloatToStr` dans la branche de la valeur de la cellule (ligne 2718), mais cette fonction auxiliaire est définie quelques centaines de lignes plus bas (ligne 2910). Sans une déclaration anticipée, le compilateur Delphi à passage unique signalait "Identificateur non déclaré : XlsxFloatToStr". Une déclaration anticipée est maintenant placée au début du bloc d'implémentation de `lxHandleX`, afin que à la fois le site d'appel initial et la définition existante soient compilés correctement.

Version 2.55.0

**Onde de travaux en cours pour les graphiques, phase A : amélioration de la gestion du cache pour les graphiques multi-séries + ajout de légendes pour les graphiques et les axes.** Deux limitations importantes de la création de graphiques ont maintenant été corrigées ; les deux proviennent de la liste des travaux en cours de la version v2.54.0. La première modification, côté émission, concerne uniquement le format des données (sans modification de l'API) ; la seconde utilise les paramètres existants de AddChartSheet, à savoir Titre / Titre de l'axe des catégories / Titre de l'axe des valeurs, qui n'avaient auparavant aucun effet.
**Mise en cache des valeurs par série, qui n'est plus tronquée à Series[0].** [MS-XLS] §2.1.7.20.1, la grammaire ABNF pour les feuilles de graphique autorise `*(SIIndex *NUMBER)` — un bloc `SIIndex(1) + N×NUMBER` par série. L'outil de construction de la phase 1 générait uniquement un bloc de cache de taille `Series[0].ValArea`, de sorte que toute série ultérieure avec une plage de valeurs plus longue voyait ses emplacements de cache tronqués silencieusement. L'outil de construction calcule maintenant (a) le nombre maximal de points parmi toutes les séries pour la plage de lignes `DIMENSIONS`, et (b) itère sur chaque série préparée, générant un bloc `SIIndex(1)` individuel dont le nombre de points correspond au nombre de points de cette série (`AreaPointCount(ValArea)`). Les emplacements de cache restent à zéro (les références BRAI `PtgArea3d` continuent de résoudre les cellules sources actives au moment du dessin) ; le changement concerne uniquement la fourniture d'une empreinte de cache complète au parser strict d'Excel.
**Les légendes de titre de graphique / titre de l'axe des catégories / titre de l'axe des valeurs sont maintenant correctement écrites.** L'implémentation de la phase 1 acceptait trois paramètres de titre dans les versions surchargées de `AddChartSheet` et les ignorait silencieusement ("Junk := Length(...)" comme espace réservé). Ils génèrent maintenant un bloc de légende attaché correct — `TEXT` ($1025) + `POS` + littéral `BRAI`-tStr + `SeriesText` ($100D) + `OBJECTLINK` ($1027) + Fin — à la position correcte, juste avant la fin du conteneur `CHART`, conformément à [MS-XLS] §2.1.7.20.1 CHARTTITLES ABNF. `OBJECTLINK.wLinkObj` utilise 1 pour le titre du graphique, 2 pour le titre de l'axe des valeurs et 3 pour le titre de l'axe des catégories, conformément à [MS-XLS] §2.4.182. Les appelants qui passent `Title := 'Quarterly Sales'` voient enfin "Quarterly Sales" affiché au-dessus de la zone de tracé dans Excel.

Version 2.54.1

**[MS-XLSX] Suivi de l'audit croisé.** Deux corrections ciblées issues de la liste "différée" de l'audit de la version v2.52.0. Les deux sont visibles par l'utilisateur et n'affectent aucun emplacement d'appel existant.
**Les cellules de date conservent leur format de date lorsqu'elles sont combinées avec n'importe quel style non numérique.** Une cellule `TDateTime` avec `FontIndex` / `FillIndex` / `BorderIndex` / `AlignmentIndex` / `ProtectionIndex` définis, mais sans `NumberFormatIndex` explicite, était auparavant traitée comme une cellule unique dont `numFmtId` était 0 (Général), ce qui faisait que Excel affichait la cellule comme un numéro de série brut (par exemple, `46038`) au lieu de `1/15/2026`. Le moteur de style XLSX traite désormais la date implicite comme une dimension virtuelle : toute autre dimension stylisée transforme la cellule en une cellule composite qui inclut `numFmtId=14` en plus de la dimension réelle. Les cellules de date pures, sans autre style, continuent d'être traitées comme auparavant, en utilisant `XlsxXfIndexDate`. Nouvelles fonctionnalités publiques : `TXLSXWorkbook.RegisterCompositeXf` / `GetCompositeXf` gagnent des versions avec 7 arguments qui acceptent un dépassement de `numFmtId` intégré OOXML (les signatures existantes avec 6 arguments restent inchangées et sont redirigées vers la nouvelle version avec le dépassement désactivé).
Les noms de feuilles qui ne respectent pas les règles de nommage d'Excel sont automatiquement corrigés. Excel rejette les noms de feuilles qui dépassent 31 caractères, qui contiennent les caractères `: , /, ? * [`, qui commencent ou se terminent par un guillemet simple, qui correspondent au nom réservé `History` (sans tenir compte de la casse), ou qui sont identiques à un autre nom de feuille (sans tenir compte de la casse). HotXLS transmettait auparavant directement l'entrée utilisateur brute, ce qui entraînait l'affichage d'une boîte de dialogue "Le nom que vous avez entré n'est pas valide" lors de l'ouverture du classeur. `TXLSXSheets.Add` normalise désormais le nom à l'aide de la nouvelle fonction utilitaire `XlsxSanitizeSheetName` (les caractères interdits sont remplacés par `_`, les guillemets simples environnants sont supprimés, la longueur est limitée à 31 caractères, les noms vides ou réservés sont remplacés par `'Sheet'`) et ajoute un suffixe `' (2)' / `' (3)'` en cas de collision (sans tenir compte de la casse). Cette opération ne modifie pas les noms déjà valides, de sorte que les feuilles extraites de fichiers .xlsx conformes restent inchangées.

Version 2.54.0

**Deuxième cycle d'audit approfondi des spécifications par rapport à [MS-XLS] v20250520 / [MS-OFFCRYPTO] v20240820.** Huit défauts indépendants, liés à des cas particuliers et aux formats de données, ont été détectés par huit agents de revue de code parallèles, qui ont examiné les enregistrements de la feuille de calcul, les limites de SST/Continue, la profondeur des PTG des formules, le remplissage du chiffrement, les enregistrements de graphiques, les modules de dessin/commentaires et la prise en charge des tableaux croisés dynamiques. L'API publique n'a pas été modifiée ; le code existant se recompile sans modifications.
**La structure d'enregistrement "Comment Note" est maintenant conforme aux spécifications.** Deux corrections distinctes ont été apportées dans `TMsoDrawing.StoreNotes` (conformément à [MS-XLS] §2.4.179 Note) : (1) `idObj` est maintenant écrit comme un Word (2 octets) au lieu d'un LongWord (4 octets), corrigeant un décalage de 2 octets qui désalignait chaque octet après `idObj` ; (2) le champ `stAuthor` XLUnicodeString, qui était auparavant absent, est maintenant sérialisé (cch + flags + corps UTF-16) à partir de `FAuthor` au lieu d'être remplacé par un simple `Word(0)`. Le lecteur strict d'Excel termine l'analyse de l'enregistrement "Note" à `stAuthor`, donc son omission corrompait les métadonnées du commentaire lors de la sauvegarde et de la réouverture, même si Excel ouvrait toujours le fichier.
**La propriété `Visible` ne modifie plus l'intention.** `TMSOShapeTextBox.GetVisible` / `SetVisible` retournait `True` lorsque `fHidden` était défini et stockait `fHidden` lorsque les appelants demandaient que le commentaire soit visible – la signification du bit est inverse ([MS-XLS] §2.4.179 grbit bit1: 1 = caché). Les appelants qui utilisaient `Comment.Visible := True` obtenaient auparavant des commentaires cachés ; maintenant, la propriété correspond à son nom dans les deux sens.
**Correction de la dérivation du mot de passe RC4 pour les mots de passe de 16 caractères ou plus.** [MS-OFFCRYPTO] §2.3.6.1 stocke le champ de longueur du message MD5 en bloc unique comme un compteur de bits little-endian de 64 bits dans les octets 56 à 63. L'ancien lecteur (lxDecryption) et l'ancien encodeur (lxEncrypter) écrivaient uniquement l'octet de poids faible via SetByte, ignorant silencieusement l'octet de poids fort pour les mots de passe de 16 caractères ou plus (longueur en bits ≥ 256). Les fichiers avec des mots de passe longs dérivent désormais la même valeur ValDigest des deux côtés ; auparavant, les mots de passe longs étaient rejetés même lorsqu'ils étaient corrects, et les fichiers chiffrés par HotXLS avec des mots de passe longs ne pouvaient pas être rouverts.
Le jeton `tFuncVar` pour les formules masque désormais le bit `fCeFunc` lors de la recherche du nom de la fonction. [MS-XLS] §2.5.198.63 divise le mot de fin en `tab(15 low)` + `fCeFunc(1 high)`; le lecteur stocke le mot entier dans `Item.IntValue` comme clé de la table de hachage, ce qui fait que les fonctions appelées avec l'indicateur de requête utilisateur (appels de macros/UDF) sont hachées en `$8000 | iftab` et produisent un nom de fonction vide, ce qui annule toute la formule. Maintenant, cela est masqué avec `$7FFF`.
**Plusieurs enregistrements FILEPASS sont désormais ignorés après le premier.** La spécification [MS-XLS] §2.4.117 autorise au maximum un seul enregistrement FILEPASS ; un fichier corrompu ou malformé contenant un deuxième enregistrement FILEPASS était utilisé pour libérer le déchiffreur actif et redériver un nouveau flux de clés en cours de traitement, ce qui le désynchronisait des données déjà traitées. Les enregistrements FILEPASS suivants sont maintenant supprimés silencieusement, tout en maintenant le chiffrement actif.
**L'opcode de la classe V de PtgArray est maintenant généré correctement.** Auparavant, `GetArrayData(aClass=0)` passait incorrectement à l'opcode de la classe A ($60); conformément à [MS-XLS] §2.5.198.32, l'opcode est $20 pour la classe V, $40 pour la classe R et $60 pour la classe A. `aClass=0` est maintenant correctement mappé à $20.
**La forme Chart3DBarShape n'est plus générée pour les graphiques 2D.** La spécification [MS-XLS] §2.4.47 indique que Chart3DBarShape "DOIT être ignorée si le flux de données actuel ne contient pas d'enregistrement Chart3d". HotXLS ne prend pas encore en charge les types de graphiques 3D (aucun enregistrement Chart3d n'est généré), donc l'écriture d'une Chart3DBarShape vide dans chaque bloc DataFormat était à la fois redondante et non conforme à la spécification (la charge utile vide ne respectait pas non plus la disposition riser+taper de 2 octets). L'enregistrement est maintenant complètement omis.
**Les problèmes détectés lors de l'audit ont été documentés dans le fichier `TechnicalNotes.md`.** Les lacunes importantes relevées lors du deuxième audit (absence d'émission d'enregistrements XFExt, non-sérialisation des données constantes PtgArray, suppression des paramètres de titre de graphique/titre d'axe de catégorie/titre d'axe de valeur, cache de graphique par série, tableaux croisés dynamiques/tableaux de requêtes/connexions de données non pris en charge) sont documentées comme des lacunes connues pour les développements futurs, plutôt que comme des omissions silencieuses.

Version 2.53.0

OpenOffice excelfileformat.pdf cross-audit round 2. Three additional BIFF8 wire-format fixes uncovered by re-running the spec sweep after v2.50.0, targeting modules the first pass had touched only lightly: the formula token decoder, the XF alignment byte, and the ROW outline-collapse boundary check.
Macro-command formulas with the user-prompt flag no longer corrupt the parser (§3.7.2 tFuncVar). The byte at offset+1 of a tFuncVar token packs the argument count in bits 6-0 ($7F) and the user-prompt flag in bit 7. Without masking, prompt-flagged tFuncVars were read as 128+N arguments, blowing the formula stack and yielding nil for the whole expression.
JustifyLastLine alignment flag round-trips correctly (§5.115 XF). The XF BIFF8 alignment byte (offset 6) packs HorAlign + WrapText + VerAlign + JustifyLastLine. Bit 7 ($80, JustifyLastLine) was never written, so cells configured with the flag reverted to the Excel default after save / reopen.
Row 0 / row 65535 no longer mis-flagged as outline-group boundaries (§5.88 ROW). The fCollapsed ($10) bit fired for the boundary rows when their explicit outline level differed from the absent neighbours' default level 1. Absent neighbours are now treated as matching the row's own level.

Version 2.52.0

**[MS-XLSX] audit croisée — deuxième tour.** Trois améliorations apportées au générateur de fichiers XLSX suite à l'audit de la version v2.51.0. Chaque modification est basée sur une clause spécifique des normes ECMA-376 ou W3C XML ; l'effet combiné améliore la compatibilité avec les lecteurs OOXML et réduit les messages d'erreur de validation.
**Les chaînes de caractères dans les cellules conservent les espaces au début et à la fin lors de la sauvegarde et de la réouverture.** Dans la fonction `XlsxFormatCellValue`, la méthode de repli pour les chaînes intégrées générait les balises `... sans l'attribut `xml:space="preserve"`; la normalisation XML 1.0 §3.3.3 supprimait les espaces environnants lors du chargement, de sorte qu'une cellule dont la valeur était " En attente " était renvoyée sous la forme "En attente". Les chemins d'accès pour les chaînes de caractères, les blocs de texte enrichi et le texte des commentaires comportaient déjà cet attribut ; la méthode de repli pour les chaînes intégrées est maintenant mise à jour pour correspondre.
**Chaque feuille de calcul contient désormais une indication `.** Bien que l'ECMA-376 §18.3.1.35 indique que l'élément `` est facultatif, chaque fichier .xlsx créé par Excel le contient ; les applications qui le lisent (Apache POI / NPOI / OOXML SDK) utilisent cette indication pour pré-dimensionner les tampons de cellules au lieu de les augmenter dynamiquement. L'outil d'écriture calcule maintenant le rectangle englobant des cellules remplies pendant la phase de regroupement des lignes et génère l'élément comme deuxième enfant de ` (après `, si présent, et avant ``). Les feuilles de calcul vides sont réduites à `.


        <sst count="..."> indique le nombre total de références de cellules, et non le nombre de chaînes uniques. L'ECMA-376 §18.4.8 définit `count` comme le nombre total de références et `uniqueCount` comme le nombre de chaînes distinctes ; l'auteur utilisait auparavant les deux comme `FStrings.Count` (toujours égaux), ce qui induisait en erreur les consommateurs d'OOXML concernant la densité des références. `TXLSXSharedStrings` suit désormais un `RefCount` distinct qui est incrémenté à chaque appel `Add` / `AddRich`, indépendamment de la déduplication, et l'attribut indique le nombre total de références réel.



      Version 2.51.0
      
        **[MS-XLSX] :** Vérification croisée réussie. Cinq corrections de format de données et de sécurité linguistique ont été apportées au module d'écriture XLSX, découvertes lors de la validation par rapport à la documentation Microsoft *[MS-XLSX] — Extensions Excel (.xlsx) au format Office Open XML SpreadsheetML* (version 20260108) et aux exigences du schéma XML 1.0 / OOXML. L'API publique n'a pas été modifiée ; les applications existantes peuvent être recompilées et enregistrées sans modification.
        Les fichiers .xlsx enregistrés s'ouvrent désormais dans toutes les régions Windows. Les marges de page, les largeurs de colonnes, les hauteurs de lignes, les tailles de police, les teintes de couleur, les teintes de thème, les tailles de texte enrichi de polices personnalisées et la valeur numérique de chaque cellule, encadrée par <v>, étaient sérialisées via la fonction `FloatToStr` sensible à la locale de Delphi. Sur Windows configuré pour une région dont le séparateur décimal est une virgule (la plupart de l'Europe continentale et certaines régions d'Asie/Amérique latine), le programme écrivait des valeurs d'attribut comme `width="8,43"` et `top="0,75"`, ce que le schéma OOXML rejette. Excel affichait un message du type "Nous avons trouvé un problème avec le contenu du fichier <file>.xlsx" et proposait une option de récupération qui effaçait les paramètres de page, les largeurs de colonnes et les valeurs numériques des cellules. Chaque attribut OOXML à double valeur utilise désormais un séparateur "." invariable, quel que soit la région active. La même correction corrige également le cache en mémoire des largeurs de colonnes/hauteurs de lignes qui stockait auparavant des chaînes formatées selon la locale ; `GetColWidth` / `GetRowHeight` renvoyaient `0.0` immédiatement après un appel à `SetColWidth` / `SetRowHeight` sur le même classeur dans ces régions.
        Les cellules contenant des caractères de contrôle ne corrompent plus le classeur. XML 1.0 §2.2 interdit les codes ASCII de 0x00 à 0x08, 0x0B, 0x0C, 0x0E à 0x1F (et U+FFFE / U+FFFF) dans tout document XML ; ils ne peuvent pas non plus être encodés comme références de caractères numériques. Les valeurs de cellules qui contenaient ces octets (données héritées, dumps de journaux, sentinelles de touches d'échappement) étaient auparavant écrites textuellement dans <t>...</t>, ce qui empêchait l'ouverture du fichier .xlsx et rendait les données inaccessibles. L'outil d'écriture supprime désormais silencieusement les caractères interdits ; les espaces valides (TAB / LF / CR) sont préservés.
        **Les sauts de ligne à l'intérieur des valeurs des attributs sont maintenant correctement conservés lors de la lecture et de l'écriture.** XML §3.3.3 normalise les caractères TAB / LF / CR bruts à l'intérieur d'une valeur d'attribut en un seul espace avant de transmettre la valeur à l'application. Les en-têtes / pieds de page multilignes, les commentaires des noms définis, les invites de validation des données multilignes, les chaînes d'affichage des hyperliens et tout autre attribut contenant un saut de ligne avaient tendance à se réduire à un seul espace lors du chargement. `XlsxEscapeAttr` émet désormais ces caractères sous forme de références de caractères numériques `&#x9;` / `&#xA;` / `&#xD;` afin qu'Excel les interprète comme les espaces blancs originaux.
        **Les entrées <col> sont émises dans l'ordre croissant des colonnes.** ECMA-376 18.3.1.4 / 18.3.1.13 exige que chaque entrée <col min="..."/> apparaisse dans l'ordre croissant de la valeur `min`.  L'ancien `TStringList(Sorted=True)` supprimait les doublons et triait les indices de colonne entiers lexicalement ("10" avant "2"), de sorte qu'une feuille qui personnalisait à la fois la colonne 2 et la colonne 10 produisait <col min="10"/> avant <col min="2"/>. Excel tolérait cette disposition, mais la validation des fichiers Office signalait le fichier, et les consommateurs OOXML stricts (mode strict d'Apache POI, LibreOffice avec la validation stricte activée) le rejettent. Les entrées de colonnes sont maintenant triées numériquement avant d'être émises.
      
    

      Version 2.50.0
      
        OpenOffice excelfileformat.pdf cross-audit pass. Eight follow-up wire-format and lifetime fixes uncovered by re-validating the BIFF8 writer / reader against the OpenOffice Microsoft Excel File Format documentation after the v2.49.0 [MS-XLS] pass. Public API is unchanged; existing applications recompile and re-save without modification.
        Shared formulas now span the full column range (§5.94 SHAREDFMLA). The SHRFMLA record body wrote colFirst into the colLast byte, collapsing every multi-column shared formula group to a single-column group in Excel. Fill-down formulas across two or more columns now expand to the correct cells when the workbook is reopened. The reader-side colLast width was also corrected.
        Shared formula Boolean / Error results round-trip correctly (§5.50 FORMULA). The same FormulaValue byte-layout bug fixed in v2.49.0 for standalone formulas was still present in the shared-formula writer (cells that carry a tExp token pointing at a SHRFMLA master). Cached TRUE/FALSE and #REF!/#DIV/0!/etc. values now appear as written.
        FORMULA option flags identify shared-formula members (§5.50 FORMULA). Cells inside a shared-formula group now set the fShrFmla bit (0x0008) in the FORMULA record option flags so strict parsers recognise the tExp token as a back-reference.
        Bold and underlined fonts identified correctly by strict readers (§5.45 FONT). The FONT option-flags word now sets bit 0 (bold) and bit 2 (underlined) in addition to the dedicated bls / uls fields.
        CFRULE option flags carry spec-mandated constant bits (§5.16 CFRULE). When at least one formatting block is present the option-flags DWORD now ORs in bit 7 (0x00000080, "Always 1") and bits 21-19 (0x00380000, "Always 111").
        CHOOSE() formulas read back correctly (§3.10.5 tAttrChoose). The tAttr parser previously skipped a fixed 4 bytes for every subtype; tAttrChoose ($04) is variable-length. The decoder now reads nc and advances by 6 + 2·nc bytes.
        Data-validation and conditional-formatting teardown no longer dereferences past the tail. Two Destroy destructors (TDataValidator, TCondFormatter) walked 0..cnt on lists whose valid indices are 0..cnt-1.
      
    

      Version 2.49.0
      
        **Vérification de la conformité aux spécifications [MS-XLS] v20250520.** Correction de seize problèmes liés au format et au comportement dans les modules suivants : générateur BIFF8, décodeur de formules, chemin de cryptage, générateur de graphiques, formatage conditionnel et validation des données, index SST/ExtSST, lecteur de stockage VBA et chemin d'ouverture du flux OLE. L'API publique n'a pas été modifiée ; le code existant se recompilera sans modifications. Les points importants sont indiqués ci-dessous.
        **Le champ `Formula` du format BIFF8 gère désormais correctement les résultats booléens et les erreurs.** [MS-XLS] §2.5.133. Le champ `FormulaValue` inclut le type dans le byte[0] et le code booléen-us/d'erreur dans le byte[1]; auparavant, l'outil d'écriture émettait `$0001`/$0002 comme mot et plaçait la valeur dans le byte[2], ce qui faisait que les formules booléennes mises en cache étaient lues comme "Faux" et les formules d'erreur comme "#NULL!" dans toutes les applications.
        **Les couleurs des cellules définies via `SetColorRGB` sont maintenant affichées correctement.** Le gestionnaire de couleurs écrivait `ColorType=1` (thème) pour les valeurs RGB et `ColorType=2` (RGB) pour les valeurs de thème, inversant ainsi les deux chemins de code. Désormais, les deux fonctions de définition de couleur acheminent les données vers le "bucket" `ColorType` correspondant, de sorte que les valeurs RGB sont traitées par le résolveur RGB et les indices de thème sont traités par le résolveur de thème.
        **Correction de l'obfuscation XOR et du déchiffrement RC4.** La boucle de déchiffrement XOR Method-1 correspond désormais à [MS-OFFCRYPTO] §2.3.7.3 (XOR d'abord, puis rotation vers la droite de 5 ; l'index de XorArray est dérivé de la position du flux d'entrée, et non de la position de post-traitement). La fonction Skip de RC4 parcourt désormais chaque limite de 1024 octets de manière continue au lieu de passer directement au bloc de destination, ce qui maintient l'état du flux de clés en alignement avec la position du fichier pour chaque appel ultérieur à Decrypt.
        **Le format de données des feuilles de graphique est maintenant conforme à la spécification.** Les enregistrements SIIndex sont émis dans l'ordre numIndex=1 → 2 → 3 ([MS-XLS] §2.4.262 ; auparavant, c'était 2 → 1 → 3, ce que les analyseurs stricts rejettent), le nombre de DEFAULTTEXT est limité au maximum spécifié de 2 ([MS-XLS] §2.1.7.20.1 ; auparavant, c'était 4), le placeholder Chart3DBarShape utilise l'ID correct $105F (auparavant, c'était $1066).
        Les enregistrements de conseils d'avertissement pour les hyperliens sont chargés correctement. Le décodeur du corps de l'enregistrement `HLinkTooltip` ($0800) lisait auparavant les champs d'ancrage `FrtRefHeader` aux décalages 2/4/6/8 au lieu de 4/6/8/10, ce qui empêchait la comparaison entre l'ancrage et la plage, et les conseils d'avertissement par cellule étaient supprimés silencieusement ; les conseils d'avertissement sont maintenant associés à leurs hyperliens. Le décodeur de référence de plage BIFF8 a également corrigé une erreur de frappe `FFirstColRel`/`FLastColRel` dans le chemin d'extension de signe de repli pour BIFF5/7 qui décodait incorrectement les plages avec des décalages relatifs de la dernière colonne négatifs.
        **Corrections apportées au formatage conditionnel et à la validation des données au moment de l'exécution.** Dans les classes `TCondRange` et `TDVRange`, la fonction `IsContainRow` renvoyait "true" uniquement lorsque la plage se réduisait à une seule ligne (la comparaison était inversée) ; le nettoyage des règles de formatage conditionnel/validation des données par ligne fonctionne désormais sur les plages multi-lignes. Trois destructeurs (CondFormat, formatter, DVRangeList) utilisaient `for i := 0 to cnt` sur des listes dont les indices valides sont 0..cnt-1 ; l'erreur d'un caractère était corrigée, et les charges de travail de longue durée ne provoquent plus occasionnellement des erreurs d'exécution pendant la fermeture. Les règles d'ensemble d'icônes CF12 émettent `ct=$06` (ensemble d'icônes selon [MS-XLS] §2.4.43) au lieu de `ct=$05` (filtre), de sorte que les classeurs contenant des règles d'ensemble d'icônes s'ouvrent avec les règles intactes.
        **Index de recherche rapide ExtSST conforme aux spécifications pour les classeurs volumineux.** Le champ `dsst` est maintenant calculé comme `max((cstUnique / 128) + 1, 8)` conformément à [MS-XLS] §2.4.107, au lieu de la valeur par défaut statique de 8 ; les classeurs contenant plus de ~900 chaînes uniques créent désormais un tableau de buckets `rgISSTInf` correct, et la recherche rapide SST d'Excel fonctionne.
        **L'enregistrement WriteAccess respecte [MS-XLS] §2.4.349, où cch <= 54.** Le champ `userName.cch` contient désormais la longueur réelle du nom d'utilisateur (6 pour "HotXLS"), et les octets restants sont remplis par le "remplissage" défini dans la spécification. Auparavant, ce champ contenait cch=109, ce qui est signalé par Office File Validation comme une violation de format.
        **Le chemin d'accès pour l'ouverture du flux de classeur BIFF8 correspond à l'orthographe spécifiée.** La première tentative d'ouverture du flux OLE utilise 'Workbook' (avec une majuscule 'W' conformément à [MS-XLS] §2.1.7.20) au lieu de minuscules, ce qui permet aux conteneurs de fichiers composites sur les implémentations OLE sensibles à la casse d'ouvrir le flux du premier coup.
        Le lecteur de modules VBA ne supprime plus le dernier octet de chaque flux. La longueur de recherche jusqu'à la fin utilisée était `trunc(l) - 1` au lieu de `trunc(l)`, ce qui tronquait la fin du flux compressé et provoquait l'arrêt anticipé du décompresseur de conteneur RLE pour certains modules.
      
    

      Version 2.48.10
      
        Les fichiers .xls sauvegardés par HotXLS incluent maintenant les deux flux d'ensemble de propriétés de fichier composé OLE qu'Excel attend sur chaque classeur : \005SummaryInformation et \005DocumentSummaryInformation. Avant v2.48.10, seuls les builds TRIAL les écrivaient (comme mécanisme de marquage de bannière) ; les builds de release produisaient des fichiers .xls dont le flux Workbook était du BIFF8 valide mais dont le conteneur OLE manquait les flux de métadonnées Office standard. Le parseur strict d'Excel 2003 traite cela comme la condition "File error: data may have been lost" (Excel moderne conserve la bannière Vue Protégée "ce fichier a des problèmes"). Ajouter les flux résout la boîte de dialogue sur les classeurs de graphique sans changer aucun enregistrement BIFF8.
        Les deux flux sont émis via le chemin Win32 StgCreatePropSetStg + IPropertySetStorage.Create + IPropertyStorage.WriteMultiple — le même code que Microsoft Office utilise, donc Office File Validation accepte la disposition d'octets. Le flux SummaryInformation est créé avec AppName="HotXLS" par défaut et auteur vide ; les builds TRIAL écrasent encore les valeurs Author / AppName avec la bannière d'essai via lxTrial.XlsTrialStampXlsSummary après le marquage par défaut, donc les fichiers d'essai restent identifiables dans le panneau Fichier > Informations > Propriétés d'Excel. Le flux DocumentSummaryInformation est créé vide (Win32 émet toujours l'en-tête de l'ensemble de propriétés + la propriété CODEPAGE — assez pour que le parseur strict d'Excel considère les métadonnées comme "présentes et bien formées").
        Cette correction est universelle — chaque .xls sauvegardé par HotXLS porte maintenant les métadonnées OLE standard, pas seulement les classeurs de graphique. Les sorties uniquement-feuille-de-calcul des releases précédentes échappaient au symptôme parce qu'Excel est plus indulgent avec les classeurs sans métadonnées uniquement-feuille-de-calcul qu'avec les classeurs avec feuille de graphique, mais il leur manquait aussi techniquement les flux. La nouvelle unité Lib/lxXlsSummary.pas détient les deux procédures auxiliaires ; lxHandle.pas les appelle inconditionnellement à l'intérieur de TXLSWorkbook.SaveWorkbook après que StoreWorkbook peuple le flux Workbook et avant FDocStorage.Commit.
        Cette release ferme la séquence de suivi du chart Phase 2 de huit versions (v2.47.0 — v2.48.10) : depuis la liaison de séries tArea3D, en passant par le réalignement de l'id BRAI, les valeurs observées d'Excel pour sdtX/cValx, le placement de SERIESTEXT, la suppression du remplissage du flux Workbook, les enregistrements shell au niveau feuille, et maintenant les flux de métadonnées OLE. Le résultat est un .xls de graphique qui s'ouvre dans Excel 2003 et Excel moderne sans aucun avertissement "le fichier a des problèmes", aligné au niveau octet avec ce qu'Excel lui-même écrit pour les mêmes données.
      
    

      Version 2.48.9
      
        Les feuilles de graphique BIFF8 portent maintenant l'ensemble complet d'enregistrements shell au niveau feuille qu'Excel 2003+ exige. Le chart_phase2_demo.xls de v2.48.8 rendait le graphique en colonnes correctement, mais Excel 2003 affichait toujours une boîte de dialogue "File error: data may have been lost" (les versions Excel plus récentes conservaient la bannière Vue Protégée) parce que le substream du graphique manquait des mêmes enregistrements au niveau feuille qu'un substream de feuille de calcul porte. Les vrais fichiers Excel (variantes from-scratch et re-saved de la sortie HotXLS) enveloppent les enregistrements du graphique dans ce shell :
          
            Avant les enregistrements du graphique (entre BOF et UNITS) : HEADER ($0014, vide), FOOTER ($0015, vide), HCENTER ($0083, valeur 0), VCENTER ($0084, valeur 0), SETUP ($00A1, configuration de page de 34 octets), PRINTSIZE ($0033, valeur 3).
            Après les enregistrements du graphique (après le CHART END le plus extérieur, avant EOF) : DIMENSIONS ($0200, 14 octets) déclarant la plage de données en cache, trois marqueurs SERIESINDEX ($1065) pour les emplacements de cache catégories / valeurs / tailles de bulles, un NUMBER ($0203, 14 octets) par point de valeur en cache, et WINDOW2 ($023E, variante de 10 octets pour feuille de graphique) à la fin.
          
          Les valeurs d'octets ont été copiées verbatim depuis dev-notes/biffview-refs/excel_column_chart_resaved.xls (la référence de graphique en colonnes sauvegardée par Excel, locale).
        
        Le cache de valeurs émet actuellement des marqueurs zéro (0.0 pour chaque point de données), correspondant à ce qu'Excel lui-même écrit lors du ré-enregistrement d'un graphique dont le cache source n'était pas pré-rempli. Le graphique trace toujours les vraies données car les références PtgArea3d du BRAI se résolvent aux cellules de la feuille source au moment du dessin — le cache est ce qui permet à Excel d'analyser la feuille de graphique sans avertissement, pas ce qui alimente le tracé. Une version future peut remplir le cache avec les vrais nombres de la plage Values ; le format wire est en place.
        Test fumée bout en bout : ouvrez le Demo/Delphi/XlsCreateChart/chart_phase2_demo.xls régénéré dans Excel 2003 — l'invite "File error: data may have been lost" n'apparaît plus, et le graphique en colonnes se rend identiquement à avant. Le même fichier s'ouvre proprement dans Excel moderne sans la bannière Vue Protégée.
      
    

      Version 2.48.8
      
        L'écrivain BIFF8 (.xls) ne remplit plus le flux Workbook avec des octets zéro de fin. TXLSWorkbook.StoreOleFile appelait auparavant StoreExtraSpace(Book) après les enregistrements de la dernière feuille, remplissant la longueur du flux jusqu'à la prochaine limite de 512 octets (secteur OLE). Le parseur strict d'Excel traite ces octets zéro finaux comme un flux factice d'enregistrements d'id 0x0000 et fait apparaître l'invite Vue Protégée "ce fichier a des problèmes" — visible sur le chart_phase2_demo.xls de v2.48.7 même après la correction du format wire BRAI / sdtX / SERIESTEXT et le rendu correct du graphique. Supprimer l'appel retire le remplissage du contenu du flux Workbook ; le remplissage de secteur OLE se produit toujours, mais dans la couche conteneur CFB sous le flux où Excel lui-même le place (chaque .xls sauvegardé par Excel a une longueur de flux Workbook non alignée sur secteur).
        Historique des symptômes : tout .xls sauvegardé par HotXLS dont la longueur totale en octets d'enregistrements valides n'atterrissait pas par hasard sur une limite de 512 octets portait le flux de zéros finaux. Le bug existait depuis le commit de bootstrap du dépôt mais se manifestait rarement — la plupart des classeurs ont assez d'enregistrements pour que le remplissage finisse petit (≤ 4 octets zéro tolérés par Excel). Les classeurs de feuilles de graphique atterrissent bien en dessous de la limite de secteur (le démo v2.47.0 — v2.48.7 remplissait 420 octets zéro), c'est donc là que l'invite Vue Protégée est devenue cohérente.
        La méthode StoreExtraSpace survit comme code mort privé dans lxHandle.pas au cas où un futur chemin de code aurait vraiment besoin de flux arrondis au secteur ; le site d'appel dans StoreOleFile est supprimé. La longueur du flux Workbook est maintenant exactement égale à la longueur en octets de tous les enregistrements valides (démo de graphique : 3164 octets ; référence Excel from-scratch : 4419 octets — les deux non alignés sur secteur). Les chemins de code lecteur ne sont pas affectés — HotXLS a toujours lu correctement les flux Workbook non alignés sur secteur des fichiers sauvegardés par Excel.
      
    

      Version 2.48.7
      
        Les enregistrements de séries de graphique BIFF8 sont enfin rendus correctement dans Excel. La correction consiste à réaligner les assignations d'id BRAI avec [MS-XLS] §2.4.51 — le plan d'implémentation parent les documentait inversées, propageant le bug à travers chaque sortie de graphique de v2.41.0 à v2.48.6. Les sémantiques d'id correctes sont :
          
            id = 0 — nom de série / étiquette de légende (le plan disait : categories)
            id = 1 — values (correct)
            id = 2 — categories (le plan disait : name)
            id = 3 — bubble sizes (le plan disait : errBars)
          
          Les symptômes Excel de l'inversion correspondent exactement : la plage Categories (étiquettes texte A2:A5) était émise comme BRAI id=0 → Excel la lisait comme le nom de la série et concaténait les quatre cellules en "North South East West" pour la légende / l'auto-titre. Le littéral PTG tStr 'Q1 Sales' était émis comme BRAI id=2 → Excel attendait une plage de cellules de catégorie là, trouvait un littéral de chaîne, abandonnait et rendait l'axe X comme quatre zéros.
        
        Également réaligné sur le format wire de graphique en colonnes sauvegardé par Excel : SERIES.sdtX est maintenant 0x0003 (la valeur observée d'Excel pour les catégories texte, pas 0x0001 documenté par [MS-XLS] §2.4.252), et cValx porte le décompte réel des catégories au lieu de 0. La règle "cValx MUST = 0 quand sdtX ∈ {1, 3}" est contredite par chaque échantillon Excel-saved examiné.
        Le porteur littéral de nom SERIESTEXT ($100D) revient, mais au bon endroit : immédiatement après le BRAI id = 0, toujours dans le bloc SERIES BEGIN/END. C'est ce que font les vrais fichiers Excel — le point d'émission de v2.48.5 (après tout le cluster BRAI, avant DataFormat) était incorrect et cassait le parsing du graphique ; la position correcte est juste à côté du BRAI du nom de série.
        Les fichiers de graphique sauvegardés par v2.41.0 — v2.48.6 portent tous le format wire BRAI inversé. Ils s'ouvrent dans Excel sans erreur mais montrent les symptômes de légende / axe X ci-dessus. Re-sauvegardez avec v2.48.7+ pour migrer ; pas de changement d'API — le même appel AddChartSheet produit maintenant un graphique qui se rend identiquement à ce qu'Excel lui-même écrirait pour les mêmes données.
        Nouvel outil d'inspection au niveau octet dev-notes/biffview-refs/dump_chart_substream.py qui vide le substream de graphique de n'importe quel .xls BIFF8 avec décodage par enregistrement (SERIES / BRAI / SERIESTEXT / AXIS / CATSERRANGE / LEGEND / OBJECTLINK / POS / TEXT). Utilisé pendant cette sortie pour byte-diff la sortie HotXLS contre les échantillons de référence sauvegardés par Excel ; disponible pour les suivis futurs de spec de graphique.
      
    

      Version 2.48.6
      
        Le substream de feuille de graphique BIFF8 retire les changements de v2.48.5. Les tests Excel réels sur la démo régénérée v2.48.5 n'ont pas du tout rendu le graphique — pire que la référence v2.47.0 (où le graphique se dessinait mais avec des étiquettes d'axe X erronées). Les deux changements de v2.48.5 en étaient la cause :
          
            SERIES.sdtX = 4 n'est en réalité pas accepté par Excel même si Apache POI expose CATEGORY_DATA_TYPE_TEXT = 4. [MS-XLS] §2.4.252 exige strictement que sdtX soit 0x0001 ou 0x0003.
            L'enregistrement SERIESTEXT ($100D) ajouté à l'intérieur du bloc SERIES BEGIN/END est une violation structurelle — SERIESTEXT appartient aux blocs TEXT (contextes de titre de graphique / titre d'axe / étiquette de données), pas à l'intérieur du bloc SERIES. L'y placer a fait que le parseur de graphique d'Excel rejette tout le substream.
          
        
        v2.48.6 restaure le format wire v2.47.0 ET ajoute une correction de conformité spec : SERIES.cValx est maintenant 0 quand sdtX = 1 (règle [MS-XLS] §2.4.252 spec MUST). Avant v2.48.6, on écrivait cValx = count (4 dans la démo) violant cette règle, ce qui contribuait peut-être à l'invite Vue protégée "le document a des problèmes" d'Excel. cValy porte toujours le décompte réel des valeurs (sdtY=1 n'a pas de règle de zéro).
        Nouvelle démo Delphi XlsCreateChart dans Demo/Delphi/XlsCreateChart/ crée un classeur à deux feuilles : une feuille "Data" avec quatre lignes (Region, Sales) et une feuille "Chart1" de graphique en colonnes dont la série lie Data!$A$2:$A$5 / Data!$B$2:$B$5 comme Categories / Values. La démo est le successeur permanent du chart_phase2_demo.xls ad hoc que v2.47.0 — v2.48.5 plaçait dans la racine du dépôt pour les tests BiffView ; le fichier racine a été supprimé, et la nouvelle démo écrit sa sortie à côté de son propre .exe.
        Non résolu connu : avec le format wire de v2.48.6, Excel continue de rendre les étiquettes de l'axe X du graphique en colonnes comme des zéros et de basculer sur la concaténation du texte des cellules de catégorie pour la légende (au lieu d'utiliser le littéral PTG tStr de BRAI id=2 'Q1 Sales'). C'est une vraie lacune de format wire qui nécessite un graphique en colonnes sauvegardé par Excel comme référence pour le diff — suivi en follow-up. La zone de tracé à 4 barres elle-même se rend correctement (hauteurs 100/150/200/175 correspondent à Values).
      
    

      Version 2.48.5
      
        Les enregistrements de séries de graphique BIFF8 s'affichent maintenant correctement dans Excel. v2.47.0 a connecté la liaison tArea3D pour les plages Categories / Values, mais Excel dessinait toutes les étiquettes de l'axe X comme 0 et utilisait le texte concaténé des catégories ("North South East West") comme légende et titre automatique, au lieu du Name fourni par l'utilisateur. Deux corrections restaurent le rendu prévu :
        Le champ sdtX de l'enregistrement SERIES est maintenant 4 (catégories texte), pas 1. [MS-XLS] §2.4.252 ne documente que 1 (dates) et 3 (séquence BIFF7), mais les vrais fichiers de graphique en colonnes / barres / lignes sauvegardés par Excel écrivent 4 pour les axes de catégories texte (correspondant à la constante CATEGORY_DATA_TYPE_TEXT d'Apache POI). Avec sdtX=1, Excel essayait de coercer les cellules 'North' / 'South' en nombres → fallback à 0 ; sdtX=4 laisse passer les étiquettes textuelles verbatim. L'ancienne forme wire violait aussi la règle de spec "cValx doit être zéro quand sdtX=1".
        Un enregistrement SERIESTEXT ($100D) est désormais émis dans le bloc SERIES BEGIN/END (après le cluster BRAI, avant DataFormat) chaque fois qu'un Name littéral est fourni. Le mécanisme de la première moitié de Phase 2 (BRAI id=2 + PTG tStr) est conservé pour la complétude de la spec, mais Excel récupère réellement l'étiquette de légende et le titre automatique depuis SERIESTEXT ; avec seulement la variante BRAI, Excel basculait sur la concaténation des cellules de catégorie. Après cette correction, la légende affiche le vrai Name (ex. 'Q1 Sales') et un titre vide laisse l'emplacement du titre automatique vide.
        Migration : les sorties de feuilles de graphique v2.42.0 — v2.47.0 s'ouvrent toujours sans erreur dans Excel mais présentaient les symptômes ci-dessus. Re-sauvegardez avec v2.48.5+ pour obtenir le format wire corrigé ; aucun changement d'API requis, le même appel AddChartSheet produit maintenant le bon graphique.
      
    

      Version 2.48.4
      
        L'émission BIFF8 CFEX ($087B) est retirée. HotXLS n'écrit plus le CFEX apparié après chaque CF12 — toute la configuration Data Bar / Color Scale / Icon Set voyage maintenant en ligne dans la queue par type CF12 (v2.48.1 — v2.48.3). Apache POI / NPOI ignorent CFEX de toute façon, donc c'est une pure simplification.
        Le chemin de lecture BIFF8 CF12 consomme maintenant la queue par type directement depuis CF12. Cela complète la réécriture du format wire Gap #6 en 5 PATCH (v2.48.0 header + v2.48.1 data_bar + v2.48.2 color_gradient + v2.48.3 multistate + v2.48.4 retrait CFEX).
      
    

      Version 2.48.3
      
        Les règles Icon Set de BIFF8 CF12 ($087A) émettent maintenant le sous-enregistrement multistate compatible NPOI en ligne, permettant à Apache POI / NPOI de lire la famille d'icônes, les seuils par palier et les drapeaux reverse / icon-only directement depuis CF12. La disposition correspond à NPOI IconMultiStateFormatting.Serialize().
        Les fichiers .xls HotXLS-générés v2.48.2 devraient être ré-enregistrés via v2.48.3 pour que les règles Icon Set reçoivent la nouvelle queue en ligne. Le retrait de l'émission CFEX arrive en v2.48.4.
      
    

      Version 2.48.2
      
        Les règles Color Scale à 2 et 3 paliers de BIFF8 CF12 ($087A) émettent maintenant le sous-enregistrement color_gradient compatible NPOI en ligne, permettant à Apache POI / NPOI de lire le seuil, la couleur et la position d'interpolation de chaque palier directement depuis CF12. La disposition correspond à NPOI ColorGradientFormatting.Serialize().
        Les fichiers .xls HotXLS-générés v2.48.1 devraient être ré-enregistrés via v2.48.2 pour que les règles Color Scale reçoivent la nouvelle queue en ligne. La queue Icon Set arrive en v2.48.3.
      
    

      Version 2.48.1
      
        Les règles Data Bar de BIFF8 CF12 ($087A) émettent maintenant le sous-enregistrement data_bar compatible NPOI en ligne (28 octets ajoutés après template_params), permettant à Apache POI / NPOI de décoder la couleur de la barre, les seuils min/max et les bornes de longueur en pourcentage directement depuis CF12, sans consulter l'enregistrement CFEX hérité. La disposition correspond à NPOI DataBarFormatting.Serialize().
        Les fichiers .xls HotXLS-générés v2.48.0 devraient être ré-enregistrés via v2.48.1 pour que les règles Data Bar reçoivent la nouvelle queue en ligne. Les queues Color Scale / Icon Set arrivent en v2.48.2 — v2.48.3.
      
    

      Version 2.48.0
      
        Disposition de l'en-tête BIFF8 CF12 ($087A) corrigée selon NPOI CFRule12Record.serialize() et les fichiers de référence sauvegardés par Excel. Excel écrit ext_formatting_length(4) avant les jetons de formule et un bloc template_params préfixé par longueur ; HotXLS avait ces champs dans le mauvais ordre. Les queues par type (data_bar / color_gradient / multistate) arrivent en v2.48.1 — v2.48.3.
        Les fichiers .xls HotXLS-générés v2.34.0 — v2.47.1 devraient être ré-enregistrés via v2.48.0 pour réécrire leurs enregistrements CF12. Le champ nID de 2 octets non-spécifié à la fin de chaque CF12 a été supprimé.
      
    

      Version 2.47.1
      
        Format wire de l'enregistrement BIFF8 CONDFMT12 ($0879) corrigé pour correspondre aux fichiers sauvegardés par Excel. L'implémentation précédente suivait un brouillon spec ancien qui laissait la plage associée de 8 octets comme "réservée" dans FtrHeader et insérait un champ Réservé de 4 octets inexistant avant numCF. Les fichiers .xls Excel remplissent réellement ces 8 octets avec la plage de cellules associée. Référence : poi_ConditionalFormattingSamples.xls enregistrement 152 correspond maintenant octet par octet.
        Les fichiers .xls HotXLS-générés v2.34.0 — v2.47.0 devraient être ré-enregistrés via v2.47.1 pour réparer leurs enregistrements CONDFMT12.
      
    

      Version 2.47.0
      
        La création de feuilles de graphique BIFF8 lie désormais des plages de données réelles aux séries. Les chaînes A1 Categories et Values transmises à la surcharge à 6 arguments de AddChartSheet (par exemple 'Data!$A$2:$A$5') sont compilées en jetons PTG tArea3D écrits dans les enregistrements BRAI id=0 (catégories) et BRAI id=1 (valeurs). Excel affiche maintenant de vrais points de données dans la zone de tracé au lieu du graphique vide produit par v2.42.0.
        La résolution du nom de feuille et l'enregistrement EXTERNSHEET sont automatiques : le parseur localise la feuille dans le classeur, enregistre une entrée XTI si elle n'existe pas et écrit l'ixti 0-based correspondant dans le corps de PtgArea3d. À la réécriture, le flux d'enregistrements du graphique est resérialisé via le compilateur de formules, maintenant ixti cohérent avec l'ordre final de EXTERNSHEET.
        Formes de référence acceptées : Sheet1!$A$2:$A$5 (absolue), Sheet1!A2:A5 (les marqueurs relatifs sont tolérés — les séries de graphique sont toujours stockées en absolu), 'My Sheet'!$A$1:$B$5 (noms de feuille avec espaces entre apostrophes) et références à une seule cellule comme Sheet1!$A$1 (se dégénère en PtgArea3d 1×1). Les comptes de points (cValx / cValy) sont dérivés automatiquement des dimensions de la zone.
        Les formes de référence non prises en charge basculent silencieusement vers le placeholder BRAI cce=0 style v2.41.0 pour que le graphique s'ouvre quand même dans Excel : références entre classeurs ([Book2.xls]Sheet1!...), plages nommées (Sheet1!ProfitColumn), références sans le préfixe ! de feuille et références pointant vers la feuille de graphique elle-même. Ces cas sont reportés aux phases ultérieures.
        Cela complète la Phase 2 de la Roadmap #10 (graphique en colonnes de bout en bout). Les libellés de série (première moitié de Phase 2, v2.42.0) plus la liaison de plages de série (cette release) signifient qu'un graphique en colonnes créé via AddChartSheet affiche désormais des entrées de légende correctes plus des données réelles sans post-traitement dans Excel.
      
    

      Version 2.46.0
      
        Le décodeur DXF côté BIFF8 résout maintenant les couleurs xclrType=1 (palette indexée) à partir de la palette standard Excel 2003 à 64 couleurs.
        La recherche utilise la palette par défaut Excel 2003 intégrée — icv 0..7 sont les 8 couleurs système, icv 8..15 reflètent les couleurs système, icv 16..63 sont les valeurs par défaut personnalisables standard. icv hors plage retombe au noir.
        La personnalisation du registre PALETTE BIFF8 n'est pas consultée — fichiers avec palettes personnalisées peuvent avoir de légères déviations.
        Chemins xclrType=0 (auto) et xclrType=2 (RGB) inchangés.
      
    

      Version 2.45.0
      
        Les règles de mise en forme conditionnelle font maintenant round-trip de l'attribut priority à la fois sur XLSX <cfRule priority="N"/> et sur le champ BIFF8 CF12 ipriority. Auparavant, chaque règle recevait une priorité séquentielle basée sur son index lors de la sauvegarde, et la priorité des fichiers sauvegardés par Excel était ignorée à la lecture.
        Nouvelle propriété Priority sur TCondFormatRule (côté BIFF8) et TXLSXConditionalFormat (côté XLSX). Défaut zéro, préserve le comportement auto-par-index ; valeur positive épingle la priorité.
        Priority contrôle la superposition multi-règles — quand plusieurs règles couvrent la même plage, Excel les applique dans l'ordre de priorité. Round-trip de priority préserve l'ordre de rendu prévu par l'utilisateur.
        Comportement par défaut inchangé pour les appelants qui ne touchent pas Priority : le writer XLSX continue d'émettre priority="1", "2"... dans l'ordre de la collection.
      
    

      Version 2.44.0
      
        Les règles de mise en forme conditionnelle Jeu d'Icônes supportent maintenant les substitutions d'icône par stop côté XLSX. Chacun des 3 / 4 / 5 stops peut se désinscrire du défaut familial et afficher n'importe quelle icône de l'une des 17 familles intégrées Excel 2007, identifiée par nom du jeu + id de l'icône. Élément OOXML : <cfIcon iconSet="OtherSet" iconId="N"/>.
        Nouvelles méthodes sur TXLSIconSetSpec : SetIconOverride(stopIndex, OverrideSet, IconId) et ClearIconOverride(stopIndex). Propriétés en lecture seule HasIconOverride[i], IconOverrideSet[i], IconOverrideId[i].
        Le writer XLSX émet des enfants <cfIcon> uniquement pour les stops qui ont appelé SetIconOverride. Le reader parse les éléments <cfIcon> entrants par position.
        Limitations connues : BIFF8 (.xls) CFEX n'a pas de slot pour les substitutions par stop ; une règle avec substitutions enregistrée en .xls rend le défaut familial pour tous les stops.
      
    

      Version 2.43.0
      
        Les règles de mise en forme conditionnelle XLSX (.xlsx) font maintenant round-trip des références de couleur de thème dans l'élément <color> des règles Barre de Données et Échelle de Couleurs. Auparavant le writer émettait uniquement <color rgb="FFRRGGBB"/> et le reader ignorait les attributs theme / tint.
        Nouvelles méthodes sur TXLSDataBarSpec et TXLSCfValue basculent le slot en mode thème : SetThemeColor(themeId, tint) et ClearThemeColor.
        Le writer XLSX émet <color theme="N"/> quand Tint vaut exactement 0.0, ou <color theme="N" tint="0.5"/> quand non-zéro.
        Comportement par défaut inchangé : les règles créées avec les points d'entrée RGB-only existants continuent d'émettre <color rgb="..."/> exactement comme avant.
        Limitations connues : BIFF8 (.xls) CFEX porte toujours uniquement la couleur RGB ; la résolution de palette de thème du classeur reste hors champ ; les règles iconSet ne portent pas d'éléments <color>.
      
    

      Version 2.42.0
      
        L'API de création de feuilles-graphique BIFF8 gagne une cinquième surcharge AddChartSheet qui accepte un tableau d'enregistrements TXLSChartSeriesInfo (Name, Categories, Values). Chaque Name non vide est écrit dans le sous-flux de graphique comme étiquette de série littérale via un token PTG tStr sur le BRAI de nom-de-série (id=2). Excel utilise cette étiquette dans la légende et le sélecteur de série, donc un graphique multi-série affiche désormais des légendes appropriées au lieu des espaces réservés par défaut "Series1 / Series2".
        TXLSChartSeriesInfo est ré-exporté depuis lxHandle avec TXLSChartType, pour que les appelants puissent construire le tableau sans importer lxChartBuilder directement.
        C'est la première moitié de Roadmap #10 Phase 2 (graphique en colonnes de bout en bout). Le chemin du nom-de-série est câblé ; la liaison de données catégorie et valeur (convertir les chaînes A1-range Categories et Values en vraies références tArea3D de plage de cellules dans le BRAI) reste un espace réservé — ces deux champs sont acceptés par l'API mais pas encore émis dans le sous-flux. Une version ultérieure les acheminera via le compilateur de formules et la table EXTERNSHEET pour terminer la seconde moitié de la Phase 2.
      
    

      Version 2.41.0
      
        HotXLS gagne la création programmatique de feuilles-graphique BIFF8. Un nouveau jeu de surcharges AddChartSheet sur Sheets écrit un sous-flux de graphique complet dans le fichier .xls enregistré, alors qu'auparavant les feuilles-graphique ne pouvaient être préservées que de manière opaque lors d'un round-trip load-save. Quatre surcharges couvrent les points d'entrée courants : nom seul / nom + type de graphique / + titre / + titre d'axe catégorie + titre d'axe valeur. L'IXLSWorksheet retourné apparaît dans la collection Sheets, reçoit une entrée boundsheet de feuille-graphique à l'enregistrement, et Excel l'ouvre comme onglet de graphique.
        Une nouvelle énumération TXLSChartType sélectionne le type de graphique : xlsChartTypeColumn, xlsChartTypeBar, xlsChartTypeLine, xlsChartTypePie. L'énumération est ré-exportée depuis lxHandle pour que le code utilisateur n'ait pas besoin d'importer l'unité chart-builder directement.
        Le sous-flux de graphique émis couvre le cadre BIFF8 requis par la spécification — BOF (dt=$0020), Chart / PlotGrowth / Frame / Series / SheetProperties / AxesUsed / AxisParent (POS + axe catégorie + axe valeur + PlotArea + Frame + ChartFormat + enregistrement de type + ChartFormatLink + Legend), EOF — pour qu'Excel reconnaisse le résultat comme un véritable onglet de graphique du type demandé. Le round-trip existant via TXLSCustomChart est inchangé.
        C'est la première étape de Roadmap #10 (sous-flux CHART — le plus gros élément de l'audit BIFF8). La phase 1 livre le cadre et la surface API pour que les phases suivantes ajoutent la liaison de données de séries, les titres d'axes et le formatage détaillé par type.
        Limitations : la nouvelle feuille-graphique affiche un graphique vide par défaut du type demandé. La liaison de données de séries, le texte de titre rempli et le formatage détaillé par type (gap width / overlap / hole size / marker style) sont reportés aux phases ultérieures. Excel préserve la présence et le type du graphique lors de la sauvegarde et réouverture, mais pas encore les données fournies par l'utilisateur.
      
    

      Version 2.40.0
      
        Nouvelle démo Delphi XlsCondFormat12 sous Demo/Delphi/XlsCondFormat12/ qui démontre l'API d'extension de mise en forme conditionnelle v2.34.0+ de bout en bout. Trois boutons permettent de générer CondFormat12.xls (backend BIFF8), CondFormat12.xlsx (backend XLSX) ou les deux côte à côte. Chaque feuille de sortie porte les mêmes quatre types de règles — Barre de données, échelle 3 couleurs, Jeu d'icônes (3 flèches) et échelle 2 couleurs — couvrant dix lignes de données pour ouvrir les fichiers dans Excel et vérifier visuellement.
        Le chemin BIFF8 exerce en plus la substitution de style DXF v2.35.0 : la règle Barre de données attache la couleur de police blanche en gras pour que le texte de la cellule reste lisible.
        Nouvelle fixture de test DUnitX à Tests/Delphi/HotXLS.CondFormat12Tests.pas couvre dix scénarios de round-trip et de surface d'API : round-trip BIFF8 pour les quatre types de règles, round-trip de style DXF pour les couleurs RGB, couleurs de thème et drapeaux de police, et round-trip XLSX pour Barre de données / échelle 3 couleurs / Jeu d'icônes avec ShowOnly. La fixture est câblée dans HotXLSDelphiTests.dpr et le .dproj correspondant.
        Pour prendre en charge la fixture de test, TCondFormat expose deux nouveaux accesseurs publics : RuleCount et Rule(I).
        Note de validation : ouvrez les .xls et .xlsx de la démo dans Excel pour voir les quatre règles d'extension CF12 / OOXML rendues côte à côte.
      
    

      Version 2.39.0
      
        La substitution de style XF différentiel (DXF) sur les règles de mise en forme conditionnelle prend désormais en charge l'encodage de couleur de thème en plus du mode RGB existant. Chaque emplacement de couleur — couleur de police, fond de remplissage, premier plan de remplissage — peut être défini contre un index de thème du classeur plus une valeur de teinte.
        Trois nouvelles méthodes sur TXLSDxfStyle activent un emplacement en mode thème : SetFontColorTheme(themeId, tint), SetFillBgColorTheme(themeId, tint), SetFillFgColorTheme(themeId, tint). Tint est un single dans la plage [-1.0, +1.0]. Les méthodes existantes SetXxxColor(rgb) restent en mode RGB ; les deux modes sont mutuellement exclusifs par emplacement.
        Interrogez le mode actif via les nouvelles propriétés en lecture seule XxxColorIsTheme / XxxColorThemeId / XxxColorThemeTint. HasXxxColor retourne True dans les deux modes.
        Le format de fil BIFF8 suit la disposition standard XFProp Colour : xclrType=2 + LongWord BGR 4 octets pour RGB, xclrType=3 + tint signé 2 octets × 32767 + index de thème 4 octets pour le mode thème. Le décodeur de blob DXF reflète ce dispatch.
        Limitations connues : le round-trip en mode thème n'est pris en charge que du côté BIFF8 (.xls) — le côté XLSX (.xlsx) émet et lit toujours uniquement <color rgb="..."/>.
      
    

      Version 2.38.0
      
        La lecture XLSX (.xlsx) reconnaît maintenant les règles de mise en forme conditionnelle d'extension Excel 2007+ dans les fichiers entrants — barre de données, échelle de couleurs (2 et 3 stops, détectés automatiquement du nombre de cfvo) et jeu d'icônes — et peuple l'objet TXLSXConditionalFormat correspondant pour que le code utilisateur puisse inspecter et faire round-trip de ces règles sans les perdre. Auparavant, les classeurs .xlsx sauvegardés par Excel avec ces types de règle étaient silencieusement abandonnés au chargement.
        Le lecteur analyse l'enveloppe OOXML <cfRule type="dataBar|colorScale|iconSet"> et le corps intérieur <dataBar> / <colorScale> / <iconSet>, parcourant les entrées enfant <cfvo> pour récupérer le type et la val de chaque seuil, et les entrées <color> pour récupérer la couleur de la barre ou les couleurs par stop de l'échelle.
        Les règles de jeu d'icônes font round-trip du nom de famille iconSet (les 17 jeux de référence Excel 2007), du drapeau reverse, et du drapeau showValue (mappé à ShowOnly).
        Les valeurs de couleur analysées de l'attribut OOXML rgb="AARRGGBB" sont converties dans la même convention BGR LongWord utilisée par l'API d'écriture, donc un round-trip load-edit-save préserve les couleurs visuelles exactement.
        Le traitement existant XLSX <cfRule type="cellIs"> est inchangé ; le dispatch choisit les nouveaux types de règle uniquement quand l'attribut type les nomme.
        Limitations connues : les références de couleur de thème sont lues comme 0 au lieu d'être résolues contre la palette de thème du classeur ; les substitutions iconId par stop ne sont pas capturées ; l'attribut priority de <cfRule> est ignoré à la lecture.
      
    

      Version 2.37.0
      
        Le format d'enregistrement BIFF8 CFEX porte maintenant le tableau cfvo complet par stop (kind + chaîne de valeur + couleur, selon la sémantique cfvo de [MS-XLS]) au lieu de juste la couleur de barre/stop. Les règles de barre de données persistent maintenant les types et valeurs de seuil min/max, les échelles de couleurs persistent la combinaison kind + value + color de chaque stop, et les jeux d'icônes persistent kind + value de chaque seuil avec les drapeaux reverse / showOnly.
        L'écriture CFEX ajoute un octet de drapeau de version (ver=1) pour que les anciens lecteurs HotXLS qui attendent la disposition minimale v2.34.0 CFEX retombent silencieusement sur l'interprétation héritée. Le lecteur v2.37.0 reconnaît aussi les enregistrements ver=0 produits par d'anciennes builds.
        Le lecteur détecte maintenant les entrées mixtes CONDFMT + CONDFMT12 sur la même plage — un motif commun dans les fichiers sauvegardés par Excel. L'entrée CONDFMT plus ancienne est marquée via une nouvelle propriété IsShadowed sur TCondFormat. Le writer continue d'émettre les deux familles d'enregistrements lors de la sauvegarde.
        Nouvelle propriété TotalRange sur TCondFormat expose la plage d'extension fusionnée précédemment privée.
        Limitations connues : la détection shadow est limitée à une correspondance exacte de la boîte englobante. Le round-trip cfvo complet de ColorScale préserve les 8 valeurs kind standard mais ne préserve pas les métadonnées de teinte de couleur theme d'Excel.
      
    

      Version 2.36.0
      
        La sortie XLSX (.xlsx) prend désormais en charge les trois types de règles d'extension de mise en forme conditionnelle Excel 2007+ — barre de données, échelle de couleurs (2-stop et 3-stop), et jeu d'icônes — amenant le backend XLSX à parité avec le backend BIFF8 (.xls) de v2.34.0. Quatre nouvelles méthodes publiques sur TXLSXWorksheet reflètent l'API XLS : AddCondFormatDataBar, AddCondFormatColorScale2, AddCondFormatColorScale3, AddCondFormatIconSet.
        Le fichier .xlsx sauvegardé émet maintenant l'élément OOXML <conditionalFormatting> avec la structure enfant appropriée pour chaque type de règle : <cfRule type="dataBar"><dataBar> pour les barres, <cfRule type="colorScale"><colorScale> avec 2 ou 3 cfvo + color stops, et <cfRule type="iconSet"><iconSet iconSet="..."> avec l'ensemble cfvo approprié.
        Le mappage des noms de jeux d'icônes intégrés couvre les mêmes dix-sept jeux de référence Excel 2007 pris en charge par le backend XLS, produits comme chaîne d'attribut OOXML iconSet standard.
        Les types de seuil et les valeurs de couleur utilisent la même énumération et convention de couleur que l'API XLS — même TXLSCfValueKind, même format LongWord BGR Delphi. Les appels existants AddConditionalFormat XLSX continuent à se comporter de manière identique.
        Limitations connues : l'encodage de couleur de thème n'est pas encore émis ; les substitutions iconId par stop dans les jeux d'icônes ne sont pas prises en charge. La reconnaissance côté lecture XLSX des règles barres de données / échelles de couleurs / jeux d'icônes provenant de fichiers sauvegardés par Excel reste différée — seule l'écriture est connectée dans cette version.
      
    

      Version 2.35.1
      
        Le reader BIFF8 décode désormais les octets Differential XF (DXF) attachés à une règle CF12 dans le property bag TXLSDxfStyle de la règle, en plus de conserver les octets bruts dans DxfBlob. Le chargement d'un classeur sauvegardé par Excel avec des règles de barres de données / échelles de couleurs / jeux d'icônes stylisées expose maintenant la couleur de police, les couleurs de remplissage, gras / italique / soulignement et l'id de format de nombre directement via la paire HasXxx+valeur sur chaque Rule.Style.
        Comportement round-trip : un cycle load-edit-save reflète maintenant toute mutation post-chargement de Rule.Style. Si un utilisateur lit un classeur, change Rule.Style.SetFontColor et sauvegarde, la nouvelle couleur l'emporte ; si l'utilisateur ne touche pas le Style, le fichier sauvegardé porte les mêmes substitutions que l'original.
        Les valeurs xfPropType inconnues dans le blob DXF sont ignorées plutôt que rejetées, donc les fichiers Excel plus récents utilisant des types de propriété pas encore reconnus par cette version continuent à se charger (les octets bruts restent dans DxfBlob pour inspection ou support futur de round-trip).
      
    

      Version 2.35.0
      
        Les règles de mise en forme conditionnelle peuvent désormais porter une substitution de style XF différentiel (DXF), de sorte qu'une règle CF12 qui se déclenche dans Excel peut changer la couleur de police, le remplissage, la graisse, l'italique, le soulignement ou le format de nombre de la cellule sans altérer le XF de base de la cellule. La substitution est exposée comme une nouvelle propriété TXLSDxfStyle sur chaque TCondFormatRule, accessible après avoir créé une règle via les APIs existantes AddCondFormatDataBar / AddCondFormatColorScale* / AddCondFormatIconSet.
        Substitutions de style prises en charge dans cette version : couleur de police, couleur de fond de remplissage, couleur de premier plan de remplissage, motif de remplissage, police en gras, police en italique, style de soulignement de police et id de format de nombre intégré. Chaque propriété a un drapeau HasXxx apparié — seules les propriétés explicitement définies via SetXxx sont émises dans le fichier BIFF8.
        Le writer BIFF8 ajoute maintenant un bloc DXF non vide à l'enregistrement CF12 lorsque le Style de la règle a au moins une substitution définie. Le bloc DXF utilise la mise en page publique du tableau XFProp (cxfp + tuples par propriété de type / taille / données), permettant à Excel de capter les changements de style lorsque la règle s'applique.
        Le reader BIFF8 préserve les octets DXF bruts d'un fichier sauvegardé par Excel dans la propriété DxfBlob de la règle, donc un round-trip load-edit-save ne perd plus silencieusement le style de cellule porté par les règles CF12. Le décodage des octets bruts en propriétés TXLSDxfStyle est planifié pour une version de suivi.
        Le comportement par défaut est inchangé pour les règles qui ne s'inscrivent pas pour un style — cbdxf = 0 est émis, identique à v2.34.0, donc les règles existantes de barres de données / échelles de couleurs / jeux d'icônes sont rendues exactement comme avant.
        Limitations connues : l'encodage de couleur de thème pour DXF n'est pas pris en charge (RGB uniquement) ; les substitutions de bordure et les arrêts de dégradé ne sont pas dans le jeu de propriétés de cette version ; l'ordre des octets pour les blobs de valeur XFProp suit les notes publiques [MS-XLS] et peut nécessiter de petits ajustements pour la fidélité round-trip Excel complète une fois validé avec BiffView. La parité côté XLSX pour les trois nouveaux types de règle reste différée.
      
    

      Version 2.34.0
      
        Nouvelle API publique de mise en forme conditionnelle sur la feuille pour les règles d'extension d'Excel 2007+ : AddCondFormatDataBar, AddCondFormatColorScale2, AddCondFormatColorScale3 et AddCondFormatIconSet. Chaque méthode accepte une plage sqref comme "A1:A10" ainsi que les paramètres spécifiques au type (couleur de la barre, couleurs des arrêts de dégradé ou famille de jeu d'icônes) et renvoie l'objet de règle créé.
        Le writer BIFF8 (.xls) émet désormais les enregistrements CONDFMT12 / CF12 / CFEX aux côtés des enregistrements CONDFMT / CF existants, ce qui permet aux classeurs créés via la nouvelle API de persister leurs règles de barres de données, échelles 2 ou 3 couleurs et jeux d'icônes sur disque.
        Le reader BIFF8 reconnaît les enregistrements CONDFMT12 / CF12 / CFEX entrants et les expose via le même modèle de règles en mémoire ; les fichiers .xls créés par Excel avec des règles d'extension ne sont plus silencieusement supprimés au chargement.
        Catalogue intégré de jeux d'icônes couvrant les dix-sept jeux de référence Excel 2007 (familles 3-flèches / 3-drapeaux / 3-feux / 3-panneaux / 3-symboles, 4-flèches / 4-évaluations / 4-feux, et 5-flèches / 5-évaluations / 5-quarts), sélectionnables via l'énumération TXLSIconSetType.
        Les types de seuil pour les bornes de barres et les arrêts d'échelles / jeux d'icônes peuvent être nombre, min / max de plage, pourcentage, centile ou formule, conformes aux types cfvo d'Excel.
        Le comportement des règles de valeur de cellule existantes est inchangé ; seules de nouvelles APIs et la nouvelle gestion d'enregistrements BIFF8 ont été ajoutées.
        Limitations connues dans cette version : la sortie XLSX pour les trois nouveaux types de règle n'est pas encore branchée (règles XLSX de valeur de cellule existantes non affectées) ; le bloc de style XF différentiel sur CF12 est émis vide, donc Excel peut afficher barres et échelles avec des couleurs par défaut plutôt que celles fournies par l'API ; les tableaux cfvo par arrêt dans CFEX ne portent que la couleur, pas la combinaison type / valeur. Ces lacunes sont prévues pour les versions de suivi v2.34.x / v2.35.x avec le classeur de démonstration et la validation du rendu Excel.
      
    

      Version 2.33.3
      
        Nouveau démo Delphi XlsTables sous Demo/Delphi/XlsTables/ démontrant de bout en bout le côté écriture des Tables BIFF8 (ListObjects). Il génère SalesTable.xls avec une région de ventes à quatre colonnes (Région / Produit / Trimestre / Revenu) liée comme une Table à A1:D10 en utilisant Sheet.AddTable('SalesTable', 'A1:D10', headers). Ouvrez le .xls produit dans Excel pour vérifier les listes déroulantes de colonne, les bandes de lignes alternées et le nom de référence structurée SalesTable dans la Boîte de Nom.
        Le démo est la recette de bout en bout la plus courte pour adopter l''API AddTable de v2.33.0 : définit StyleName = 'TableStyleMedium2' et ShowRowStripes = True, remplit neuf lignes de données + une ligne d''en-tête, et écrit le classeur avec un seul appel SaveAs. La sortie va à côté de l''exécutable.
        L''infrastructure de compilation est inchangée : le build-Win32-Demo.cmd existant ramasse XlsTables.dpr automatiquement via son balayage for /r Demo *.dpr — aucun changement aux scripts de build ou aux configurations .cbproj/.dproj n''est requis.
      
    

      Version 2.33.2
      
        Le SaveAs BIFF8 (.xls) supprime maintenant les enregistrements autonomes au niveau de la feuille AUTOFILTERINFO/AUTOFILTER ($009D / $009E) lorsqu''une Table sur la même feuille couvre entièrement la plage de filtre automatique. Excel intègre une liste déroulante de filtre automatique dans l''objet Table lui-même, donc émettre un filtre automatique supplémentaire au niveau de la feuille pour la plage identique déclenche la Validation des Fichiers Office à rejeter le fichier. Cela correspond à la correction côté XLSX livrée dans v2.29.4.
        La vérification de couverture est conservatrice : une Table est considérée comme "couvrant" le filtre automatique uniquement lorsque sa première/dernière ligne et sa première/dernière colonne encadrent les limites du filtre automatique. Le chevauchement partiel maintient le comportement d''émission du filtre automatique au niveau de la feuille.
        Les enregistrements BIFF5 et les feuilles de calcul sans Table ne sont pas affectés — la vérification de suppression ne s''exécute que lorsque le format du fichier est BIFF8 et que la feuille de calcul contient au moins une Table. Aucun changement d''API publique.
      
    

      Version 2.33.1
      
        Le côté lecture BIFF8 (.xls) reconnaît maintenant les enregistrements Tables de fonctionnalités partagées que v2.33.0 a ajoutés du côté écriture. L''ouverture d''un .xls enregistré par Excel (ou par HotXLS lui-même) avec un ou plusieurs ListObjects/Tables remplit maintenant la collection Tables de la feuille de calcul avec un TXLSTable par FEAT11 ($0872) analysé, reconstruisant la plage de la table à partir du Ref8U primaire, récupérant l''id, le nom et le nom d''affichage de la table lorsqu''ils sont présents, et remplissant le nom du style de table à partir de l''enregistrement LIST12 ($0877) apparié. Auparavant, ces enregistrements étaient silencieusement ignorés.
        L''opcode FEATHEADR ($0867) partagé est maintenant distribué selon son champ Isf au lieu d''aller toujours à l''analyseur de protection. Isf=2 (Protection Améliorée) conserve le comportement existant ; Isf=4 (SharedList) est reconnu comme marqueur pour les Tables sur la feuille ; Isf=3 (SmartTags) et autres valeurs sont ignorés en toute sécurité. FEATHEADR11 ($0871) est également reconnu silencieusement comme marqueur Tables.
        Le lecteur est au mieux de ses capacités et tolérant : les charges utiles FEAT11 mal formées ou de variantes Excel se dégradent élégamment vers une Table qui a au moins la plage de cellules correcte. La protection de feuille en round-trip est inchangée.
      
    

      Version 2.33.0
      
        Les feuilles de calcul BIFF8 (.xls) prennent désormais en charge les objets Table (ListObjects Excel). Appelez Worksheet.AddTable(Name, Range, Columns) sur une IXLSWorksheet pour attacher une région de table nommée à une plage de cellules — par exemple Sheet.AddTable('SalesTable', 'A1:F9', HeaderList). Le chemin d''enregistrement .xls émet désormais la famille d''enregistrements de fonctionnalités partagées BIFF8 qui marque la feuille comme contenant des tables : FEATHEADR ($0867 avec Isf=4), FEATHEADR11 ($0871), et une paire FEAT11 ($0872) + LIST12 ($0877) par table. Auparavant, l''appel AddTable sur la façade XLS n''était pas disponible ; les tables définies sur une feuille de calcul étaient silencieusement abandonnées lors de SaveAs(xlExcel97).
        Nouvelle API publique sur IXLSWorksheet : propriété Tables: TXLSTables (collection en lecture seule) et méthode AddTable. La forme reflète TXLSXTable / TXLSXTables côté XLSX. TXLSTable expose Id, Name, DisplayName, Range, Columns, StyleName (par défaut 'TableStyleMedium2'), ShowFirstColumn, ShowLastColumn, ShowRowStripes (par défaut true), ShowColumnStripes et TotalsRowShown.
        Les nouveaux enregistrements de flux de feuille sont émis juste avant l''EOF de la feuille de calcul, après la protection de feuille, uniquement lorsque le format de fichier est BIFF8 (xlExcel97). Les classeurs sans tables sont enregistrés exactement comme auparavant — aucun FEATHEADR n''est émis, aucun changement dans le flux d''enregistrements, aucun surcoût. Les enregistrements BIFF5 ne sont pas affectés.
        Les ID de table sont attribués séquentiellement par feuille (1..N) au moment de l''enregistrement s''ils ne sont pas prédéfinis. Le nom de style par défaut 'TableStyleMedium2' correspond à celui qu''Excel et le côté XLSX utilisent déjà.
        Limitations connues de cette version initiale (v2.33.0) : les formules de ligne de totaux et les plages auxiliaires de références structurées ne sont pas encore émises ; la suppression des conflits entre AUTOFILTERINFO au niveau de la feuille et une plage de Table sera ajoutée dans un suivi ; le côté lecture (analyse d''un .xls enregistré par Excel avec des tables vers la collection Tables) est également un suivi.
      
    

      Version 2.32.1
      
        Correction d'une erreur de compilation introduite par la fonctionnalité d'écriture FILEPASS de v2.32.0 qui empêchait la bibliothèque de se construire sur RAD Studio 12+ avec une vérification stricte des types. L'assistant EncryptAllBlobs déclarait son tampon de dispersion comme PByte dans un contexte où PByte se résolvait en alias local de lxHandle, tandis que la cible d'appel EncryptBlobData dans lxEncrypter attendait lxBLOB.PByte. Bien que les deux types aliasient tous deux ^Byte, Delphi les traite comme distincts sous la vérification stricte E2010. La variable de tampon est maintenant entièrement qualifiée comme lxBLOB.PByte, de sorte que le chemin de chiffrement par mot de passe v2.32.0 compile proprement sur toutes les versions RAD Studio prises en charge (12.0–37.0).
      
    

      Version 2.32.0
      
        Nouvelle propriété EncryptionPassword sur IXLSWorkbook. Définir un mot de passe non vide avant SaveAs produit désormais un fichier .xls protégé par mot de passe compatible Excel : Excel, LibreOffice Calc et autres lecteurs BIFF8 demandent le mot de passe à l'ouverture et refusent l'accès si le mot de passe est incorrect. Auparavant, le setter de mot de passe était silencieusement ignoré côté écriture.
        Le chemin d'écriture émet l'enregistrement BIFF8 FILEPASS ($002F) immédiatement après le BOF du classeur et chiffre RC4 chaque corps d'enregistrement suivant avec le même algorithme que côté lecture (vMajor=1, vMinor=1 -- chiffrement "Office 97/2000 Compatible" d'Excel). Le Salt et le Verifier de 16 octets sont générés via CryptGenRandom de Windows plutôt que Random de Pascal. La re-dérivation de la clé de bloc à chaque limite de 1024 octets est préservée.
        Le chiffrement s'applique uniquement à BIFF8 (xlExcel97) ; le chemin BIFF5 reste en clair. Un EncryptionPassword vide conserve le comportement en clair existant (valeur par défaut), les applications existantes ne sont pas affectées.
        Côté lecture : correction d'un bug latent dans ParseFilePass qui faisait traiter le premier corps d'enregistrement après FILEPASS (typiquement CODEPAGE) comme texte clair. Les fichiers chiffrés écrits par HotXLS effectuent maintenant un aller-retour correct à travers HotXLS.
        Note de sécurité : BIFF8 RC4 (vMajor=1/vMinor=1) utilise une clé de 40 bits, considérée comme cassée par les normes de 2025. Utilisez cette fonctionnalité pour la compatibilité avec l'interface de protection par mot de passe classique d'Excel, pas pour la confidentialité de données sensibles. Pour une vraie sécurité, préférez XLSX avec AES.
      
    

      Version 2.31.0
      
        Ajout de la propriété UseSharedFormulas sur IXLSWorkbook. Lorsqu'elle est activée (True), SaveAs en format BIFF8 regroupe les cellules partageant une formule modèle dans des enregistrements SHRFMLA natifs ($04BC), conformément au format compact de Microsoft Excel. Des colonnes de formules telles que =A1*B1, =A2*B2, …, =A99*B99 sont regroupées automatiquement, réduisant la taille du fichier de 30 à 60 % sur les feuilles à forte densité de formules modèles.
        Le regroupement s'effectue vers le bas par colonne, de manière contiguë et basée sur le modèle : seules les cellules de la même colonne avec des lignes consécutives et des formules PTG équivalentes sont regroupées. Les cellules avec des formules matricielles ou des indicateurs de fusion sont exclues.
        La valeur par défaut est False, conservant l'émission inchangée des enregistrements FORMULA par cellule. Activez la fonctionnalité en définissant Workbook.UseSharedFormulas := True avant d'appeler SaveAs.
        La lecture n'est pas affectée. Il s'agit d'une version MINOR (2.30.x → 2.31.0) car une nouvelle propriété publique est ajoutée et le format de sortie BIFF8 change lorsque la fonctionnalité est activée.
      
    

      Version 2.30.6
      
        Correction d'une quatrième classe d'erreurs de compilation dans les démos C++Builder sous le compilateur bcc32 basé sur clang de RAD Studio 37.0 : le schéma d'indexation ->Borders[idx]->Prop sur un pointeur intelligent d'interface déclenchait l'erreur E5843 ("le type de référence membre n'est pas un pointeur"). Toutes les occurrences ont été remplacées par ->Borders->Item[idx]->Prop. Ce correctif touche les démos ApiTour, ExportWithColoring, PurchaseOrder et QuickStart et complète la compatibilité totale avec clang pour les neuf projets de démo C++Builder.
      
    

      Version 2.30.5
      
        Les neuf projets de démonstration C++Builder se compilent désormais correctement sous le compilateur bcc32 basé sur clang de RAD Studio 37.0. Trois classes d'erreurs de compilation ont été corrigées : la propriété EOF de lxFormula a été renommée IsEof pour éliminer un conflit avec la macro C stdio.h du même nom ; les constantes d'énumération de l'API XLS (xlHAlignCenter, xlAround, xlMedium, etc.) sont maintenant explicitement qualifiées avec l'espace de noms Lxhandle:: ; et les affectations de valeurs de cellules XLSX ont été modifiées de OleVariant(...) en Variant(...) car TXLSXCell.Value est de type System::Variant et le compilateur clang refuse la conversion implicite depuis la classe de base protégée OleVariant.
      
    

      Version 2.30.4
      
        La démo OrderCalc (exemple de bon de commande pour Delphi) prend désormais en charge l'export XLSX en plus des formats XLS, HTML et RTF existants. En sélectionnant « Excel 2007+ (*.xlsx) » dans la boîte de dialogue d'enregistrement, la commande est écrite via l'API native TXLSXWorkbook et produit directement un fichier XLSX conforme au standard, avec polices, remplissages, bordures, alignement, formats de nombre et formules Excel.
      
    

      Version 2.30.3
      
        SaveXLSWorkbookAsXLSX (le pont utilisé par TDataToXLS.SaveAs et TGridToXLS.SaveAs lorsque le nom de fichier cible se termine par .xlsx) copie désormais les couleurs de remplissage d'arrière-plan des cellules, les couleurs de police et les attributs de style de police (nom, taille, gras, italique) du classeur XLS sous-jacent vers la sortie XLSX. Les largeurs de colonnes -- y compris les colonnes décoratives intentionnellement étroites -- sont également copiées. Auparavant, seules les valeurs et les formats numériques étaient transférés, ce qui donnait une sortie XLSX sans mise en forme, avec toutes les largeurs de colonnes à la valeur par défaut, et une colonne décorative délibérément étroite apparaissant comme une large colonne vide.
      
    

      Version 2.30.2
      
        Correction d'un bug round-trip du lecteur XLS : la direction Outline.SummaryRow était inversée après Open. Le flag fRwSumsBelow du record WSBOOL (BIFF8 spec p278, octet 0 bit 6, masque $0040) signifie « les lignes de résumé apparaissent *en dessous* du détail », mais l'analyseur définissait SummaryRow = xlAbove quand le bit était positionné (et xlBelow quand il était à zéro) -- exactement l'inverse de la spécification. Le côté écriture était déjà correct (émet $0040 pour xlBelow), donc ouvrir un fichier Excel avec « lignes de résumé en dessous » puis le ré-enregistrer via HotXLS inversait silencieusement la direction de l'outline en « au-dessus ». La direction d'analyse correspond désormais à la spécification et à l'écrivain, et les configurations d'outline circulent correctement. fColSumsRight ($0080) était déjà géré correctement et n'a pas changé.
      
    

      Version 2.30.1
      
        L'écrivain XLS (BIFF8) émet désormais les enregistrements INTERFACEHDR / INTERFACEEND / WRITEACCESS dans la section des globals du classeur, en accord avec la disposition d'enregistrements native de Microsoft Excel. Excel lui-même écrit toujours ce trio entre CODEPAGE/DSF et WINDOW1, et certains lecteurs BIFF stricts ou chemins Office File Validation peuvent les attendre. INTERFACEHDR contient la page de code (1200, UTF-16), INTERFACEEND est un marqueur vide, et WRITEACCESS contient le nom d'utilisateur « enregistré par » (actuellement codé en dur à « HotXLS » ; une future version pourra le promouvoir en propriété Workbook). Les fichiers XLS générés correspondent désormais plus étroitement à la disposition d'octets native d'Excel.
      
    

      Version 2.30.0
      
        Ajout d'un pont d'export classique vers XLSX. TDataToXLS.SaveAs et TGridToXLS.SaveAs écrivent désormais les noms de fichiers .xlsx via le moteur XLSX tout en gardant inchangés les chemins existants .xls, .html et .rtf.
        Ajout d'APIs de vue de feuille de calcul pour XLS et XLSX. IXLSWorksheet.View et TXLSXWorksheet.View prennent en charge la vue normale, l'aperçu des sauts de page et la vue mise en page, et le paramètre est conservé par le chemin d'écriture/lecture de fichier correspondant.
        Ajout d'APIs de compatibilité classique pour les classeurs : IXLSWorkbook.SetCodePage et IXLSWorkbook.VBAProject. Les projets VBA peuvent maintenant être inspectés via les noms de modules et le texte source TXLSVBAProject/TXLSVBAModule lorsqu'un classeur contient un stockage VBA.
        TXLSXWorkbook étendu avec ParsedVBAProject, une vue analysée en lecture seule sur une charge utile vbaProject.bin valide, tout en préservant le comportement existant de round-trip des octets bruts VbaProject.
        Ajout de l'unité optionnelle cxGridAddExcel pour les flux d'export cxGrid DevExpress. Elle n'est intentionnellement pas incluse dans les packages par défaut afin que les installations sans DevExpress continuent à compiler proprement.
        Correction du rendu des feuilles de graphique XLSX : les feuilles de graphique ajoutées via AddChartSheet apparaissaient vides dans Excel (les 3 icônes d'outils de graphique apparaissaient brièvement en haut à droite puis disparaissaient ; la feuille entière devenait vide). Cause : le dessin de la feuille de graphique utilisait <xdr:twoCellAnchor> + xfrm cx=0/cy=0, mais les feuilles de graphique n'ont pas de grille de cellules contre laquelle résoudre twoCellAnchor ; Excel se rabattait sur le xfrm 0×0 et rendait le graphique en taille zéro. Les dessins de feuilles de graphique utilisent désormais <xdr:absoluteAnchor> avec la taille par défaut 9525000×6858000 EMU (≈10×7,2 pouces), conformément à ECMA-376-1 14.2.3.2. Les ancres de graphique sur les feuilles de calcul sont inchangées.
      
    

      Version 2.29.4
      
        Correction d'un bug d'empaquetage XLSX qui provoquait l'invite de réparation d'Excel « Nous avons détecté un problème avec une partie du contenu de <fichier>.xlsx » lorsqu'un autoFilter au niveau de la feuille et une Table couvraient la même plage (par exemple la feuille Details de XlsxFeatureGallery.xlsx du démo MemoryDataExport, qui appelait AddTable('SalesTable', 'A1:F9', ...) suivi de SetAutoFilter('A1:F9')). OOXML interdit deux mécanismes de filtre sur la même plage ; le writer supprime désormais l'émission <autoFilter> au niveau de la feuille lorsque sa plage coïncide avec celle d'une table. L'autoFilter propre à la table (rendu sous forme de listes déroulantes d'en-tête) continue de fonctionner.
        Correction d'une violation de schéma connexe dans <dataValidation> : l'attribut operator était émis pour chaque validation, mais ECMA-376-1 18.3.1.32 ne l'autorise que pour whole / decimal / date / time / textLength. AddListValidation produit type="list", et la valeur par défaut operator="between" passait à travers ; OFV est plus strict qu'Excel et peut rejeter le classeur. L'attribut operator est désormais omis pour list / custom / none.
        Correction de l'élément <legacyDrawing r:id="..."/> sur les feuilles combinant des hyperliens internes et externes avec des commentaires (feuille Dashboard de XlsxFeatureGallery.xlsx : 1 interne + 1 externe + 1 commentaire). Le calcul du rId comptait tous les hyperliens au lieu des seuls externes (les internes utilisent l'attribut inline location= et ne consomment pas de rId), ce qui faisait pointer legacyDrawing vers la cible de relation des commentaires au lieu de celle du vmlDrawing. ECMA-376-1 18.3.1.51 exige une relation de type vmlDrawing. Le rId est désormais calculé uniquement à partir du nombre d'hyperliens externes.
        Nettoyage complémentaire : les feuilles de graphique ajoutées via AddChartSheet n'émettent plus de fichier xl/worksheets/_rels/sheetN.xml.rels redondant. Ce fichier orphelin pointait vers un part de feuille de calcul inexistant ; les feuilles de graphique n'écrivent désormais que la relation correcte sous xl/chartsheets/_rels/sheetN.xml.rels.
        Mise à jour du démo MemoryDataExport (XlsxFeatureGallery) : suppression de l'appel redondant SetAutoFilter('A1:F9') sur la feuille Details -- AddTable attache déjà un autoFilter à la plage de la table, donc l'appel supplémentaire déclenchait le rejet OFV ci-dessus. La suppression défensive dans le writer couvre le code client qui ne reçoit pas la mise à jour du démo.
      
    

      Version 2.29.3
      
        Correction d'une régression XLSX round-trip où les bordures dessinées sur des lignes autrement vides étaient perdues après Open + modification + SaveAs. Le séparateur horizontal de la ligne 8 d'ApiTour (produit par un appel Range.SetBorders sur une ligne sans données) s'affichait correctement dans le fichier ApiTour.xlsx fraîchement généré, mais disparaissait dans ApiTour-XLSX-Modified.xlsx après que l'étape Modify du démo réenregistrait le fichier, laissant Excel afficher une ligne de grille verticale brisée en C8 / D8 uniquement dans le fichier modifié (le fichier ApiTour.xlsx d'origine n'était pas affecté). L'analyseur XLSX applique désormais aussi les styles de cellule lorsqu'un élément `<c>` est auto-fermant ou ne possède aucun enfant valeur/formule, ce qui permet aux cellules stylées sans valeur de survivre au round-trip.
      
    

      Version 2.29.2
      
        Correction d'une régression XLSX round-trip dans le flux Open + modification + SaveAs. ParseWorksheetXml stockait l'index cellXf  directement dans cell.FormatIndex ; lors du SaveAs, les cellXfs sont reconstruits à partir des pools de style du classeur (avec éventuellement des entrées composites), et le même index numérique n'a presque jamais la même sémantique dans la nouvelle disposition ; la cellule réenregistrée pointait vers un cellXf incorrect, voire au-delà de la nouvelle table cellXfs, et Excel signalait « Office a détecté un problème avec ce fichier ». ApplyStyle mappe désormais cellStyle inversement vers FontIndex / FillIndex / BorderIndex / NumberFormatIndex / AlignmentIndex / ProtectionIndex via les tables CellXfXxxMap déjà remplies par ParseStylesXml, ce qui permet de réémettre la cellule contre les cellXfs reconstruits.
      
    

      Version 2.29.1
      
        Correction de deux régressions de rendu XLSX : (1) Range.SetBorders pouvait émettre les cellules d'une ligne dans un ordre de colonne non monotone (le passage outline crée A8/C8, le passage inside crée B8 -- sortie A8/C8/B8 au lieu de A8/B8/C8) ; Excel signalait alors « Office a détecté un problème avec ce fichier » et forçait l'affichage protégé. L'écriture XLSX trie maintenant chaque ligne par colonne avant l'émission (schéma OOXML CT_Row). (2) Les cellules avec 2+ index de style (Font + Fill + Border, etc.) étaient auparavant écrasées via une chaîne de priorité sur une seule dimension (FontIndex gagnait, Border/Fill étaient perdus). L'écriture collecte désormais un pool composite-cellXf pendant SaveAs et achemine les cellules multi-dim vers un cellXf synthétisé qui préserve toutes les dimensions.
      
    

      Version 2.29.0
      
        L'unité d'aide interne `lxList2` a été renommée en `lxKeyList` et les classes à clé WideString `TXLSKeyList` / `TXLSKeyEntry` / `TXLSKeyArray` de `lxList` ont été renommées en `TXLSStringKeyList` / `TXLSStringKeyEntry` / `TXLSStringKeyArray` afin que le nom de l'unité corresponde à sa classe principale `TXLSObjectKeyList` et que les deux générations de key-list soient explicites (`TXLSStringKey*` pour l'ancien pool à clé WideString, `TXLSObjectKey*` pour le nouveau pool de déduplication basé sur THashtableKey). Si votre code référence l'ancien nom d'unité ou les anciens noms de classes, mettez à jour les clauses uses et les noms de types en conséquence.
      
    

      Version 2.28.3
      
        Correction d'une régression de l'écriture de cellule XLSX : les bordures définies sur des lignes par ailleurs vides disparaissaient. `Range[''A3:C10''].SetBorders(xlsxEdgeOutline,...)` sur une feuille dont la ligne 8 ne contenait aucune donnée affichait une ligne verticale brisée entre les colonnes C et D, car l'écriture sautait toute cellule dont la valeur n'était pas assignée -- même si la cellule possédait un BorderIndex / FontIndex / FillIndex / NumberFormatIndex / AlignmentIndex / ProtectionIndex. L'écriture émet désormais `` pour les cellules sans valeur qui portent un index de style.
      
    

      Version 2.28.2
      
        Correction d'une violation de schéma de feuille XLSX qui empêchait Excel de charger les feuilles combinant cellules fusionnées et AutoFilter. Le générateur XLSX émet désormais l'élément <autoFilter> avant <mergeCells>, conformément à la séquence OOXML CT_Worksheet (autoFilter est #11, mergeCells est #15). Auparavant, ces classeurs déclenchaient la boîte de dialogue de réparation d'Excel avec Load error. Line 1, column 0 sur sheet1.xml et la récupération supprimait également tableParts / autoFilter des feuilles Details voisines.
      
    

      Version 2.28.1
      
        Ajout d'API simplifiées à la façade XLS classique. IXLSRange expose désormais les propriétés en lecture seule Width et WidthInPixels, ainsi que SaveAsCSV(FileName). IXLSWorksheet et IXLSWorkbook exposent désormais les méthodes SaveAsCSV(FileName / Stream) pour la plage utilisée ou la feuille active. IXLSPageSetup expose Order, Draft, BlackAndWhite, PrintNotes, et la propriété en lecture seule IsFitToPages. L'enregistrement SETUP lors de la sauvegarde/ouverture conserve désormais ces paramètres d'impression.
      
    

      Version 2.28.0
      
        Ajout de l'export RTF sur TXLSXWorkbook. Les nouvelles méthodes SaveAsRTF (FileName / Stream x feuille active par défaut / index de feuille explicite) écrivent la feuille sélectionnée en tant que document RTF 1.6 contenant un tableau simple. La largeur des colonnes est dérivée des données ColWidth de la feuille (1 unité de caractère Excel est approximée à 96 twips RTF). Les colonnes sans largeur explicite utilisent la largeur StandardWidth si elle est définie, sinon 809 twips (environ 8,43 caractères). Le gras (\\b), l'italique (\\i) et la taille de police (\\fsN en demi-points) par cellule sont appliqués à partir de l'index de police de la cellule. Les caractères non-ASCII sont encodés en tant qu'échappements RTF \\uN? Unicode en 16 bits signés, conformément à la section 2.4.2 de la norme RTF 1.6, couvrant toute la plage BMP. Les cellules fusionnées ne sont pas étendues ; la cellule d'origine contient le contenu, et les autres cellules dans la plage sont émises comme des cellules vides. SheetIndex par défaut écrit la feuille active ; une valeur hors de portée renvoie -1. Les feuilles vides produisent un document RTF minimal valide.
      
    

      Version 2.27.0
      
        Ajout de l'export HTML sur TXLSXWorkbook. Les nouvelles méthodes SaveAsHTML (FileName / Stream x feuille active par défaut / index de feuille explicite) écrivent la feuille sélectionnée en tant que document HTML UTF-8 avec une BOM UTF-8. La sortie est un seul tableau <table> à l'intérieur d'une page HTML minimale. Les cellules fusionnées sont exprimées par les attributs colspan / rowspan. Le style des cellules est émis en tant que CSS en ligne : famille de police, taille (pt), gras (font-weight:bold), italique (font-style:italic), barré (text-decoration:line-through) et couleur de police explicite ; la couleur de remplissage solide est utilisée comme couleur de fond (background-color) ; l'alignement horizontal (gauche / centre / droite / justifié) et WrapText (white-space:pre-wrap). Les valeurs de variante de date sont affichées au format 'aaaa-mm-jj hh:nn:ss' ; les cellules avec du texte enrichi sont aplaties en concaténant le texte de chaque exécution. Les couleurs de thème sont ignorées silencieusement (aucune résolution de theme1.xml dans l'export HTML simple). SheetIndex par défaut écrit la feuille active ; une valeur hors de portée renvoie -1.
      
    

      Version 2.26.0
      
        Ajout du support des couleurs de thème, des couleurs indexées et des nuances/ombres sur TXLSXFont, TXLSXFill et TXLSXBorderEdge. Chaque emplacement de couleur comporte désormais trois nouveaux champs, en plus des champs RGB existants : ColorTheme (entier ; -1 = non défini ; 0 à 11 = emplacement de thème OOXML), ColorIndex (entier ; -1 = non défini ; 0 à 63 = emplacement de palette hérité OOXML — associé à Workbook.IndexedColor[N] et XlsxDefaultIndexedPalette) et TintAndShade (double entre -1,0 et 1,0 ; émis uniquement avec le thème). TXLSXFill expose les variantes avant-plan/arrière-plan pour les trois. Priorité de l'écrivain : thème > indexé > RGB ; l'ancienne méthode "ColorIsAuto = True" continue de supprimer complètement l'élément. SaveAs et Open assurent la compatibilité des ensembles d'attributs complets <color theme="N" tint="..."/> et <color indexed="N"/> sur les couleurs de police/remplissage/bordure. Gestion interne : TXLSXBorders.LookupOrAdd compare désormais les trois nouveaux champs afin d'éviter que les bordures de couleur thème ne soient en conflit avec les entrées de couleur RGB dans le pool.
      
    

      Version 2.25.0
      
        Ajout de la compatibilité des liens vers des classeurs externes sur TXLSXWorkbook. Nouveaux types : TXLSXExternalLink (URL cible + liste des noms de feuilles) + collection TXLSXExternalLinks. La propriété TXLSXWorkbook.ExternalLinks expose la collection ; Add(Target) ajoute un nouveau lien et le renvoie à l'appelant, qui le remplit. SaveAs génère un bloc <externalReferences> au niveau du classeur dans xl/workbook.xml, une relation externalLink dans xl/_rels/workbook.xml.rels (à la fin de la plage rid pour maintenir la stabilité des rid existants), le fichier xl/externalLinks/externalLink{N}.xml pour chaque entrée (<externalBook><sheetNames>) et son fichier .rels associé, qui pointe vers l'URL du classeur distant avec TargetMode="External", ainsi que les remplacements de ContentType correspondants. Open analyse les paires externalLink{N}.xml + .rels en commençant à l'index 1 et s'arrête au premier espace. La version actuelle assure la compatibilité de l'URL cible et des noms de feuilles ; les valeurs de cellule mises en cache dans <sheetDataSet> ne sont pas conservées.
      
    

      Version 2.24.0
      
        Ajout d'une fonction d'aide pour la composition des bordures : TXLSXRange.SetBorders. Nouvelle énumération TXLSXBorderEdgeKind (xlsxEdgeAll / Outline / Inside / InsideHorizontal / InsideVertical / Top / Bottom / Left / Right / DiagonalUp / DiagonalDown) qui sélectionne les bords à écrire. SetBorders(Kind, Style, Color) / SetBorders(Kind, Style) (par défaut, noir opaque) itère sur chaque cellule de la plage, calcule le masque de bordure en fonction de la position de chaque cellule (les cellules d'angle ont deux bords externes, les cellules des bords ont un, les cellules intérieures ont des lignes de grille intérieures, etc.), combine Style + Color sur une copie de la bordure actuelle de la cellule (les appels successifs Outline + Inside s'ajoutent plutôt que d'écraser), puis effectue une recherche ou une addition au niveau du classeur dans Workbook.Borders et écrit l'index de bordure résultant (1-based) sur la cellule. La nouvelle fonction d'aide TXLSXBorders.LookupOrAdd renvoie 0 pour les bordures vides, empêchant ainsi l'accumulation d'entrées inutiles.
      
    

      Version 2.23.0
      
        Ajout de fonctions de surcharge pour l'exportation CSV dans TXLSXWorkbook. Nouveaux points d'entrée : SaveAsCSV(FileName) / SaveAsCSV(FileName, SheetIndex, Delimiter) / SaveAsCSV(Stream) / SaveAsCSV(Stream, SheetIndex, Delimiter) écrivent la zone remplie de la feuille sélectionnée en UTF-8 avec un BOM initial et des terminaux de ligne CRLF. Les variantes par défaut sélectionnent la feuille active et la virgule comme délimiteur ; la surcharge SheetIndex/Delimiter accepte n'importe quel caractère WideChar (généralement la tabulation #9 pour TSV). Le guillemotage des champs suit la RFC 4180 : les valeurs contenant le délimiteur, le double guillemet, CR ou LF sont entourées de guillemets, les guillemets internes étant doublés. Les valeurs de date sont affichées au format 'aaaa-mm-jj hh:nn:ss' ; les cellules de texte enrichi sont aplaties en concaténant le texte de chaque exécution ; les cellules vides à l'intérieur du rectangle délimiteur sont affichées sous forme de délimiteurs nus et la ligne s'arrête à la dernière colonne remplie.
      
    

      Version 2.22.0
      
        Ajout de remplacements de palette de couleurs indexées au niveau du classeur dans TXLSXWorkbook. Nouveaux points d'entrée : IndexedColor[Index: Integer]: LongWord (lecture/écriture, emplacements valides 0..63, LongWord ARGB), HasCustomIndexedColor(Index): Boolean (indique si l'appelant a remplacé un emplacement), CustomIndexedColorCount: Integer (nombre d'emplacements remplacés ; 0 = la palette émet la valeur par défaut), ResetIndexedColors: procédure (supprime toutes les remplacements). La constante XlsxDefaultIndexedPalette expose la palette héritée OOXML ECMA-376 pour les emplacements 0..63. SaveAs émet <colors><indexedColors> avec les 64 enfants <rgbColor> uniquement si au moins un emplacement a été remplacé ; les emplacements non modifiés utilisent la palette par défaut, ce qui permet de conserver les fichiers propres lorsqu'ils sont enregistrés sans modifications. Open analyse le bloc et supprime silencieusement les emplacements dont la valeur correspond à la valeur par défaut, ce qui réduit au minimum les opérations de relecture. Les affectations d'emplacements hors plage (< 0 ou > 63) sont ignorées au lieu de générer une erreur.
      
    

      Version 2.21.0
      
        Ajout de six propriétés d'affichage pour la vue feuille dans TXLSXWorksheet. Zoom : Entier représentant le pourcentage de zoom affiché dans la barre d'état d'Excel (10..400, par défaut 100 ; les valeurs hors plage sont ramenées à la valeur la plus proche). DisplayGridLines / DisplayZeros : Booléen (par défaut True) pour masquer les lignes de la grille des cellules ou afficher les cellules avec une valeur de zéro comme vides lorsque défini sur False. DisplayRightToLeft : Booléen (par défaut False) pour inverser la disposition de la feuille en mode RTL (de droite à gauche) pour l'arabe, l'hébreu, etc. StandardWidth / StandardHeight : Double pour définir la largeur par défaut des colonnes (unités de caractères Excel) / la hauteur par défaut des lignes (points) ; 0 = non défini, auquel cas Excel applique ses valeurs par défaut intégrées de 8,43 / 15. SaveAs génère les balises <sheetView showGridLines / showZeros / rightToLeft / zoomScale> et <sheetFormatPr defaultColWidth / defaultRowHeight> uniquement lorsque les valeurs diffèrent des valeurs par défaut d'Excel ; Open les analyse pour les restaurer. La gestion existante de la sélection des onglets et de la mise en surbrillance des cellules est inchangée et utilise désormais un seul composant d'émission.
      
    

      Version 2.20.7
      
        Ajout de surcharge TStream dans TXLSXWorkbook pour la sérialisation en mémoire. Nouveaux points d'entrée : SaveAs(Stream: TStream) / SaveAs(Stream: TStream; FileFormat: TXLSXFileFormat) écrit l'intégralité du package .xlsx dans le flux spécifié, en commençant à la position actuelle ; Open(Stream: TStream) le lit. L'appelant est propriétaire du flux et doit le libérer. Utile pour les réponses HTTP, le stockage blob, les pipelines en mémoire et les tests unitaires qui contournent le système de fichiers local. Les surcharges SaveAs / Open basées sur des fichiers existantes sont inchangées et délèguent désormais aux mêmes fonctions internes d'écriture / de lecture.
      
    

      Version 2.20.6
      
        Ajout des propriétés Hidden / Visible / Comment à TXLSXDefinedName. Hidden correspond à l'attribut OOXML <definedName hidden="1"/> (par défaut False / Visible=True ; True masque le nom dans l'interface utilisateur du gestionnaire de noms d'Excel). Visible est un alias booléen (inverse de Hidden) pour un code plus clair au niveau de l'appel. Comment correspond à <definedName comment="..."/> . SaveAs génère les deux attributs uniquement lorsque les valeurs diffèrent des valeurs par défaut ; Open les analyse pour les restaurer. SheetIndex (la liaison de portée locale existante via localSheetId) est inchangée.
      
    

      Version 2.20.5
      
        Ajout de cinq traits de police supplémentaires à TXLSXFont. Nouvelle énumération TXLSXFontVertAlign (xlsxVertAlignBaseline / Superscript / Subscript) qui contrôle les cases à cocher "Superscript" / "Subscript" existantes dans Excel via une seule propriété VertAlign (mutuellement exclusives dans l'interface utilisateur). Nouvelles propriétés OutlineFont et Shadow de type Boolean pour les effets de police correspondants dans Excel. Nouvel entier Family (numéro de famille de police OOXML : 1=Roman / 2=Swiss / 3=Modern / 4=Script / 5=Decorative ; 0=non défini) et CharSet (numéro de jeu de caractères GDI : 0=ANSI / 1=Default / 134=GB2312 / 136=ChineseBig5 / etc. ; -1=non défini). SaveAs génère les éléments enfants correspondants <vertAlign> / <outline/> / <shadow/> / <family> / <charset> à l'intérieur de <font> ; Open les analyse pour les restaurer. ColorIndex / ThemeColor / TintAndShade seront implémentés dans une prochaine version axée sur les thèmes.
      
    

      Version 2.20.4
      
        Ajout de commutateurs pour la direction des diagonales des bordures. TXLSXBorder expose maintenant DiagonalUp: Boolean et DiagonalDown: Boolean. Ces deux indicateurs partagent le Style et la Couleur de la bordure diagonale existante et déterminent quelle(s) direction(s) diagonale(s) Excel doit afficher : uniquement vers le haut (inférieur gauche vers supérieur droit), uniquement vers le bas (supérieur gauche vers inférieur droit), ou les deux. SaveAs génère les attributs diagonalUp / diagonalDown sur l'élément <border> lorsqu'ils sont définis ; Open les lit pour les restaurer. Auparavant, le moteur écrivait une seule bordure diagonale sans contrôle de direction, ce qui empêchait Excel de dessiner l'une ou l'autre ligne diagonale.
      
    

      Version 2.20.3
      
        Ajout du commutateur workbook Date1904. TXLSXWorkbook expose maintenant une propriété Date1904: Boolean qui permet de choisir entre l'époque Windows 1900 (par défaut ; correspond à Excel pour Windows) et l'époque Mac 1904 (héritage Excel pour Mac). SaveAs génère <workbookPr date1904="1"/> dans xl/workbook.xml lorsqu'il est défini ; Open le lit pour le restaurer. Cet indicateur est une métadonnée uniquement ; le moteur ne transforme pas les numéros de série stockés ; les appelants doivent définir Date1904 avant d'assigner des valeurs de cellule de type TDateTime afin que la conversion aller-retour se fasse correctement dans le calendrier approprié.
      
    

      Version 2.20.2
      
        Ajout du support des critères de filtre automatique par colonne. Nouveaux types : TXLSXAutoFilterOp (Égal / DifférentDe / SupérieurÀ / InférieurÀ / SupérieurOuÉgalÀ / InférieurOuÉgalÀ), TXLSXAutoFilterColumn (ColId + 1 ou 2 critères + connecteur AND/OR), TXLSXAutoFilterColumns. TXLSXWorksheet expose la propriété AutoFilterColumns et les méthodes AddAutoFilterColumn(ColId, Op, Criteria) / AddAutoFilterColumn(ColId, Op1, Criteria1, Op2, Criteria2, AndConnector) / ClearAutoFilterColumns. SaveAs étend l'élément <autoFilter ref="..."/> existant en un corps de <filterColumn colId=N><customFilters and=0|1><customFilter operator="..." val="..."/>...</customFilters></filterColumn> par colonne lorsque des critères sont définis ; Open analyse la même structure. Auparavant, le moteur ne stockait que la plage de filtre automatique (sqref) et Excel affichait des menus déroulants de filtre vides.
      
    

      Version 2.20.1
      
        Ajout du support des sauts de page manuels sur TXLSXWorksheet. Nouvelles entrées : AddRowBreak(BeforeRow) / AddColBreak(BeforeCol) pour insérer un saut de page horizontal ou vertical avant une ligne/colonne donnée (sémantique "Avant" de l'interface utilisateur Excel - la ligne N commence une nouvelle page). Vérification HasRowBreak / HasColBreak ; RemoveRowBreak / RemoveColBreak supprime une seule entrée ; ClearRowBreaks / ClearColBreaks / ClearAllPageBreaks efface en masse. RowBreakCount / ColBreakCount + RowBreaks(Index) / ColBreaks(Index) indexés exposent les indices "Avant" basés sur 1 pour l'itération. SaveAs génère <rowBreaks> / <colBreaks> avec des enfants <brk id="N-1" max="..." man="1"/> entre <headerFooter> et <drawing> ; Open les analyse.
      
    

      Version 2.20.0
      
        Ajout de la visibilité des feuilles (Masquée / TrèsMasquée), de la sélection par feuille et du suivi de la feuille active sur TXLSXWorkbook / TXLSXSheets / TXLSXWorksheet. Nouveaux types : TXLSXSheetVisibility (xlsxSheetVisible / xlsxSheetHidden / xlsxSheetVeryHidden). Nouvelles propriétés de TXLSXWorksheet : Visibility, Visible (alias booléen), IsSelected (lecture seule). Nouveaux membres de TXLSXSheets : ActiveIndex, Activate(Index), Move(FromIndex, ToIndex). Nouveau proxy TXLSXWorkbook.ActiveSheet. SaveAs génère <sheet state="..."/> sur les entrées de feuilles du classeur, <bookViews><workbookView activeTab=N/></bookViews> lorsque la feuille active n'est pas la valeur par défaut 0, et tabSelected="1" sur l'élément <sheetView> de la feuille active ; Open analyse les trois. La première feuille ajoutée est à la fois visible et active par défaut, afin que les anciens sites d'appel continuent de fonctionner.
      
    

      Version 2.19.2
      
        Ajout de quatre options supplémentaires pour l'attribut PageSetup dans TXLSXWorksheet afin de couvrir complètement l'élément OOXML <pageSetup> : BlackAndWhite (rendu noir et blanc), Draft (supprime les graphiques pour un aperçu plus rapide), PrintNotes (affiche les commentaires des cellules au lieu de les masquer) et PrintOverThenDown (parcourt les lignes de gauche à droite au lieu de la disposition par défaut de haut en bas). SaveAs génère les attributs correspondants blackAndWhite / draft / cellComments / pageOrder ; Open les analyse pour les réutiliser. Les valeurs par défaut restent désactivées afin que les feuilles de calcul inchangées n'acquiert pas d'attributs supplémentaires.
      
    

      Version 2.19.1
      
        Ajout de propriétés pratiques pour les en-têtes et pieds de page en trois parties dans TXLSXWorksheet. Nouvelles entrées : LeftHeader / CenterHeader / RightHeader et LeftFooter / CenterFooter / RightFooter. Chacune lit ou écrit la section &L / &C / &R de la chaîne brute existante HeaderText / FooterText ; l'écriture d'une seule section reconstruit la forme brute complète afin que l'enregistreur et le lecteur fonctionnent sans modifications.
        Ajout d'options d'impression pour la sortie des pages au niveau de la feuille. Nouvelles propriétés TXLSXWorksheet : CenterHorizontally, CenterVertically, PrintGridlines, PrintHeadings. SaveAs génère un élément <printOptions horizontalCentered / verticalCentered / gridLines / headings/> lorsque l'une de ces quatre options est activée ; Open analyse les mêmes attributs. Les valeurs par défaut restent désactivées afin que les feuilles de calcul inchangées n'acquiert pas d'élément <printOptions/> supplémentaire.
        Ajout de la prise en charge de la sauvegarde et de la lecture des zones d'impression (PrintArea), des lignes d'en-tête (PrintTitleRows) et des colonnes d'en-tête (PrintTitleCols) au niveau de chaque feuille. Ceux-ci correspondent aux définitions de noms intégrés au niveau du classeur OOXML _xlnm.Print_Area et _xlnm.Print_Titles, définies via localSheetId. PrintArea prend une référence A1 simple (par exemple, "$A$1:$D$10"); PrintTitleRows et PrintTitleCols prennent des références de lignes ou de colonnes uniquement (par exemple, "$1:$3" ou "$A:$B") et les combinent en une seule entrée Print_Titles. L'enregistreur ajoute le nom de la feuille avec les guillemets appropriés (guillemets simples autour des noms contenant des espaces ou des caractères spéciaux) ; le lecteur supprime le préfixe et renvoie les entrées à la feuille correspondante, de sorte qu'elles ne se retrouvent pas dans la collection user-facing TXLSXWorkbook.DefinedNames.
      
    

      Version 2.19.0
      
        Ajout d'opérations d'insertion et de suppression de lignes/colonnes avec décalage complet au niveau de la feuille dans TXLSXWorksheet. Nouvelles entrées : InsertRows(BeforeRow, Count), DeleteRows(StartRow, Count), InsertCols(BeforeCol, Count), DeleteCols(StartCol, Count). InsertRows / InsertCols déplace les lignes/colonnes existantes vers la zone coupée de Count ; DeleteRows / DeleteCols supprime la plage [Start, Start+Count-1] et déplace tout ce qui se trouve après la zone coupée de Count.
        Ce déplacement s'applique à tous les éléments de géométrie de la feuille qui dépendent de la position de la ligne/colonne : les ancres de cellules (Cells), les coins des plages fusionnées (MergedCells - les plages chevauchantes sont tronquées aux bords restants et les plages internes sont supprimées), les listes de métadonnées de lignes/colonnes (FRowHeights / FColWidths / niveaux de contour / masqué / réduit), les ancres de liens hypertexte et de commentaires (les entrées situées dans une bande supprimée sont supprimées), FreezePane (FFreezeRow / FFreezeCol), AutoFilterRange, et la chaîne de plage par entrée pour chaque ConditionalFormat, DataValidation et tableau Excel (une entrée dont la plage se trouve entièrement dans la zone supprimée est supprimée).
        De nouveaux membres Delete(Index) ont été ajoutés aux collections associées afin que la logique de déplacement puisse supprimer une seule entrée sans effacement : TXLSXHyperlinks, TXLSXComments, TXLSXConditionalFormats, TXLSXDataValidations, TXLSXTables.
        Hors du champ de cette version : les images et les graphiques ne sont pas déplacés (leurs ancres EMU en pixels les séparent de la grille de cellules et un déplacement fidèle nécessiterait de recalculer les décalages EMU) ; les formules des noms définis au niveau du classeur ne sont pas réécrites. Les deux sont suivis pour une version ultérieure.
      
    

      Version 2.18.2
      
        Des fonctions d'ajustement automatique (AutoFit) ont été ajoutées pour les largeurs de colonnes et les hauteurs de lignes. TXLSXWorksheet expose AutoFitColumn(ACol) / AutoFitColumns(ColMin, ColMax) et AutoFitRow(ARow) / AutoFitRows(RowMin, RowMax) ; TXLSXRange expose AutoFitColumns et AutoFitRows qui transmettent l'appel à la feuille, en respectant les limites de la plage. La largeur est estimée en unités de caractères Excel (Calibri 11pt, les caractères ASCII comptent pour 1, les caractères CJK comptent pour 2) avec une correction de 1,20 px par caractère et un espacement de 1,0, et est limitée à [8,43 ; 255,0]. La hauteur de ligne par défaut est de 15 pt et augmente de 12,75 pt par saut de ligne dans le texte de la cellule. Les plages larges (EntireRow / EntireColumn) sont limitées à la dernière ligne/colonne contenant une cellule de la feuille afin que l'ajustement automatique ne fasse pas itérer jusqu'aux limites de la grille Excel.
      
    

      Version 2.18.1
      
        Ajout d'une fonctionnalité de protection au niveau de la cellule, avec conversion aller-retour vers le moteur XLSX. TXLSXCell expose de nouvelles propriétés pratiques Locked : Boolean (par défaut True) et FormulaHidden : Boolean (par défaut False) qui reflètent le modèle de protection des cellules d'Excel. Elles exposent l'index du pool TXLSXCell.ProtectionIndex (de 1 à 1 dans le nouveau pool au niveau du classeur TXLSXProtections) ; l'écriture de la propriété pratique recherche ou ajoute la paire (Locked, FormulaHidden) dans le pool. Les valeurs par défaut (Locked=True, FormulaHidden=False) correspondent à ProtectionIndex=0, ce qui maintient le pool vide pour les cellules standard.
        Ajout des fonctions TXLSXRange.SetLocked(ALocked) et TXLSXRange.SetFormulaHidden(AHidden) pour simplifier le déverrouillage ou la dissimulation d'une plage entière, en effectuant une seule recherche ou ajout et en appliquant le résultat à chaque cellule du rectangle.
        Ajout des mécanismes de lecture/écriture correspondants. La fonction SaveAs génère un cellXf avec un élément enfant inline <protection locked="N" hidden="M"/> pour chaque entrée de Protections dans le classeur ; Open analyse l'élément <protection> et le réintègre dans Workbook.Protections, et transmet le nouveau CellXfProtMap via ParseStylesXml et ParseWorksheetXml afin que l'index de protection de chaque cellule soit conservé avec les index existants de police, de remplissage, de bordure, de format de nombre et d'alignement.
      
    

      Version 2.18.0
      
        Ajout de l'objet TXLSXRange pour l'accès à plusieurs cellules et les opérations par lots sur TXLSXWorksheet. Nouveaux points d'entrée : Worksheet.Range['A1:C5'], Worksheet.RCRange[r1,c1,r2,c2], Worksheet.UsedRange, Worksheet.EntireRow(r), Worksheet.EntireColumn(c). La plage retournée expose SetValue / SetFormula / Clear / ClearAll / Merge / Unmerge / Offset / Resize, ainsi que les setters d'index de style par cellule (SetFontIndex / SetFillIndex / SetBorderIndex / SetNumberFormatIndex / SetAlignmentIndex), et une fonction pratique SetNumberFormat(Fmt) qui recherche ou ajoute la chaîne de format dans le pool du classeur. Les objets TXLSXRange appartiennent à la feuille et sont libérés lors de la destruction de la feuille ; les appelants ne les libèrent pas.
        Ajout de TXLSXCell.NumberFormat: WideString, qui s'associe à l'existing NumberFormatIndex. La lecture renvoie la chaîne de format à partir du pool du classeur ; l'écriture recherche ou ajoute la chaîne et met à jour NumberFormatIndex de manière transparente. Nécessite que la cellule soit attachée à un classeur (le flux standard via TXLSXWorkbook.Sheets.Add(...).Cells[r, c]).
        Ajout de références arrière cellule -> feuille -> classeur afin que chaque TXLSXCell puisse déterminer son classeur propriétaire sans nécessiter de gestion externe. TXLSXSheets, TXLSXWorksheet et TXLSXCells ont acquis des références internes Owner, connectées via leurs constructeurs ; TXLSXCell expose une propriété Workbook en lecture seule et une fonction interne SetWorkbook utilisée par TXLSXCells.GetItem lors de la création automatique d'une cellule lors de l'accès.
      
    

      Version 2.17.42
      
        Correction du problème de conversion des cellules XLSX lors de la réouverture. Les cellules écrites par SaveAs étaient supprimées lors de l'ouverture, avec HasCell(row, col) renvoyant False et toutes les informations d'état au niveau de la cellule (valeur, formule, index de police, index de remplissage, index de bordure, index de format numérique) étaient perdues. La cause était un appel inutile à MoveToAttribute('r') dans l'analyseur de feuille de calcul, qui modifiait le type de nœud du lecteur en attribut, ce qui rendait la vérification IsEmptyElement renvoyer True et désactivait l'analyse des cellules pour chaque élément <c> avec un attribut r="", c'est-à-dire chaque cellule. La suppression de ce déplacement de curseur inutile restaure la conversion des cellules texte, numériques, de formule et de date.
        Correction de la restauration de l'index de style XLSX lors de la réouverture. Les index de police, de remplissage, de bordure et de format numérique personnalisés des cellules étaient lus comme zéro, même après que les pools correspondants (Workbook.Fonts/Fills/Borders/NumberFormats) avaient été correctement convertis. L'analyseur cellXf suivait sa position avec un compteur qui n'était incrémenté que sur la balise de fin </xf>, mais Excel émet souvent des entrées auto-fermantes <xf .../> (sans balise <alignment> interne), de sorte que le compteur ne dépassait jamais zéro et chaque mappage cellXf écrasait le précédent. L'analyseur incrémente maintenant le compteur pour les balises auto-fermantes <xf />, ce qui permet la conversion des index FontIndex / FillIndex / BorderIndex / NumberFormatIndex par cellule.
        Correction de la conversion des cellules de date XLSX. L'écriture d'une valeur TDateTime dans TXLSXCell.Value passait auparavant par le pool de chaînes partagées avec t="s" parce que Delphi's VarIsNumeric() renvoie False pour varDate. SaveAs écrit maintenant le numéro de série de la date directement dans <v> et applique la celluleXf de date, de sorte que les cellules de date s'ouvrent en tant que Variant varDate au lieu d'une chaîne localisée que l'appelant ne pouvait pas reconvertir en TDateTime.
      
    

      Version 2.17.41
      
        Correction de l'erreur "le flux zlib ne prend pas en charge la recherche" qui se produisait lors de la réouverture des fichiers .xlsx contenant des images intégrées ou un projet VBA (.xlsm). Les chemins de rechargement des images et de la charge utile VBA acheminaient tous deux le flux d'entrée décompressé via TMemoryStream.CopyFrom(Source, 0), ce qui réinitialisait Source pour dériver le nombre d'octets ; cette réinitialisation n'est pas autorisée sur un flux Deflate en lecture seule. Les deux emplacements d'appel utilisent maintenant une fonction d'assistance de lecture par blocs jusqu'à la fin de fichier, de sorte que les fichiers .xlsx contenant des images ou des macros sont convertis via SaveAs/Open sans générer d'erreur.
      
    

      Version 2.17.40
      
        Ajout du support des feuilles de graphique (feuille de calcul graphique en pleine page) dans le moteur XLSX. L'objet TXLSXWorksheet expose un nouveau champ IsChartSheet, ainsi qu'une fonction utilitaire Workbook.AddChartSheet(Name, ChartType, Title) au niveau du classeur, qui crée la feuille, active le champ, et initialise Charts[0] avec une valeur par défaut appropriée. La fonction SaveAs écrit les feuilles IsChartSheet dans xl/chartsheets/sheetN.xml avec un fichier rels dédié pointant vers la partie graphique partagée, les enregistre comme types de contenu de feuille de graphique, et génère la relation de feuille de graphique dans xl/_rels/workbook.xml.rels. Les feuilles de calcul ordinaires conservent leur chemin d'accès existant dans xl/worksheets/sheetN.xml. L'ouverture reconnaît les feuilles de graphique via le type de relation, mais les charge actuellement comme des feuilles de calcul ordinaires (leurs données de graphique arrivent toujours via les parties graphiques partagées).
      
    

      Version 2.17.39
      
        Ajout de la prise en charge de la rétractabilité des lignes/colonnes pour les groupes de contours dans le moteur XLSX. L'objet TXLSXWorksheet expose les propriétés booléennes RowCollapsed[Row] et ColCollapsed[Col], ainsi que les fonctions utilitaires SetRowCollapsed / SetColCollapsed / ClearRowCollapsed / ClearColCollapsed. La fonction SaveAs génère l'attribut collapsed="1" sur les entrées <row> et <col> correspondantes ; l'ouverture analyse cet attribut. Combiné aux attributs outlineLevel et hidden existants, cela permet au moteur XLSX de gérer une hiérarchie de groupement entièrement rétractable.
      
    

      Version 2.17.38
      
        Ajout de la prise en charge de la rétractabilité des lignes/colonnes pour le moteur XLSX. L'objet TXLSXWorksheet expose les propriétés booléennes RowHidden[Row] et ColHidden[Col], ainsi que les fonctions utilitaires SetRowHidden / SetColHidden / ClearRowHidden / ClearColHidden. La fonction SaveAs génère l'attribut hidden="1" sur les entrées <row> et <col> correspondantes ; l'ouverture analyse cet attribut et le stocke dans la feuille de calcul, de sorte que les lignes/colonnes masquées survivent à la sauvegarde sans nécessiter une largeur personnalisée ou un niveau de contour.
      
    

      Version 2.17.37
      
        Ajout de la prise en charge de la sauvegarde de la couleur de l'onglet de la feuille de calcul dans le moteur XLSX. L'objet TXLSXWorksheet expose les propriétés TabColor (ARGB) et TabColorIsAuto. La fonction SaveAs génère un bloc <sheetPr><tabColor rgb="..."/></sheetPr> comme premier enfant de <worksheet> lorsque la couleur de l'onglet est définie ; l'ouverture analyse l'élément <tabColor> et le stocke dans la feuille de calcul, de sorte que les onglets de feuille de calcul colorés survivent à la sauvegarde. Les classeurs par défaut ne contiennent pas ce bloc supplémentaire (TabColorIsAuto = True).
      
    

      Version 2.17.36
      
        Ajout de la fonctionnalité de sauvegarde et de restauration de l'alignement des cellules dans le moteur XLSX. Nouvelles énumérations de jetons TXLSXHorizontalAlignment et TXLSXVerticalAlignment, classe TXLSXAlignment (Horizontal, Vertical, WrapText, ShrinkToFit, Indent, TextRotation), et une collection TXLSXAlignments au niveau du classeur (Workbook.Alignments). TXLSXCell contient désormais un AlignmentIndex (index basé sur 1 dans Workbook.Alignments). La fonction SaveAs ajoute un cellXf avec un élément enfant <alignment> en ligne pour chaque entrée d'alignement du classeur ; la fonction Open lit les attributs <alignment> et les mappe dans Workbook.Alignments, puis associe le cellXf à TXLSXCell.AlignmentIndex. Les fonctions ParseWorksheetXml et ParseStylesXml ont reçu un paramètre CellXfAlignMap pour gérer la correspondance entre les deux phases.
      
    

      Version 2.17.35
      
        Ajout de l'API de chiffrement AES (chiffrement selon la norme ECMA-376) au moteur XLSX. TXLSXWorkbook expose les fonctions SaveAsEncrypted(FileName, Password) / OpenEncrypted(FileName, Password) / CanReadEncrypted(FileName), ainsi qu'une exception EXlsxEncryptionNotImplemented. CanReadEncrypted reconnaît les octets magiques du fichier binaire Microsoft Compound File ($D0 $CF $11 $E0 $A1 $B1 $1A $E1), permettant aux appelants de détecter les archives chiffrées avant de décider comment les ouvrir ; OpenEncrypted revient de manière transparente à la fonction Open standard pour les fichiers .xlsx non chiffrés. Le pipeline AES-128/256 + SHA + OLE Compound File lui-même n'est pas encore implémenté ; la lecture et l'écriture de fichiers réellement chiffrés génèrent l'exception spécifiée jusqu'à la prochaine version, qui implémentera l'algorithme. Le type d'exception est distinct pour permettre aux appelants existants de la capturer et de revenir à Worksheet.Protect / Workbook.ProtectWorkbook pour le verrouillage visuel.
      
    

      Version 2.17.34
      
        Performances : remplacement de la concaténation de chaînes WideString, qui avait une complexité O(N^2) pour la construction des lignes de cellules de chaque feuille, par un TXLSWideStringBuilder. Les grandes feuilles (10 000 cellules ou plus) restent linéaires en termes de mémoire et de CPU lors de la sauvegarde. Ajout d'une nouvelle fonction utilitaire WriteWorksheetXmlStreaming et d'un indicateur opt-in TXLSXWorkbook.StreamingWrite ; lorsque cet indicateur est activé, SaveAs ne conserve plus toutes les feuilles XML dans un cache sheetXmls simultanément ; chaque feuille est construite, écrite et supprimée avant de passer à la suivante. Le fichier sharedStrings.xml est généré en dernier, de sorte que le chemin de streaming produit toujours un SST entièrement rempli. Le comportement par défaut reste inchangé.
      
    

      Version 2.17.33
      
        Ajout d'opérations sur les plages de cellules au moteur XLSX. L'objet TXLSXWorksheet expose ClearRange(R1, C1, R2, C2), CopyRange(SrcR1, SrcC1, SrcR2, SrcC2, DstR, DstC) pour la copie dans la même feuille, CopyRangeTo(... TargetSheet, DstR, DstC) pour la copie entre feuilles, et MoveRange(SrcR1, SrcC1, SrcR2, SrcC2, DstR, DstC) pour le copier-coller. Chaque opération duplique la valeur de la cellule, la formule, les quatre indices de style et toute charge utile de texte enrichi ; MoveRange évite les chevauchements avec la destination, de sorte que les chevauchements partiels conservent leurs valeurs copiées. L'objet TXLSXCells gagne également une fonction utilitaire Remove(Row, Col).
      
    

      Version 2.17.32
      
        Ajout d'ancres de liens internes au moteur XLSX. L'objet TXLSXHyperlink possède maintenant une propriété Location (par exemple, "Sheet2!A1") et une fonction utilitaire IsInternal ; TXLSXHyperlinks expose AddInternal, et TXLSXWorksheet ajoute trois versions surchargées de AddHyperlinkToCell. SaveAs génère des liens internes avec l'attribut inline location="" et omet l'entrée de relations de la feuille ; Open reconnaît les liens location="" et les redirige vers AddInternal. Les liens URL externes continuent de transiter à travers le fichier de relations sans modification.
      
    

      Version 2.17.31
      
        Ajout du support aller-retour du texte enrichi au moteur XLSX. Nouvelle classe TXLSXRichTextRun (par exécution : Nom / Taille / Gras / Italique / Barré / Souligné / Couleur) et conteneur TXLSXRichText qui expose AddRun / AddRunText / Clear / PlainText. L'objet TXLSXCell possède maintenant une propriété RichText associée ; SaveAs écrit la cellule en tant que chaîne partagée avec plusieurs exécutions <r>/<rPr>/<t> et Open reconstruit l'objet TXLSXRichText à partir de l'entrée SST analysée, la valeur Variant de la cellule affichant toujours le texte brut concaténé pour les appelants qui ignorent la mise en forme.
      
    

      Version 2.17.30
      
        Ajout du support aller-retour des graphiques au moteur XLSX. Nouvel énumérateur TXLSXChartType (colonne / barre / ligne / circulaire), TXLSXChartSeries (Nom, PlageDeCatégories, PlageDeValeurs) et TXLSXChart (TypeDeGraphique, Titre, titres des axes, cellules d'ancrage From/To, Séries) ainsi qu'une collection TXLSXCharts par feuille (Worksheet.Charts). TXLSXWorksheet expose AddChart(Type, Titre, FromRow, FromCol, ToRow, ToCol). SaveAs génère xl/charts/chartN.xml (numérotation globale du classeur) et le lie à une ancre à deux cellules / cadre graphique dans le fichier xl/drawings/drawingN.xml partagé ; Open analyse à la fois l'ancre et la définition du graphique et les reconstitue dans la collection. Les titres de graphiques, les titres des axes, les noms des séries et les plages sources sont pris en charge dans le cycle aller-retour.
      
    

      Version 2.17.29
      
        Correction d'une erreur EListError "Opération non autorisée sur une liste triée" levée par SetColWidth, SetRowHeight, SetRowOutlineLevel et SetColOutlineLevel. Les quatre champs TStringList étaient créés avec Sorted=True, mais modifiés via le setter Values[Name] := X, ce que l'environnement d'exécution (RTL) de RAD Studio refuse sur une liste triée. Les listes sont maintenant créées non triées; les recherches continuent via IndexOfName, ce qui est acceptable pour les nombres typiques de colonnes/lignes par feuille.
      
    

      Version 2.17.28
      
        Correction de TZipArchive.Exists, qui était un stub qui renvoyait toujours false. Le chemin d'accès XLSX Open utilise zip.Exists(...) pour vérifier chaque partie avant de la lire, ce qui signifie que chaque tentative précédente de sauvegarde (cellules, styles, commentaires, dessins, propriétés du document, noms définis, protection, VBA, etc.) perdait silencieusement son contenu lors de la lecture. Exists délègue désormais à la recherche existante Fcd.Entries.Exists, ce qui correspond au modèle OpenFile / CreateFile.
      
    

      Version 2.17.27
      
        Ajout de la préservation des projets VBA au moteur XLSX. TXLSXWorkbook expose une charge utile VBA Project ainsi que les fonctions LoadVbaProjectFromFile(FileName), ClearVbaProject et HasVbaProject. SaveAs écrit les octets dans xl/vbaProject.bin, enregistre le type de contenu .bin, modifie le type de contenu du classeur vers la variante activée pour les macros et ajoute une relation vbaProject au fichier rels du classeur; Open lit les octets de xl/vbaProject.bin dans la propriété. Les octets ne sont pas analysés ni modifiés, de sorte que les projets .xlsm existants sont sauvegardés et restaurés exactement. Note : les classeurs activés pour les macros doivent être enregistrés avec l'extension .xlsm pour que Excel active les macros.
      
    

      Version 2.17.26
      
        Ajout de la protection des classeurs et des feuilles au moteur XLSX. TXLSXWorksheet expose Protect / Protect(Password) / UnProtect ainsi que IsProtected et SheetProtectHash; TXLSXWorkbook ajoute ProtectWorkbook (avec les drapeaux facultatifs password, LockStructure, LockWindows) et UnProtectWorkbook ainsi que IsWorkbookProtected / WorkbookProtectHash / LockStructure / LockWindows. SaveAs émet <sheetProtection> pour chaque feuille protégée et <workbookProtection> pour les classeurs protégés; Open analyse les deux blocs et les remet dans l'API. Les mots de passe sont stockés sous la forme du hachage standard en 4 hexadécimaux pour garantir la fidélité de la sauvegarde et de la restauration (le texte brut d'origine n'est pas récupérable).
      
    

      Version 2.17.25
      
        Ajout de la sauvegarde et de la restauration des propriétés du document au moteur XLSX. TXLSXWorkbook expose désormais les propriétés Title, Author, Subject, Keywords, Description, Category, LastModifiedBy, Created, Modified, Company, Application et AppVersion. SaveAs émet docProps/core.xml et docProps/app.xml (et les enregistre dans [Content_Types].xml + _rels/.rels) chaque fois qu'une propriété est modifiée; Open analyse les deux fichiers et les remet dans l'API, ce qui permet aux auteurs, aux horodatages de modification et aux métadonnées de l'application de survivre à une sauvegarde et à une réouverture.
      
    

      Version 2.17.24
      
        Ajout de la fonctionnalité de sauvegarde et de restauration des tableaux au format Excel dans le moteur XLSX. Nouvelle classe TXLSXTable (Id, Name, DisplayName, Range, Columns, StyleName, ShowFirstColumn / ShowLastColumn / ShowRowStripes / ShowColumnStripes) et une collection TXLSXTables par feuille. TXLSXWorksheet expose les tableaux et la méthode AddTable(Name, Range, ColumnNames). SaveAs génère xl/tables/tableN.xml (numérotation globale du classeur), met à jour les relations de la feuille avec les relations des tableaux, ajoute <tableParts> à la feuille et enregistre le type de contenu du tableau. Open analyse les relations des tableaux et tableN.xml pour les réintégrer dans la feuille, ce qui permet aux bandes de tableaux formatées de survivre à une sauvegarde et à une réouverture.
      
    

      Version 2.17.23
      
        Ajout de la fonctionnalité de sauvegarde et de restauration des filtres automatiques dans le moteur XLSX. TXLSXWorksheet expose la propriété AutoFilterRange ainsi que les méthodes SetAutoFilter(Row1, Col1, Row2, Col2) / SetAutoFilter(Range) / ClearAutoFilter. SaveAs génère la balise <autoFilter ref="..."/> après le bloc de fusion de cellules lorsque la plage n'est pas vide ; Open analyse l'attribut ref et le réintègre dans la propriété, ce qui permet à la bande de filtre d'une feuille de survivre à une sauvegarde et à une réouverture.
      
    

      Version 2.17.22
      
        Ajout de la fonctionnalité de sauvegarde et de restauration des paramètres de page dans le moteur XLSX. TXLSXWorksheet expose les propriétés Margin{Left,Right,Top,Bottom,Header,Footer}, PageLandscape, PaperSize, PageScale, FitToWidth, FitToHeight, HeaderText et FooterText, ainsi que les méthodes de commodité SetPageMargins(L, R, T, B[, H, F]). SaveAs génère les blocs correspondants <pageMargins>, <pageSetup> et <headerFooter> entre les hyperliens et les dessins ; Open les analyse et les réintègre. Les feuilles par défaut restent inchangées (l'indicateur PageSetupTouched contrôle la sortie).
      
    

      Version 2.17.21
      
        Ajout de la fonctionnalité de sauvegarde et de restauration de la fonction de "figer" des volets dans le moteur XLSX. TXLSXWorksheet expose les méthodes FreezePane(Col, Row) / UnfreezePane ainsi que les propriétés en lecture seule FreezeCol et FreezeRow. SaveAs écrit un bloc <sheetViews>/<pane state="frozen"> avant <sheetData> avec l'état activePane et la sélection correspondants ; Open analyse le bloc <pane state="frozen"> et le réintègre dans la position de "figer", ce qui permet aux dispositions "figer-haut/gauche/coin" de survivre à une sauvegarde et à une réouverture.
      
    

      Version 2.17.20
      
        Ajout des niveaux de regroupement de lignes et de colonnes dans le moteur XLSX. TXLSXWorksheet expose les propriétés indexées RowOutlineLevel[Row] et ColOutlineLevel[Col], ainsi que les méthodes SetRowOutlineLevel / HasRowOutlineLevel / ClearRowOutlineLevels et les méthodes correspondantes pour les colonnes. SaveAs génère les attributs outlineLevel sur les entrées <row> et les entrées <col> fusionnées (combinés avec les largeurs personnalisées lorsqu'elles sont présentes) ; Open analyse les deux attributs et les réintègre dans la feuille, ce qui permet aux hiérarchies de lignes/colonnes regroupées de survivre à la sauvegarde et à la restauration.
      
    

      Version 2.17.19
      
        Ajout du support de la mise en forme conditionnelle et de la validation des données dans le moteur XLSX. Nouvelles énumérations TXLSXCfOperator et classes TXLSXConditionalFormat (Range, Op, Formula1, Formula2) ainsi qu'une collection TXLSXConditionalFormats pour chaque feuille de calcul (Worksheet.ConditionalFormats). Nouvelles classes TXLSXDataValidationType, TXLSXDvOperator, TXLSXDataValidation (Range, ValidationType, Op, Formula1, Formula2, AllowBlank, ShowInputMessage, ShowErrorMessage) et une collection TXLSXDataValidations (Worksheet.DataValidations) avec un raccourci AddList(Range, Items) pour les listes déroulantes courantes. TXLSXWorksheet expose les fonctions AddConditionalFormat et AddDataValidation / AddListValidation. La fonction SaveAs écrit les blocs <conditionalFormatting> (avec cfRule type="cellIs") et un bloc <dataValidations> après sheetData ; la fonction Open analyse ces blocs et les remet dans les collections.
      
    

      Version 2.17.18
      
        Ajout du support des noms définis dans le moteur XLSX. Nouvelle classe TXLSXDefinedName (Name, Formula, SheetIndex) et une collection TXLSXDefinedNames au niveau du classeur (Workbook.DefinedNames) avec les méthodes Add(Name, Formula[, SheetIndex]) et IndexOfName. La fonction SaveAs génère un bloc <definedNames> dans xl/workbook.xml ; les entrées avec SheetIndex >= 0 ont un attribut localSheetId (portée de feuille) et les entrées avec SheetIndex = -1 sont de portée globale. La fonction Open analyse les éléments <definedName> et les remet dans la collection, ce qui permet de conserver les plages nommées lors de l'ouverture et de la réouverture des classeurs.
      
    

      Version 2.17.17
      
        Ajout du support des images dans le moteur XLSX. Nouvelles énumérations TXLSXImageFormat (png, jpeg, gif, bmp), classe TXLSXImage (Row/Col anchor, WidthEMU/HeightEMU, Format, Data) et une collection TXLSXImages par feuille de calcul. TXLSXWorksheet expose la collection Images ainsi que les fonctions AddImage(Row, Col, Data, Format) et AddImageFromFile(Row, Col, FileName). La fonction SaveAs écrit les octets de l'image dans xl/media/imageN.<ext>, génère xl/drawings/drawingN.xml avec une ancre de cellule unique par image (et un fichier _rels correspondant), enregistre les types de contenu et les relations feuille de calcul/dessin, et génère une référence <drawing r:id="..."/> dans la feuille de calcul. La fonction Open analyse drawingN.xml + drawing rels + media pour remettre les images dans Worksheet.Images.
      
    

      Version 2.17.16
      
        Ajout d'un formatage numérique personnalisé pour la conversion aller-retour dans le moteur XLSX. Nouvelle classe TXLSXNumberFormat et collection TXLSXNumberFormats au niveau du classeur (Workbook.NumberFormats) qui suppriment les doublons des codes de format via Add(FormatCode). TXLSXCell expose une nouvelle propriété NumberFormatIndex ; SaveAs génère un bloc <numFmts> dans xl/styles.xml (les identifiants personnalisés commencent à la base 164 réservée par OOXML) et associe chaque format à un cellXf dédié. Open analyse les numFmts personnalisés et inverse la correspondance cellXf->numFmtId en NumberFormatIndex lors de la lecture. Priorité en cas de conflit : FormatIndex > FontIndex > FillIndex > BorderIndex > NumberFormatIndex.
      
    

      Version 2.17.15
      
        Ajout du formatage des bordures de cellule pour la conversion aller-retour dans le moteur XLSX. Nouvel énumérateur TXLSXBorderStyle, classe TXLSXBorderEdge (Style + Color + ColorIsAuto pour chaque côté), classe TXLSXBorder avec les bords Gauche/Droite/Haut/Bas/Diagonale, ainsi que des fonctions utilitaires SetAll(Style[, Color]), et une collection TXLSXBorders au niveau du classeur (Workbook.Borders) avec un raccourci Borders.AddBox(Style[, Color]). TXLSXCell expose une nouvelle propriété BorderIndex ; SaveAs génère chaque bordure dans xl/styles.xml et l'associe à un cellXf dédié. Open analyse les bordures et traduit la correspondance cellXf->borderId en BorderIndex lors de la lecture. La priorité reste FormatIndex > FontIndex > FillIndex > BorderIndex lorsque plusieurs sont définis sur la même cellule.
      
    

      Version 2.17.14
      
        Ajout du formatage de remplissage de cellule pour la conversion aller-retour dans le moteur XLSX. Les nouveaux énumérateurs TXLSXFillPattern et la classe TXLSXFill décrivent patternType, fgColor et bgColor ; la collection TXLSXFills au niveau du classeur est accessible via Workbook.Fills, avec une fonction utilitaire Fills.AddSolid(color) pour le cas courant de remplissage de couleur unie. TXLSXCell expose une nouvelle propriété FillIndex ; SaveAs génère chaque remplissage dans xl/styles.xml et l'associe à un cellXf dédié. Open les analyse et inverse les attributs de la cellule en FillIndex lors de la lecture. FontIndex conserve la priorité lorsque les deux sont définis.
      
    

      Version 2.17.13
      
        Finalisation du formatage des polices pour XLSX. Open analyse maintenant xl/styles.xml et le reconstruit dans Workbook.Fonts et une table cellXf->fontId ; chaque attribut s de la cellule est mappé vers TXLSXCell.FontIndex afin que les classeurs enregistrés et rouverts conservent les polices personnalisées (Nom, Taille, Gras, Italique, Barré, Souligné, Couleur).
      
    

      Version 2.17.12
      
        Ajout d'une classe TXLSXFont ainsi qu'une collection Workbook.Fonts pour que les cellules XLSX puissent choisir une police personnalisée. TXLSXCell possède une nouvelle propriété FontIndex ; SaveAs génère la liste des polices dans xl/styles.xml et un cellXf par police, puis fait référence au cellXf correspondant de chaque cellule dans son attribut s. La conversion aller-retour de FontIndex est prévue pour la prochaine version.
      
    

      Version 2.17.11
      
        Ajout de la gestion des hauteurs de ligne dans le moteur XLSX. L'objet TXLSXWorksheet expose une propriété RowHeight[Row] ainsi que les fonctions SetRowHeight, HasRowHeight et ClearRowHeights. La fonction SaveAs écrit les attributs "ht" et "customHeight="1"" sur chaque balise <row> avec une hauteur personnalisée (y compris les lignes qui ne contiennent qu'une hauteur, sans données de cellule) ; la fonction Open lit l'attribut "ht" et le stocke dans la carte des hauteurs de ligne.
      
    

      Version 2.17.10
      
        Ajout de la gestion des largeurs de colonne dans le moteur XLSX. L'objet TXLSXWorksheet expose une propriété ColWidth[Col] ainsi que les fonctions SetColWidth, HasColWidth et ClearColWidths. La fonction SaveAs génère un bloc <cols> avec une entrée <col> par colonne personnalisée ; la fonction Open relit les entrées <col min/max/width> dans la feuille de calcul, de sorte que les largeurs non modifiées reprennent les valeurs par défaut d'Excel.
      
    

      Version 2.17.9
      
        Ajout de la gestion des commentaires de cellule dans le moteur XLSX. L'objet TXLSXWorksheet expose une collection Comments et les fonctions AddComment(Row, Col, Text[, Author]). La fonction SaveAs génère les fichiers xl/commentsN.xml (avec une liste d'auteurs dédupliquée) et un fichier compagnon xl/drawings/vmlDrawingN.vml afin qu'Excel puisse afficher les ballons de commentaires ; la fonction Open lit les commentairesN.xml et les stocke dans la collection. Les relations de la feuille de calcul, les types de contenu et la configuration de <legacyDrawing> sont gérés automatiquement.
      
    

      Version 2.17.8
      
        Ajout de la gestion des hyperliens dans le moteur XLSX. L'objet TXLSXWorksheet expose une collection Hyperlinks et les fonctions AddHyperlink(Row, Col, Url[, Display[, Tooltip]]). La fonction SaveAs écrit un bloc <hyperlinks> dans chaque feuille de calcul et génère un fichier correspondant xl/worksheets/_rels/sheetN.xml.rels contenant les URL cibles externes ; la fonction Open lit d'abord les relations de la feuille de calcul pour résoudre les entrées <hyperlink r:id="..."/> en URL dans la collection.
      
    

      Version 2.17.7
      
        Ajout de la gestion des cellules fusionnées dans le moteur XLSX. L'objet TXLSXWorksheet expose une collection MergedCells et une fonction MergeCells(R1, C1, R2, C2) qui reproduit le style de l'interface BIFF. La fonction SaveAs génère un bloc <mergeCells> après sheetData, et la fonction Open analyse les entrées <mergeCell ref="A1:B2"/> et les stocke dans la collection.
      
    

      Version 2.17.6
      
        Le moteur XLSX effectue désormais une conversion aller-retour des valeurs de date et des formules. Les valeurs de cellule TDateTime sont sérialisées en tant que numéros de série Excel et marquées avec un style de cellule intégré pour que Excel les affiche comme des dates ; lors de l'ouverture, les cellules dont le style fait référence au style de cellule pour la date sont décodées en variantes TDateTime. TXLSXCell expose une nouvelle propriété Formula ; SaveAs écrit la formule en tant qu'élément enfant <f> et Open analyse le texte de <f> et le stocke dans la cellule.
      
    

      Version 2.17.5
      
        Un modèle de fichier styles.xml a été ajouté au moteur XLSX. SaveAs génère maintenant un fichier xl/styles.xml minimal et valide avec les polices, les remplissages, les bordures, les cellStyleXfs et les cellXfs par défaut, ainsi que les enregistrements de type de contenu et de relation de classeur correspondants. Les cellules possèdent une propriété FormatIndex et émettent l'attribut de cellule s="N" lorsqu'il est différent de zéro, et Open lit s="N" et le stocke dans FormatIndex. Les descripteurs de style concrets (polices, remplissages, bordures, cellXfs en tant que collections au niveau du classeur) seront ajoutés dans les commits suivants.
      
    

      Version 2.17.4
      
        La prise en charge des chaînes partagées (SST) a été ajoutée au moteur XLSX. SaveAs crée un tableau de chaînes dédupliquées et génère le fichier xl/sharedStrings.xml, remplaçant l'émission de chaînes intégrées. Open lit d'abord xl/sharedStrings.xml et résout les références de cellule t="s" via le SST. Les cellules de chaîne intégrées provenant de fichiers XLSX tiers sont toujours acceptées lors de l'ouverture.
      
    

      Version 2.17.3
      
        Le tableau d'enregistrements de cellules dans TXLSXWorksheet a été remplacé par des objets TXLSXCell et une collection TXLSXCells. Le site d'appel d'accès aux cellules lit désormais Worksheet.Cells.Item[Row, Col].Value, ce qui correspond à la forme IXLSCells / IXLSRange sur la façade BIFF. Worksheet.Cells.HasCell / Cells.Count / Cells.CellByIndex / Cells.Clear sont également disponibles.
      
    

      Version 2.17.2
      
        La classe de collection TXLSXSheets a été introduite dans TXLSXWorkbook, reflétant la collection IXLSWorkSheets sur la façade BIFF. Le code lit désormais Workbook.Sheets.Add / Workbook.Sheets.Count / Workbook.Sheets[i] / Workbook.Sheets.IndexByName au lieu des méthodes Workbook.AddSheet / Workbook.SheetCount / Workbook.Sheet[i] précédentes.
      
    

      Version 2.17.1
      
        Renommé TXLSXWorkbook.SaveToFile en SaveAs et TXLSXWorkbook.LoadFromFile en Open, pour correspondre au style de nommage existant de IXLSWorkBook. Ajouté des surcharges pour le format de fichier et le mot de passe afin que la façade XLSX se comporte de la même manière que la façade BIFF. AddSheet offre maintenant une surcharge sans argument qui génère un nom de feuille par défaut.
      
    

      Version 2.17.0
      
        TXLSXWorkbook.SaveAs produit une archive .xlsx OOXML minimale avec les valeurs des cellules (nombres, booléens et chaînes intégrées). L'archive contient les types de contenu, les relations racines, le classeur + les relations, et une feuille de calcul par feuille.
        TXLSXWorkbook.Open lit l'archive .xlsx OOXML minimale : les noms des feuilles sont lus à partir de xl/workbook.xml et les valeurs des cellules sont lues à partir de xl/worksheets/sheetN.xml. Les chaînes partagées, les styles, les dates et les formules ne sont pas encore pris en charge.
        Ajouté l'espace de noms OOXML, les types de contenu et les constantes de relation, ainsi que les fonctions d'aide pour les références / l'analyse / l'échappement (XlsxColumnLabel, XlsxCellRef, XlsxColumnIndex, XlsxParseCellRef, XlsxParseRangeRef, XlsxEscapeText, XlsxEscapeAttr) pour être utilisés par les futures fonctionnalités XLSX.
      
    

      Version 2.16.4
      
        L'unité de façade XLSX (lxHandleX) définit maintenant ses propres types de classeur et de feuille de calcul (TXLSXWorkbook, TXLSXWorksheet), indépendamment de la façade BIFF. Les points d'entrée de sauvegarde et de chargement sont réservés ; la configuration OOXML sera complétée dans une version ultérieure.
        Ajout d'un sujet de référence pour les développeurs concernant la nouvelle façade XLSX, décrivant comment lxHandle et lxHandleX coexistent et quelles unités auxiliaires ils partagent.
      
    

      Version 2.16.3
      
        Introduction de lxHandleX, une unité de façade XLSX dédiée coexistant avec la façade BIFF existante lxHandle. Les deux unités partagent la même infrastructure sous-jacente (pools de styles, utilitaires XML, archive ZIP) mais exposent des hiérarchies de classes indépendantes : lxHandle gère TXLSWorkBook et les chemins classiques XLS/HTML/RTF/CSV ; lxHandleX gérera TXLSXWorkbook et toutes les API spécifiques à XLSX. Trois stubs de méthodes ajoutés accidentellement à lxHandle (SetCodePage, GetColumnXFIndex, GetRowXFIndex) ont été supprimés afin de conserver l’API publique de la façade BIFF identique à celle de v2.15.0. Le code existant utilisant lxHandle ne nécessite aucune modification.
      
    

      Version 2.16.2
      
        Ajout de trois unités internes de structures de données complétant les fondations du moteur XLSX : lxAvlTree fournit un arbre AVL O(log N) (TAVLTree/TAVLNode) pour les recherches triées ; lxCols et lxRows sont des conteneurs d’informations de colonnes et de lignes avec déduplication fine et réécriture d’index, utilisés par les cartes de largeur de colonne et de hauteur de ligne par feuille du moteur XLSX. Les trois unités sont dormantes dans cette version et seront activées dans v2.17.0 lors de la première activation du moteur de lecture/écriture XLSX.
      
    

      Version 2.16.1
      
        Ajout de six unités internes d’utilitaires XML et ZIP complétant la couche d’infrastructure du moteur XLSX : lxWStream (flux de fichier en caractères larges avec vérification d’existence du fichier et assistant d’écriture AnsiString) ; lxCacheStream (enveloppe de flux avec tampon réduisant les appels E/S sous-jacents) ; lxZlibStream (flux deflate/inflate en avance uniquement, indépendant de la liaison de chiffrement BIFF loZlib existante) ; lxXmlReader (lecteur à extraction de style SAX pour une analyse XML à haute vitesse) ; lxXmlWriter (écrivain XML en flux avec réutilisation des noms d’éléments) ; lxZipArchive (lecteur/écrivain ZIP à répertoire central avec flux deflate par entrée). Associées aux sept unités de v2.16.0, elles forment la fondation interne complète du moteur XLSX.
      
    

      Version 2.16.0
      
        Ajout de sept unités internes d’infrastructure de styles constituant la fondation du prochain moteur XLSX : lxHashTable (tables de hachage génériques avec variantes de clé entière, WideString et objet) ; lxKeyList (liste à clé objet avec recherche rapide et réécriture d’index) ; lxStyleColor (gestionnaire de couleurs de thème Office et de slots de palette) ; lxStyleFont, lxStyleFill et lxStyleBorder (pools dédupliqués pour les styles de police, de remplissage et de bordure couvrant les 12 types de lignes BIFF et les mappages de style XLSX) ; lxStyleXf (agrège les cinq pools de styles avec une liste de formats numériques en un seul enregistrement XF). Les sept unités sont dormantes dans cette version et n’affectent pas les chemins XLS existants.
      
    

      Version 2.15.1
      
        Ajout des fonctions utilitaires de couleur lxRgb : RGBtoHLS, HLStoRGB, RGBTint et GetRGBTint effectuent des conversions entre les espaces colorimétriques RGB et HLS (plage HLS 0–240). Elles sous-tendent les calculs de teinte de couleur de thème, la mise en forme conditionnelle par échelle de couleurs et l’interpolation de palette dans la sortie XLSX.
        Ajout des constructeurs de chaînes haute performance lxStrBuilder : TXLSStringBuilder (AnsiChar) et TXLSWideStringBuilder (WideChar) utilisent des tampons pré-alloués à croissance doublante pour éliminer la réallocation mémoire par concaténation des chaînes Pascal standard. La variante AnsiChar alimente le chemin de sérialisation XML XLSX ; la variante WideChar gère l’assemblage de chaînes larges dans l’analyseur XLSX.
      
    

      Version 2.15.0
      
        Refonte de la documentation HtmlHelp en une structure adaptée au web, avec des dossiers dédiés pour les sujets, les ressources, les scripts, les styles et les sources.
        Ajout d'une page d'accueil et d'une page de navigation du contenu conviviales pour les navigateurs, avec des en-têtes, des raccourcis vers les sujets et des pieds de page uniformes.