Summa summarum, a 16 helyiérték hosszú numerikus adat végét az Excel angolosan levágja – sehol egy warning, egy “micsinálsz-hülye-nem-tudok-ekkorát”, semmi. Ha egy szám (szerinte hibásan) szövegként kerül be egy cellába, azért bezzeg tud zöld warning háromszöggel rinyálni. Ennek a bugnak az az igazi szépsége, hogy VBA kódból elő tudsz állítani egy cellában 16 jegyű numerikus tartalmat úgy, hogy a cella azt az adatot jeleníti meg, amit te beleírtál, DE ugyanakkor nem azzal számol, hanem a lecsapott utolsó digitű változattal! Tegnap ez úgy jött elő, hogy egy SUMIF lookup-hoz használta egy rutin a 16 jegyű számot és mivel volt több olyan cella a SUMIF lookup range-ben, amely 16 jegyű numerikus adatot tartalmazott és az első 15 jegyük megegyezett, a rohadék egy kalap alá vette mindet, dacára a 16. digit különbözőségének. A fent leírt SUMIF hiszti megoldása persze egyszerű – numerikus adat helyett szövegként kell használni a cellában a hosszú numerikus értéket (ehhez elég egy ‘ karakter a cellatartalom elejére, vagy a cellaformátum Text állapotúvá kapcsolása). Nem is ezzel van a baj, hanem a módszerrel, ahogy a drágaságos Office alkalmazás a problémát kezeli. ]]>

A probléma Amennyiben Excel 2007 feletti verziókban úgy akarsz conditional formattingot (=feltételes formázás) létrehozni, hogy az képlettel számolódik és a felhasznált képlet relatív hivatkozást tartalmaz, akkor a VBA engine hibásan az conditional formatting target range-ének első celláját használja fel _abszolút_ címzéssel a kért relatív címzés helyett.

A M$ féle “megoldás“

Ne használj relatív címzést. Köszi. Az nem tudom feltűnt-e az ominózus WORKAROUND írójának, hogy a spreadsheet egyik legnagyobb előnye a relatív címzés használata.

Mindezek után a probléma közérthetőbben, példával

Képzeld el, hogy az a feladat, hogy 15000 cellát kell ugyanazzal a képlettel számoló feltételes formázással ellátnod (a 15000 cella még “öcsi”, bőven tudnak az userek ettől izmosabbat kérni). Nos, eddig ezt megtehetted úgy, hogy az összes cellára kiadtad a formázási utasítást, mostantól azonban szerintük ez úgy fasza, ha egyesével végigiteráltatod egy ciklussal minden egyes cellát és úgy “oldod meg” azt a problémát, amit az agyatlan codereik generáltak (ugyanis Excel 97-Excel 2007 között ez normálisan működött). Lehet találgatni, melyik mennyi időt vesz igénybe… Charles Simonyi agyoncsapná a codereiteket ezért, ha látná, hogy mit műveltek! Van fogalmatok ott Redmondban arról, hogy ezzel mekkora bajt okoztok a már kész VBA alkalmazásokban, amelyek használatánál a szerencsétlen döntéshozók a conditional formatting által vizualizált inputra támaszkodnak? Forr a vérem. Update: pont ez a feladat jött szembe ma az ügyfélnél, gondoltam mérek egyet: 6610 cellán futott le a kétféle conditional formattinggal ugyanaz az algoritmus – íme a futási eredmény hh:mm:ss bontásban, hogy a redmondi srácok is értsék, mekkora szart kavartak. Conditional formatting, range-re alkalmazva: Conditional formatting, ugyanarra a range-re cellánként iterálva: ]]>