Delphi ve C++Builder Excel bileşeni olan HotXLS, bir satır veya sütun ekleme veya silme işlemi, bir kuralın kapsadığı aralığı farklı göreli formül sabitleyicilerine ihtiyaç duyan parçalara kestiğinde, bir koşullu biçimlendirme veya veri doğrulama kuralını otomatik olarak iki veya daha fazla ayrı kural nesnesine böler, ardından her koşullu biçim kuralına yeni, benzersiz bir öncelik numarası yeniden atar. Bu davranış XLSX motorunun 2.196 sürümünde gönderildi ve devre dışı bırakma ayarı olmadan otomatik olarak çalışır. Tetikleyici dardır ama yaygındır: kendi aralığına göreli bir hücre okuyan formülüne sahip bir cellIs veya expression kuralı, daha sonra tam olarak o aralığın ortasında bir yerde bir satır eklenen veya kaldırılan bir çalışma sayfasında yaşar
Excel otomasyonu üzerine çoğu yazı, formül metni sorununda durur: her SUM() ve her VLOOKUP() içindeki satır ve sütun numaralarını, referanslar hâlâ doğru hücreleri işaret edecek şekilde kaydır. Hikayenin bu yarısı gerçektir ve HotXLS'in satırlar ve sütunlar hareket ettiğinde formül referanslarını nasıl yeniden yazdığı üzerine tamamlayıcı makalede ele alınmıştır, ancak bir koşullu biçim veya veri doğrulama kuralı yalnızca bir hücrede oturan bir formül değildir. ECMA-376 terimleriyle sqref, bir formülü bir aralıkla eşleştirir ve ikisinin birlikte hareket etmesi gerekir. Yapısal bir düzenleme bu aralığı, doğru kalmak için iki farklı göreli ofsete ihtiyaç duyacak iki parçaya kestiğinde, tek bir formül dizesiyle tek bir kural nesnesini tutmak bir seçenek olmaktan çıkar ve aksini varsaymak, bir vurgulama kuralının sessizce yanlış satırları karşılaştırmaya başlamasının yoludur
Bir satır eklemek neden yalnızca taşımak yerine bir koşullu biçimlendirme kuralını böler?
Bir koşullu biçim veya veri doğrulama kuralı, tüm aralığı için tam olarak bir formül tutar; bu formül tek bir sabitleme hücresine göre değerlendirilir; bu yüzden bir düzenleme o aralığın iki parçasının iki farklı göreli ofsete ihtiyaç duymasını zorladığında, tek bir formül her iki parçayı doğru şekilde tanımlayamaz olur. ECMA-376, bir kuralın kapsamını conditionalFormatting veya dataValidation öğesindeki sqref özniteliği olarak ifade eder ve Excel, Formula1 ve Formula2'yi metin sanki o sqref'in sol üst hücresine yazılmış ve geri kalanına doldurulmuş gibi değerlendirir — sıradan bir göreli formülün bir sütunu aşağı doldurmasıyla aynı şekilde. B2:B50 üzerinde, bütçesini aşan herhangi bir gerçek rakamı işaretleyen, Formula1'i literal metin C2 olan bir cellIs kuralı olarak inşa edilmiş bir sapma vurgulaması hayal edin — geçerli satırın B hücresini aynı satırın C hücresiyle karşılaştır anlamına gelir
Idx := Sheet.AddConditionalFormat('B2:B50', xlsxCfOpGreaterThan, 'C2');
Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($FFFFC7CE);
Sheet.InsertRows(25, 1); // one blank separator row, starting at old row 25Eski satır 25'te bu tek boş ayırıcı satırı ekleyin ve ekleme noktasının üstündeki satırlar hareket etmez; bu yüzden kuralın onlara düşen payı hâlâ Formula1'i doğru olarak C2 okur. Eskiden 25 ile 50 arasında olan satırlar 26 ile 51'e kayar ve onlar için C2 artık tamamen yanlış bir hücredir, çünkü satır 26'nın kendisinin iki düzine satır üstündeki bir bütçe rakamına değil, C26'ya karşı karşılaştırma yapması gerekir
HotXLS bir kuralın bölünmesi gerekip gerekmediğine nasıl karar verir
HotXLS yalnızca geometri gerçekten gerektirdiğinde ek kural nesneleri oluşturur: dahili bir yordam olan XlsxBuildShiftedRuleParts, kuralın sqref'indeki her ayrık alanı gezer, o alanın sabitleme hücresinin düzenlemeden önce ne olduğunu ve sonra ne olacağını hesaplar ve ortaya çıkan her parçanın aynı göreli ofset düzeltmesine ihtiyaç duyup duymayacağını kontrol eder. Tüm parçalar uyuşuyorsa, tek bir kural hayatta kalır, sqref'i kaydırılmış parçaların birleşimi olarak yeniden inşa edilir ve formülü bir kez yeniden temellendirilir. Gerçek bir bölünme yalnızca parçalar uyuşmadığında olur — tam olarak yukarıdaki B2:B50 durumu — burada üst blok orijinal sabitleyicisini korur ve alt blok yeni birine ihtiyaç duyar
Bir parçanın formülünü yeniden temellendirmek, HotXLS'in OOXML paylaşılan formül grupları için zaten taşıdığı makineyi yeniden kullanan iki adımlı bir harekettir: önce formül, sanki o parçanın kendi sol üst hücresine sabitlenmiş gibi çevrilir — paylaşılan bir formülü kendi aralığı boyunca genişleten aynı göreli ofset matematiği kullanılarak — ardından sonuç, sıradan çalışma sayfası formüllerini yeniden yazan aynı satır ve sütun kaydırma tarayıcısından geçer. Formula1'in C2'den C26'ya, tek yazılmış özel bir durumla değil de iki hareketle nasıl gittiği budur: C2'yi 23 satır ileri çevirerek C25'i elde et, sanki kural her zaman orada başlamış gibi, ardından satır 25'teki sıradan kaydırmanın onu C26'ya itmesine izin ver. Dolgu rengi, doğruysa-durdur, operatörün kendisi gibi diğer her özellik, değişmeden yeni kural nesnesine biner; bu yüzden her iki yarı da hücreleri her zaman boyadıkları renkte boyamaya devam eder
// ConditionalFormats now holds two rules instead of one:
// B2:B25 Formula1 = 'C2' (rows above the insert)
// B26:B51 Formula1 = 'C26' (rows that shifted down)Veri çubukları ve simge kümeleri cellIs kuralları ile aynı şekilde bölünür mü?
Hayır: HotXLS yalnızca doğruluğu gerçekten bölge başına göreli bir formüle bağlı olan kural türlerini — cellIs karşılaştırmaları ve expression kuralları — bölümlere ayırır ve diğer her koşullu biçim türünü, sqref'i basitçe kaydırılmış parçaları çok bölgeli bir birleşim olarak kapsayacak şekilde büyüyen tek bir kural nesnesi olarak bırakır. Dahili olarak dal, sade bir Kind kontrolüdür, cf.Kind in [cfkCellIs, cfkExpression], bundan daha egzotik bir şey değil. Veri çubukları, iki ve üç renkli ölçekler, simge kümeleri, üst ve alt sıralamalar, ve yinelenen, boş ve hata dedektörleri, hücre başına göreli bir karşılaştırma yerine tüm kapsanan aralığı bir kerede tanımlayan bir yük — bir çubuk rengi, bir dizi ölçek durağı, bir simge ailesi — taşır; bu yüzden onları birkaç önceliklendirilmiş kural nesnesine bölmek herhangi bir doğruluk kazandırmaz ve yalnızca yönetilecek kurallar ekler. Bir düzenleme aralıklarını böldüğünde, HotXLS parçaları çok bölgeli bir sqref ile tek bir kural haline yeniden birleştirir ve yükü, parça başına yeni bir kural nesnesi klonlamak yerine tek bir birim olarak yeniden sabitler. Bu ayrım, koşullu biçimlendirme ve zengin metin temelleri makalesindeki kural türü taksonomisiyle uyumludur: veri çubukları, renk ölçekleri ve simge kümeleri, Style özelliğini tamamen görmezden gelerek zaten cellIs kurallarından ayrılır ve şimdi görünüyor ki aynı altta yatan nedenle bölge başına yeniden sabitlemeden de ayrılıyorlar
Yapısal bir düzenlemeden sonra kural öncelikleri neden değişir?
Öncelikler değişir çünkü her klon, bölündüğü kuralla tam olarak aynı öncelik değerini tutarak başlar ve HotXLS ardından, iki kuralı aynı sırada bağlı bırakmak yerine ortaya çıkan yinelenenleri temiz, boşluksuz bir sıralamaya çözen bir normalleştirme geçişi çalıştırır. İkinci bir dahili yordam olan XlsxNormalizeConditionalFormatPriorities, her koşullu biçimin geçerli önceliğini alır, açıkça hiç ayarlanmamış herhangi bir kural için o kuralın koleksiyondaki konumuna geri döner, bağların orijinal göreli sırasını korumak için tüm listeyi kararlı şekilde sıralar ve sıralanan sonucu boşluksuz ve tekrarsız yoğun bir 1, 2, 3 dizisine yeniden numaralandırır. HotPDF bunu bir kaydırma başlamadan önce bir kez çalıştırır; böylece klonlama temiz bir taban çizgisinden başlar, ve her bölünmeden ve her boşaltılan kural kaldırıldıktan sonra tekrar çalıştırır; böylece kaydedilen dosya asla aynı önceliği iddia eden iki kural girdisine sahip olmaz. Koşullu biçimlendirme temelleri makalesindeki, sonraki bir kuralın geri kalanını yeniden numaralandırmadan yerleşebilmesi için öncelik değerleri arasında boşluk bırakma tavsiyesini izlediyseniz bu önem taşır: boşluklar, o çalışma sayfasına dokunan bir sonraki satır veya sütun düzenlemesine kadar hayatta kalır, sonra çöker, çünkü normalleştirme yalnızca benzersizliği ve kararlı sırayı garanti eder, orijinal numaralandırma şemanızın değişmeden geri geldiğini garanti etmez
Veri doğrulama kuralları da yeniden numaralandırılacak bir önceliği olmadan bölünür
Veri doğrulama kuralları, cellIs ve expression koşullu biçimleriyle aynı aralık bölümleme mantığından geçer ve koşullu biçimlendirmenin aksine, her doğrulama türü bu yolu tekdüze alır: HotXLS'in veri doğrulaması için, veri çubukları ve simge kümelerinin koşullu biçimlendirme için olduğu gibi ayrı bir formül dışı ailesi yoktur; bu yüzden sade bir liste veya tam sayı kuralı, göreli bir özel formülü ele alan aynı yordam tarafından bölümlenir. Farklı olan önceliktir: ECMA-376, dataValidation öğesine hiç priority özniteliği vermez; bu yüzden koşullu biçimler için olduğu gibi doğrulamalar için de yeniden numaralandırma adımı yoktur. Her satırın gerçek tutarının yanındaki sütundaki kendi bütçesini aşmasını engelleyen özel formüllü bir doğrulama hayal edin
Sheet.AddCustomValidation('D2:D400', 'D2<=C2');
Sheet.DeleteRows(150, 5); // remove five rows out of the validated range
// DataValidations now holds two rules instead of one:
// D2:D149 Formula1 = 'D2<=C2' (rows above the deletion)
// D150:D395 Formula1 = 'D150<=C150' (rows that shifted up)Bu, veri doğrulama temelleri makalesinin satır sayısı kesinleşmeden bir kural eklemeye karşı uyardığı aynı nedenle önem taşır: bir doğrulama yalnızca ona verdiğiniz literal hücreleri kapsar ve daha sonraki bir yapısal düzenleme, birinin eskiden yaptığı işi yapan iki veya daha fazla kural bırakabilir. İşlevsel olarak hiçbir şey bozulmaz: orijinal aralıktaki her hücre hâlâ bir şey tarafından doğrulanır, ancak sütun başına bir DataValidations girdisi varsayan kod, ona dokunan ilk düzenlemeden sonra yanlış dizinlemeye başlar. Bunun ne kadar ileri gidebileceğine dair sert bir tavan vardır: bölünme bir çalışma sayfasını 65.534 veri doğrulama kuralının ötesine iterse, HotXLS Excel'in sessizce reddedeceği bir dosya yazmak yerine bir istisna fırlatır; bu, sıradan kullanımın muhtemelen ulaşacağı bir sınır yerine kütüphanenin bozuk bir çalışma kitabı üretmeyi reddetmesidir
Toplu bir ekleme veya silmeden sonra ne kontrol edilmeli
Bir betiğin koşullu biçimler ve doğrulamalarla dolu bir sayfa üzerinde bir dizi satır veya sütun düzenlemesi çalıştırmasından sonra doğrulamaya değer iki şey, toplam kural sayısı ve öncelik sırasıdır; çünkü her ikisi de kod incelemesinde gözden kaçırılması kolay ve birisi Excel'de Kuralları Yönet'i açtığı anda belirgin olan şekillerde kayabilir. Tek bir düzenleme nadiren çok zarar verir: tek bir cellIs kuralının ortasına tek bir ekleme, bir olan yerde en fazla iki kural nesnesi üretir. Risk, bir rapor oluşturma yordamı zaten birkaç formül-sabitlenmiş kural taşıyan bir sayfa üzerinde bir döngüde satırları birer birer eklediğinde katlanır: her geçiş, önceki bir geçişin zaten böldüğü kuralları yeniden bölebilir ve beş orijinal cellIs kuralı, orijinal aralığın dilimlerini kapsayan bundan birkaç kat fazla düşük değerli parça olarak sonuçlanabilir. Yapısal düzenlemeleri toplu yapmak — yeni bloğun tamamını bir seferde bir satır yerine tek bir çağrıda eklemek — kural sayısını gerçekleştirilen düzenleme sayısı yerine gerçekten farklı sabitleyicilerin sayısına bağlı tutar
Kural bölümleme ve öncelik normalleştirme, Delphi ve C++Builder için HotXLS Delphi Excel Bileşeni'ndeki XLSX motorunun standart davranışı olarak gönderilir; ürün sayfası, burada anlatılan koşullu biçimlendirme ve veri doğrulama yöntemleri dahil tam çalışma sayfası düzenleme API referansını taşır