Kétszer kettő néha öt

Kétszer kettő néha öt − szólt a nóta a hasoncímű filmben. No, a szorzásnál kevésbé bonyolult művelet sem mindig stimmel a nagytudású redmondi óriás alkotásában. Esetünkben a 4+3=5 ellentmondást kellene feloldani valahogy…
A vizsgált tartomány (C2:C5) celláinak száma 5, melyek.közül valójában csak 1 cella üres (C2), a többinek csak az értéke üres karakterlánc. Ezt az ÜRES() függvény (E2:E6) is, valamint a nem üres cellák összeszámlálása (H4) is tökéletesen bizonyítja. Mégis, a DARABÜRES() függvény szerint 3 üres cella található a vizsgált tartományban! "Don Corleone, tégy igazságot." ;)


Aki egy kicsit is ismeri a Microsoft sajátságos gondolkozásmódját és megoldásait, ezen az anomálián már egy cseppet sem csodálkozik.
A DARABÜRES() függvény a leírás szerint a megadott tartomány üres celláit számolja meg. Na, itt van a kutya elásva! A megoldást mint oly sokszor, most is a Súgóban találjuk egy szerényen meghúzódó megjegyzés formájában:
A függvény az üres szöveget ("") eredményező képleteket tartalmazó cellákat is figyelembe veszi, de a zérus értéket tartalmazókat nem.
Erről a cseppet sem mellékes körülményről persze a függvény leírása egy szót sem ejt, így aztán a gyanútlan felhasználó, aki jóhiszeműen abból a feltevésből indul ki, hogy a függvény azt csinálja, amit a neve sugall, áldozatul esik a Microsoft fondorlatos ármányának.
A függvény ilyetén viselkedése teljességgel értelmetlen, hiszen az üres karakterláncra történő vizsgálat (="") ugyanerre az eredményre vezet, ugyanakkor a fizikailag üres cellákat csak a kevéssé ismert CELLA() függvénnyel lehet vizsgálni.

Munkafüzet letöltése: 2007+ (xlsx) | 97-2003 (xls)

Hányas vagy? (Reloaded)

Egy korábbi írásban már foglalkoztam azzal, hogyan lehet kiszámítani valakinek a napra pontos életkorát. Lássunk most még egy módszert! A megjegyzések egyikében feltett kérdésre tekintettel kibővítem a lehetőségeket egy további formátummal is.

Van egy függvény az Excelben, amit még a súgó sem tartalmaz:
DÁTUMTÓLIG(kezdő dátum;záró dátum; egység)
A függvény két dátum különbségét számolja ki években, hónapokban vagy napokban. (Jellemző, hogy ez az amúgy kiváló függvény csupán a Lotus 1-2-3-mal való kompatibilitás okán került bele a programba. Úgy látszik, a Microsoft úgy vélte, az ő felhasználói nem méltóak erre az eszközre.)
A függvény részletes leírását magyar nyelven csak a SharePoint szerver kapcsán ismerteti a Microsoft, de ott is hibásan, minthogy magyarra fordították a függvény dátum argumentumait is. Ezekkel az argumentumokkal a függvény a #SZÁM hibaüzenetet eredményezi csupán. A helyes argumentumok tehát Y, M, D, MD, YM és YD. Amennyiben a dátum argumentumokat nem közvetlenül a képletbe írjuk, hanem dinamikusan adjuk meg, úgy nem kell idézőjelek közé tenni őket!

A DÁTUMTÓLIG és a szökőévek
A függvény az YD egység argumentum esetén a kezdő dátum évszáma alapján veszi figyelembe a szökőéveket. Például:

Kezdő dátum Záró dátum Egység Eredmény
2011.02.01 2012.03.01 YD 28
2012.02.01 2013.03.01 YD 29

Életkor: 51 év 11 hónap 4 nap
Ha a fenti formában szeretnénk egyetlen cellában megkapni valakinek a pontos életkorát, akkor − feltételezve, hogy a kezdő dátum a B1, illetve a záró dátum a B2 cellában van − az alábbi képletet kell beírnunk:
="Életkor: "&DÁTUMTÓLIG(B1;B2;"y")&" év " &DÁTUMTÓLIG(B1;B2;"ym")&" hónap "
&DÁTUMTÓLIG(B1;B2;"md")&" nap"
N. B.: A függvény neve angolul DATEDIF().

Fájl letöltése: 2007+ (xlsx) | 97-2003 (xls)

Jótékony melléütés

Alapesetben óriásméretű szóközök alakulhattak ki tömbös szedés (sorkizárás) esetén a kézi sortörés (Shift+Enter) sorában. Első sorban ezért nem is használtam soha kézi sortörést. :'(
Egy véletlen melléütésnek köszönhetem, hogy rájöttem, hogy ha közvetlenül a kézi sortörés elé egy TAB karaktert szúrunk be, akkor kulturáltan a két eljárást egymás mellett alkalmazni! :D
N. B. Ügyelni kell arra, hogy a kézi sortörés eltávolítása esetén a TAB karaktert is törölni kell.

Itt valami nem kerek...

Mielőtt tovább olvasod ezt az írást, kérlek, próbáld felidézni a kerekítéssel kapcsolatos ismereteidet. Megvan? ... OK.
Akkor most gondold át újra, mit is értesz azalatt, hogy valamit lefelé kerekítesz! Megvan? … Remek!


Ha te is arra jutottál, hogy lefelé kerekítés során a kerekítendő számhoz legközelebb eső (megfelelő pontosságú) kisebb vagy egyenlő − azaz a mínusz végtelen felé eső − számot tekintjük az eredménynek, akkor egyetértünk. Ha ezt a Microsoft is így gondolná, nem volna miről írnom. De Billre és csapatára bátran számíthatok, egy ideig még szolgálnak néhány rágni való csonttal.
Matematikai téziseit egészen eldugott helyeken publikálja a Microsoft. Ez alkalommal a súgó az, ahol a kutya el van ásva. Itt tudatják ugyanis a nagyérdeművel, hogy ŐK a lefelé kerekítést úgy értelmezik, hogy az mindig a 0 (nulla) felé történik. Csakhogy ez nem más, mint csonkolás, aminek elvégzésére külön függvény áll rendelkezésre.


A probléma természetesen periferikus, hiszen az eltérés csak negatív számok lefelé kerekítésekor mutatkozik, de ez mit sem változtat azon, hogy a Microsoftnak nem kellene felülbírálnia a matematika szabályait!

Bosszantó egy bug(ris bunkó)…

Amikor az ember fia elakad egy program használatával a munkája során, megpróbál a súgóban megoldást találni problémájára. Így aztán szerfelett bosszantó, amikor pont a súgó tartalmaz hibát!
A Word kínálata a csere funkció lehetőségeit illetően felettébb széleskörűek. Többször eltöprengtem már azon, létezik-e olyan felhasználó, akinek minderre szüksége van, aki ezeket valóban (ki) tudja használni. A lehetőségek tárházának hatékony kiaknázásához logikához és nyelvészethez egyaránt konyítani kell. Én magam ritkán használom a csere funkciót, de − mint az Office mélységei iránt érdeklő ember − szívesen foglalkozom ezzel a területtel is.
Szövegszerkesztés óráimon nem győzöm hangsúlyozni hallgatóimnak azt a szabályt, mely szerint egynél több szóköz soha, semmilyen körülmények között nem állhat egymás után. E hiba javítására a cserénél nincs jobb megoldás a dokumentumkészítés végső stádiumában. Az esetleges elgépelésből származó dupla szóközök javítása laza csuklógyakorlat: cseréljünk minden egymás után álló két szóközt egy szóközre. Erre két lehetőségünk is nyílik:
  • Egy fapados megoldás (működik!)
    A Keresett szöveg mezőbe 2 szóközt, a Csere erre mezőbe pedig 1 szóközt írunk, majd addig nyomogatjuk az Összes cseréje gombot, amíg azt az üzenetet nem kapjuk, hogy 0 csere történt.
  • Egy elegáns megoldás (nem működik!)
    Megfogadva a Súgó tanácsát, bejelöljük a Behelyettesítéssel jelölőnégyzetet, illetve a Keresett szöveg mezőbe a _{2,} karakterláncot (_=szóköz), a Mire cseréli mezőbe pedig egy szóközt írunk. Az Összes cseréje gombra kattintunk, és csiribí…, csiribá…, máris az A Keresett szöveg mező érvénytelen kifejezést tartalmaz. hibaüzenethez jutunk!
Hibás leírás a Súgóban
  • Egy korrigált elegáns megoldás (működik!)
    A fenti hibaüzenet oka, hogy a Súgó magyarításakor nem cserélték le vesszőt a hazai beállításoknak megfelelően. A helyes megoldás a fenti beállítások mellett a pontosvessző használata!
A csere beállításai az egynél több szóköz eltávolításakor

Heuréka! (Reloaded)

Egy korábbi írásomban a billentyűzet használatának előnyei mellett érveltem, és arról írtam, miként lehet a gépelés során felkínált függvénynevet akár néhány karakter beírása után a szerkesztőlécre varázsolni.
Most kaptam egy kérdést: Hogyan lehet a billentyűzetről bevinni az aktuális dátumot egy cellába.
A megoldás olyan mértékig Microsoftos, hogy úgy gondoltam, nem csupán a kérdezőnek válaszolok, hanem a téma megér egy önálló írást is.
Az Excel Súgójának tanúsága szerint a CTRL+SHIFT+: billentyűkombináció beírja a cellába az aktuális időt. Ezzel nincs is semmi baj. Ez működik is a régi (2003-as és korábbi) valamint új verziókban (2007+) egyaránt. Sőt! Működik a cellán állva közvetlenül, a cellában szerkesztő módban (F2) és a szerkesztőlécen is.
A probléma az aktuális dátummal van: a helyzet ebben az esetben már korántsem olyan rózsás, mint az időpont esetében. A működés meglehetősen kaotikus, a telepített verzió, és a csillagok együttállásának a függvénye. A 2003-as és korábbi verziókban ez a funkció csak abban az esetben működik, ha a CTRL+. (pont) billentyűkombinációt a szerkesztőlécen állva nyomjuk le. Erre a Súgó a 2003-as verzió esetében − nagyon helyesen − fel is hívja a figyelmet. A 2007+ verziók esetében azonban egy szó sem esik arról, hogy ne lehetne bárhol megnyomni a CTRL+; (pontosvessző) billentyűkombinációt. Arról most nem beszélek, miért kellett megváltoztatni az esetleg korábbról már megszokott gyorsbillentyű-kombinációt. Csak az ökör következetes, miért lenne akkor a Micorosft az? Azt sem firtatom, hogyan kell vajon egy magyar kódkiosztású billentyűzeten lenyomni a CTRL+; (pontosvessző) billentyűkombinációt, hiszen a pontosvesszőhöz az ALT GR billentyűt is le kell nyomni. Minthogy az ALT GR billentyű egyenértékű a CTRL+ALT (baloldali) billentyűkombinációval, valahogy kezdünk frusztrált állapotba kerülni a dolgok mikéntjét illetően.
Feltétlenül szót érdemel viszont, hogy a Súgóban szereplő billentyűkombináció semmilyen konstelláció esetében sem működik: sem a cellán állva, sem a cellában szerkesztő módban (F2), sem a szerkesztőlécen! Kipróbáltam angol billentyűzettel is, hiszen ott nem kell az ALT GR a pontosvessző leütéséhez: úgy sem működik!

Nem láttam volna persze neki az írásnak, ha csak a Microsoftot akarnám fikázni; van nekem annál jobb dolgom is.
A megoldás pedig, Benevole Lector, aaaaaaaaaaaaaa… −  prrrrrrrrrrrrrrrrrrrrrrr  − tádááááááááá:

CTRL+0 (nulla)

billentyűkombináció, amely − a 2003-as verzióhoz hasonlóan − bármilyen módon működik.

Heuréka!

Korábban is hangot adtam annak a véleményemnek, hogy olyankor, amikor az adatbevitel legfőbb eszköze a billentyűzet, a parancsokat is sokkal gyorsabban lehet onnan kiadni, mintsem egerészni.
Az Excel 2007 óta a szolgáltatások köre azzal a remek lehetőséggel bővült, hogy az egyenlőségjel után beírt karaktereknek megfelelő függvények megjelennek egy legördülő listában. Számomra nagyon hasznos lett volna ez az újítás, ha tudtam volna, hogyan lehet a megfelelő függvénynevet a billentyűzet segítségével kiválasztani a listából.
Nos, örömmel jelentem, lehullt végre a lepel: a TAB billentyű  megnyomásával bírható rá a program arra, hogy a hiányzó karaktereket, sőt, még a függvénynevet követő nyitó zárójelet is beírja a felhasználó helyett.

A felfedezésért ezúton is köszönetemet fejezem ki kedves tanítványomnak, Csillag Dórinak, aki feltárta előttem ezt a nagy titkot.

Okosabb az Excel mint egy ötödikes?

A mai napon lezárult az a három hónapos közvélemény kutatás, ami azt firtatta, mennyi mínusz egy második hatványa. A vélemények megoszlottak, bár a többség (19-en a 26 szavazó közül) úgy véli, a helyes válasz +1. Lehet, hogy tévedek az ötödik elemit illetően − nem emlékszem már pontosan, mikor is tanultuk a műveletek rangsorát −, de nekem határozottan úgy rémlik, a hatványozás megelőzi a négy alapműveletet. A nagy kérdés a következő: miként kell értelmezni a negatív előjelet? Szorzás −1-gyel? Vagy netán kivonásként 0−1^2, csak éppen megspóroljuk a 0 leírását? Akárhogy is, az teljesen egyértelmű, hogy a műveletek közül a hatványozást kell elsőként elvégezni. Ha eddig a felismerésig eljutottál (volna), akkor nem csodálkozol azon sem, hogy a helyes válasz −1. Nézzük, vajon hogyan vélekedik e kérdésben az Excel…
Ha beírtad egy cellába a szükséges képletet, te is tapasztalhatod, hogy a Microsoft sem okosabb azoknál, akik tévesen úgy gondolják, hogy +1 a jó megoldás. Persze magyarázat az van. A Microsoft interpretációjában − miként azt a súgóban a műveletek sorrendjéről szóló részben olvashatjuk − a negatív előjel ellentett képzésének minősül, és mint ilyen minden más műveletet megelőz. Sajátságos felfogás, de hát mi mást várhatunk a redmondi óriástól? Vedd már észre, jóember:
Nem a Microsoft van az Emberiségért, hanem az Emberiség van a Micorosoftért!

Öveket becsatolni!

A Sánta és a Pösze elmegy a Nagy Mágushoz, hogy segítsen rajtuk. A Nagy Mágus így szól a Sántához:
- Sánta! Dobd el mankód!
A Sánta eldobja mankóját. Ezután így szól a Pöszéhez:
- Pösze! Mondjál valamit!
Mire a Pösze:
- Nézd, Nagy Mágusz! Eleszett a Szánta!


Nos, én valami hasonlót ajánlok neked: Ha nem szédülsz a sebességtől, dobd el egered, és használj billentyűkombinációkat! Hidd el nekem, azokban a programokban, ahol az adatbevitel elsődleges eszköze a billentyűzet, sokkal gyorsabban lehet a parancsokat is onnan kiadni.
Gondold csak meg: a munka folyamán a kéz a billentyűzet felett van. Ahhoz, hogy az egérrel adjál ki pl. egy másolás/beillesztés parancs-párost, a) el kell vinned a kezed a billentyűzet fülül az egérhez, b) fel kell nézned a képernyőre, c) valamilyen módszerrel ki kell adnod az egér segítségével a parancsokat, majd d) a művelet befejeztével vissza kell vinned a kezedet a billentyűzet fölé, hogy folytathasd a munkát. Billentyűkombinációk használata esetén mindez lényegesen gyorsabban megy, különösen akkor, ha vakon gépelsz, de legalábbis nincsenek billentyűkezelési problémáid.
Igaz, a billentyűkombinációk megtanulásával némiképp terhelned kell kis szürkeállományodat, de egy idő után meg fogod látni, megéri! Az MS Office súgója minden modulban külön-külön tartalmazza a különböző környezetben használható billentyűkombinációkat. Érdemes egyszer egy kis időt szánni a dologra, és elolvasni a lehetőségeket. Meg fogsz lepődni, milyen gazdag a kínálat. Persze a gyakorlatban csak azokat érdemes megtanulni, amelyeket a napi munkád során valóban gyakran tudod használni. A Word szövegszerkesztőben használható billentyűparancsok listája egy Word dokumentum formájában is könnyedén előállítható egy makró segítségével.

Bár nem az MS Office témakörébe tartozik, de a témával összefüggésben kapcsán mégis megemlítek néhány, a billentyűzettel kapcsolatos dolgot, ami meglepetésemre és sajnálatomra sokak előtt ismeretlen:
1. A billentyűzet alsó sorában találhatók a Windows gombok (kettő is van belőlük). A két gomb teljesen egyenértékű: bármelyiknek a megnyomása megjeleníti a Start menüt (azaz olyan, mintha az egérrel a Start gombra kattintottál volna). Akkor is érdemes használni ezt a billentyűt, ha csak a tálcát szeretnéd megjeleníteni, ha az valami oknál fogva (teljes képernyős alkalmazás, beállítás, stb.) nem látszik. A billentyűk használatával egyenértékű a Ctrl+Esc billentyűkombináció is, ami még az ősidőkből maradt ránk, amikor nem is volt még Windows gomb a billentyűzeten.
2. Cipőt a cipőboltból! − hangozott régen az elmés reklám. Ennek analógiájára tanácsolom én neked, szokd meg: Ha nagy mennyiségű számot kell begépelned (elsősorban az Excelre gondolok), a számbillentyűzeten írd be azokat! Szövegszerkesztés közben viszont egy-egy számnak (pl. dátum, évszám, stb.) a számbillentyűzeten történő bevitele kifejezetten lassítja a munkát, hiszen az is idő, amíg az ember a kezét a billentyűzet alfanumerikus része felől a számbillentyűzetig mozgatja, majd visszaviszi. Az ilyen esetekben ezért éppenséggel a billentyűzet alfanumerikus részét célszerű használni.
Érdemes tudni, hogy a számbillentyűzeten található tizedes billentyű nem feltétlenül a rajta feltüntetett karaktert (magyar billentyűzeten vesszőt) jeleníti meg, hanem a Windows területi beállításai szerint meghatározott tizedes jelet (azaz esetenként pontot).
3. Igen kevesen használják a jobb egérgomb kattintást kiváltó billentyűt a billentyűzet alsó sorának bal oldalán, ami a helyi menü megjelenítését szolgálja. Pedig bizony ez a hasznos kis gomb ötvözi a billentyűzet és a környezetérzékeny helyi menü használatából származó előnyöket, és szerfelett felgyorsítja a munkát.

A Windows és Menü gomb megjelenítése billentyűzetenként változhat


Remélem, ebben az általános témájú írásban is tudtam újat mondani, és remélem azt is, hogy nem esett el a Sánta! :D

Hányas vagy?

Vannak esetek, amikor nem elegendő nagy vonalakban, pusztán a születési év alapján kiszámítani valakinek az életkorát, hanem pontosan tudnunk kell, hogy az illető betöltött-e már egy bizonyos életkort. Ilyen esetek pl. a nagykorúvá válás a 18. életév betöltésével, a mentesülés életkor alapján az idegenforgalmi adó alól, vagy a 70 év felettiek utazási kedveszménye.
Az alábbi írásban több módszert is bemutatok, hogyan tudod a pontos életkort kiszámítani az Excelben.


1. Képlet
Mint tudod, az Excel az 1900. január 1. óta eltelt napok számaként tarja nyilván a dátumokat. Ha a tárgynapi dátumból kivonod a vizsgálni kívánt személy születési dátumát, megkapod, hány napos az illető.
A születési dátumot igény szerint cellahivatkozásként vagy közvetlenül a képletbe írt konstansként egyaránt megadhatod. Ha a feladat az, hogy egy adott napon állapítsuk meg az életkort, és ezt az eredményt konzerváljuk (azaz az életkor ne változzon meg az idő múltával, ha újra megnyitjuk a fájlt), akkor nem szabad a MA() függvénnyel hivatkoznunk a tárgynapi dátumra, hanem csak állandóként adhatjuk meg azt.
Meglepő módon a dátumkonstansokat (szám!) idézőjelek közé kell tenni (szöveg!).
Végezetül már csak évekre kell átszámolnod a napokat, és az eredményt a legközelebbi egész számra kell lefelé kerekítened. No persze ez sem annyira egyszerű ám, mint amilyennek hangzik. A kivitelezés kapcsán már bizony problémákba ütközünk.
Kezdjük azzal, hogy hány napos is egy év? Hát nem itt van már megint az a fránya szökőév. Nos, amennyiben kortársaink életkorát kívánjuk kiszámítani − és mi mást is kívánhatnánk, hiszen az Excel nem képes az 1900. január 1. előtti dátumokat kezelni, kései utódainknak pedig a születési dátuma az, amit nem ismerünk −, nem tévedünk nagyot, ha úgy vesszük, hogy minden negyedik év szökőév, azaz egy év 365,25 napból áll. E lazaságot megengedve kizárólag az 1900-ban születettek esetében tévedünk, hiszen 1900 nem volt szökőév, de ezt az apró malőrt más eljárással sem tudnánk elkerülni, hiszen − mint arról egy korábbi írásban már szó esett − az Excel tévesen szökőévként kezeli az 1900. esztendőt.
Aztán itt van a kerekítés... Mivel a töredék évet nem vehetjük figyelembe, hiszen a beöltött életévek száma érdekel csak bennünket, a kapott eredményt mindenképpen lefelé kell kerekítenünk. Abból adódóan, hogy az életévek esetében csak az egészeket vesszük figyelembe, nem kell a kerekítés mértékével bajlódnunk, elegendő az eredmény egész részét vennünk. E célra az INT() függvénynél nem találunk kézenfekvőbb megoldást.



Életkor kiszámítása képlettel


2. Függvény
Az ATP (Analysis ToolPak) készletben található YEARFRAC() függvény két dátum (kezdő dátum; befejező dátum) közötti napok számát töredék évként fejezi ki. Ha a függvény első argumentumaként a születési dátumot, második argumentumaként pedig a tárgynap dátumát adod meg, máris megkaptad az életkort tizedes szám alakjában. A függvény alkalmazása során is használhatók cellahivatkozások,  dátumkonstansok, illetve a mindenkori tárgynap meghatározásához a MA() függvény.
A nem kívánt tizedesektől a fentebb már említett INT() függvény segítségével tudsz megválni.
A függvény használatának egyetlen problémája, hogy ha egy másik számítógépen nincsen bekapcsolva az ATP, az életkor helyett az #ÉRTÉK hibaüzenettel találja szembe magát a felhasználó.

=INT(YEARFRAC(születési dátum;MA()))

Hol is tartottam?

Bosszankodtál már azon, hogy egy hosszabb dokumentumban ide-oda navigálsz, észreveszel egy gépelési hibát, kijavítod, majd hosszasan keresgéled, hol is tartottál a munkában valójában? Egy bizonyos koron túl ez a bosszúság fokozódik, minthogy az ember emlékezete már nem a régi...

Az ilyen esetekben szerfelett hasznos szolgáltatása a szövegszerkesztő programnak, hogy a Shift+F5 billentyűkombináció megnyomásakor az utolsó szerkesztési ponthoz ugrik a szövegkurzor. Ennek köszönhetően máris folytathatjuk a munkát ott, ahol a ceruza kiesett a kezünkből.
Sőt! A billentyűkombináció ismételgetésére a legutóbbi három szerkesztési pont között rotálódik a beszúrási pont.
Figyelemre méltó, hogy ha az utolsó mentéskor a szövegkurzor egy kijelölt szövegblokknál állt, akkor a dokumentum ismételt megnyitásakor a Shift+F5 billentyűkombináció hatására nem csak az érintett beszúrási ponthoz ugrik, hanem a kijelölést is elvégzi a Word.
Szerkesztési pontnak azok a helyek minősülnek, ahol változás is történt a szövegben. Ha csak pozicionálás történik, akkor azt nem veszi figyelembe a program e tekintetben.

A kérdés már csak az, hogy fogok minderre emlékezni, ha egyszer már arra is képtelen vagyok, hogy megjegyezzem, hol tartottam a mondókámban...

Szökőévek II.

Szökőév volt-e 1900?
Egy korábbi írásomban tisztába kerülhettél a szökőév fogalmával, így most azonnal vágod a helyes választ: NEM!
Nyilván azt is tudod, hogy a szökőévekben a február hónap 29 napos. (Csak a rend kedvéért jegyzem meg, hogy nem február 29., hanem február 24. a szökőnap!) Most nézzük, hogyan vélekedik a minderről az Excel.
Az A1 cellába írd be:: 1900.02.28, majd a kitöltő négyzet segítségével másold a beírt értéket az A3 celláig.
Te is meglepődtél? (Mert én igen.) Február 28. után február 29. következik, azaz − irgalom anyja, ne hagyj el!az Excel szerint 1900 szökőév volt!
A Microsoft egy percig nem tagadja a hibát, sőt, megmagyarázta, mi ennek az oka, illetve miért nem fogja kijavítani azt sohasem. Angolul nem beszélő olvasóimat kisegítem egy helyenként kiegészített, magyarított kivonattal:
A Lotus 1-2-3 táblázatkezelő első megjelenésekor (1983) − helytelenül − szökőévként kezelte 1900-at. Ez az apró tévedés megkönnyítette a szökőévek kezelését a programban, ugyanakkor semmiféle hibát sem eredményezett a dátumműveletek jelentős részében. Ezt a számítási módot vette át a Multiplan (az Excel elődje; 1982), majd az Excel 2.0 (1987) is, ami egyfelől lehetővé tette ugyanannak a dátum sorszámozási módszernek az alkalmazását, másfelől nagyobb kompatibilitást jelentett a Lotus 1-2-3-mal, biztosítva a munkalapoknak a különböző programok közötti mozgatását.
A Microsoft szerint ugyan nem volna lehetetlen a hibát kijavítani, de úgy vélik, a beavatkozás inkább lenne hátrányos, mint előnyös. Véleményük szerint a hibajavítás az alábbi kellemetlen következményekkel járna:
  • Az MS Excel munkalapokon és más dokumentumokban szinte valamennyi dátum egy nappal csökkenne. Az elcsúszás kijavítása tekintélyes idő- és energia ráfordítást igényelne, kiváltképp a dátumokat kezelő képletek tekintetében.
    Bla, bla, bla... Más szavakkal: ez a hibajavítás nem lenne kifizetődő. Tán nem az a dolga a fejlesztő bandának, hogy rengeteg időt és energiát fordítson egy jól működő szoftver előállítására, nem pedig akár egy percet is arra, hogy megmagyarázza, miért nem tudnak egy ismert hibát kijavítani? Szegény Microsoft... Mindjárt megsajnálom őket.
  • Bizonyos függvények, mint például a HÉT.NAPJA(), eltérő értékeket adnának vissza, ami a munkalap függvények helytelen működését eredményezné.
    Miért kellene ennek így lennie, ha valóban hibajavítás történne? Nyilvánvaló, hogy a feladat nem pusztán annyi, hogy törlik azt a fránya február 29-et. Dolgozni is kellene azért a nem kevés pénzért, fiúk!
  • Megszűnne a dátum sorszámozási módszer kompatibilitása az MS Excel, és más, dátumokat kezelő alkalmazások között.
    Hja, a kompatibilitás... Na és mi volna akkor, ha a többi hibásan működő szoftvert is kijavítanák? Úgy tűnik, ez a lehetőség fel sem merül... Egyszerűbb az IBM-re fogni az egészet. Ők tehetnek mindenről, ők cseszték el az egészet az elején! Nem gondolom, hogy bármilyen hiba reprodukálásával kell biztosítani a kompatibilitást egy hibásan működő szoftverrel. A hibajavítás elvégzése esetén lehet, hogy megszűnne a kompatibilitás, ugyanakkor a Microsoft elmondhatná, hogy az ő programja − ellentétben a többiekkel − jól működik! Ez vajon miért nem szempont?
Amennyiben a hibát nem javítják ki, annak mindössze egy következménye marad:
  • A HÉT.NAPJA() függvény hibás eredményt ad vissza az 1900. március 1. előtti időszakra. Tekintettel arra, hogy elenyésző azoknak a felhasználóknak a száma, akik 1900. március 1. előtti dátumokkal dolgoznak, így az ebből adódó probléma meglehetősen ritka. A hiba ráadásul csak abban az esetben jelentkezik, ha az 1900-as dátum rendszert használjuk.
    Valóban elenyésző lehet azoknak a felhasználóknak a száma, akik 1900. március 1. előtti dátumokkal dolgoznak, minthogy az Excel egyáltalában nem képes arra, hogy az 1900. január 1. előtti dátumokat kezelje. Erről az apróságról az érvelés közepette nem tesz említést a drágalátos Microsoft.
    A megoldás: használjuk az 1904-es dátum rendszert, akkor aztán tényleg semmi problémánk nem lehet. Azt bezzeg nem mulasztják el hangsúlyozni, hogy az összes többi századvégi szökőévet (mint pl. 2100) helyesen kezelik. Dicséretes. Csak egy évet kezelnek rosszul, nem az összeset. Legyünk hálásak érte. Milyen kár, hogy nem a távoli jövőt érintő vízióim nyilvántartására szeretném használni a programot...
Ezzel még koránt sincs vége: szó sincs arról, hogy pusztán ez az egy kellemetlen következménye van az eltűnt napnak. De mostanra legyen ennyi elég. Egy későbbi írásban még visszatérek erre a mizériára.

Off topic: Ius murmurandi záradék
Felhasználó Testvérem! Vedd észre, hogy a szoftverfejlesztés nem rólunk, felhasználókról, hanem róluk, a fejlesztőkről és forgalmazókról szól.  A programozók szerint a felhasználó egy idióta, aki képtelen arra, hogy elmondja, mit akar, ezért helyette is neki, szerencsétlen  fejlesztőnek kell gondolkoznia. Neki kell megmondania, hogy a felhasználónak mi a jó, mert az ostoba felhasználó képtelen ezt saját maga eldönteni. Igaz, a programozók nem értenek az adott szakmához (sokszor a sajátjukhoz sem), de úgy vélik, tudnak programot írni. Így jutunk el aztán fokozatosan oda, hogy teljes mértékben kihal az, amit felhasználó barátnak nevezünk. Mert a programozó bizony mindig a legkisebb ellenállás irányába halad. Ha csak teheti, olyan megoldást választ, ami a legrövidebb idő alatt a legkevesebb munkával a legtöbb pénzt hozza. A felhasználó pedig tűrje békével jobbágy sorsát...



Anno Domini

Elgondolkoztál már azon, hogyan lehet egy Word dokumentumban automatikusan megjeleníteni a tárgynapi dátumot? Ha elolvasod ezt az írást, belátod majd, hogy a megoldás korántsem annyira kézenfekvő, mint gondolod...

Dátumot alapvetően kétféleképpen lehet beszúrni: szövegként és mezőként.
A dátum szövegként történő beszúrása olyan, mintha begépeltük volna a karaktereket (utólag nem is lehet megállapítani, hogy milyen módszert alkalmazott a szerző), így többé nem fog megváltozni. Az állandóság tekintetében tehát nincs probléma, viszont a dátum karakterként történő beszúrását csak makróból lehet automatizálni. Minthogy a makrók nem tartoznak jelen oldal keretei közé, így ezzel a lehetőséggel nem is foglalkozom tovább.

A dátum mezőként történő beszúrása esetén azonnal megjelenik a tárgynapi dátum. Ha a dátum mezőt tartalmazó dokumentumot sablonként elmented, az erre alapozott újabb dokumentumokban a mező helyén a tárgynapi dátum automatikusan megjelenik. Ezzel eddig meg is volnánk. Vagy mégsem?
Amennyiben a dátum mezőt keltezés céljára kívánod használni, a dátumot nem szabad mezőként beszúrni, ugyanis ha a későbbiekben ismét megnyitod a dokumentumot, akkor a dátum mező újra és újra frissül, azaz a tárgynapi dátumra módosul, felülírva ezzel az eredeti értéket.
Apró megfigyelésem, hogy amennyiben a dátum mezőt a menüből szúrod be, úgy a Word a {TIME} kódot helyezi el a szövegben, míg ha forróbillentyűt használsz (Alt+Shift+D), akkor a {DATE} kódot alkalmazza a program. A különbség mindössze annyi, hogy  a {DATE} mezőnek vannak kapcsolói is, a {TIME} mezőnek pedig nincsenek.
A két módszer jelentősen eltérő működése is indokolja, hogy a Mezőárnyékolás értéke Mindig legyen (MSO 2003: Eszközök/Beállítások/Megjelenítés; MSO 2007: Office gomb/A Word beállításai/ Speciális/Dokumentumtartalom megjelenítése), így ránézésre is azonnal megállapítható, hogy "kőbe vésett" vagy frissülő dátummal van-e dolgunk. Ezt a beállítást a Word telepítése után rögtön érdemes elvégezni, és többet nem is kell piszkálni.

A dátum frissülésének problémájára a megoldás az, hogy nem a napi dátumot, hanem a dokumentum létrehozásának dátumát kell mezőként beszúrni! A dokumentum létrehozásának dátuma a dokumentum adatlapján, a Statisztika fülön ellenőrizhető utólag. (1. ábra)

1. ábra: A létrehozás dátuma mezőként és az adatlapon

A dátum egyes részei (év, hónap, nap) tetszés szerint formázhatók, akár szét is szedhetők (2. ábra).

2. ábra: Dátumrészletek megjelenítése formázással

De van ám itt még valami! Ha a {DATE} mezőt beágyazod egy {QUOTE} mezőbe (3. ábra), akkor ugyanazt a hatást éred el, mintha a létrehozás dátumát szúrtad volna be mezőként, azaz a dokumentum későbbi megnyitásakor sem változik a dátum.


3. ábra: {QUOTE} mezőbe ágyazott {DATE mező}
A két módszer között akkor van érdemi különbség, ha nem sablont, hanem körlevelet készítesz, és rögzített dátumot szeretnél megjeleníteni. A {CREATEDATE} mező a törzsdokumentum létrehozásának dátumát tartalmazza egyszer s mindenkorra, míg a {QUOTE} mezőbe ágyazott {DATE} mező a körlevél egyesítésének dátumát fogja megjeleníteni. Bár ez a módszer egy árnyalattal bonyolultabb, alkalmazásával mégis megoldható, hogy egy törzsdokumentum automatizált módon tartalmazzon keltezést, azaz az egyesítés dátumát.


Gyakoroló feladat
Készíts egy sablont, amely az élőfej jobb felső sarkában megjeleníti a tárgynapi dátumot. A dátum a későbbiekben többé ne változzon!

Szaporodjatok és sokasodjatok!

A rajzolási segédvonalak (vezetővonalak) nagymértékben megkönnyítik a diákon az alakzatok és objektumok vizuális igazítását. Alapértelmezésben a dia függőleges és vízszintes tengelye jelenik meg, ami egyúttal kijelöli a dia középpontját. is (1. ábra), megkönnyítve ezzel a dia arányainak áttekintését is. A segédvonalak segítségével olyan diaelrendezés is könnyedén kialakítható, amelyeket a program nem tartalmaz előzetesen beépítve. A segédvonalak természetesen nem jelennek meg sem vetítés közben, sem nyomtatáskor.

1. ábra: Alapértelmezett segédvonalak
A segédvonalak a bal egérgomb nyomva tartása közben tetszőleges helyre átvonszolhatók. Az egérmutató helyén megjelenő szám mutatja az aktuális, a középvonaltól mért távolságot (2. ábra). A mozgatás egysége a beállított térköz, de − miként arról egy korábbi írásban már esett szó − az Alt billentyű egyidejű nyomva tartásával akár a rácspontok között is elhelyezhetők a segédvonalak.

2. ábra: Áthelyezett segédvonalak
A segédvonalak nem állíthatók be diánként eltérő módon, így szerfelett bosszantó, ha ilyen igény merül fel. De erre a problémára is van megoldás, ugyanis a segédvonalak szaporíthatók. Egy már létező segédvonalból kiindulva a Ctrl billentyű nyomva tartása mellett további segédvonalak helyezhetők el a dián. Ezzel a módszerrel valamennyi szükséges segédvonal létrehozható és elhelyezhető (3. ábra), és nincs szükség a segédvonalak állandó áthelyezésére. Irányonként legfeljebb 8 segédvonal húzható.
A feleslegessé vált többszörözött segédvonalaktól úgy tudsz megválni, hogy egyszerűen lehúzod őket a diáról.

3. ábra: Többszörözött segédvonalak

A segédvonalak a vizuális igazításon túl akár az objektumok méretének, illetve a köztük lévő távolság mérésére is használhatók. Ha egy segédvonal áthelyezése vagy többszörözése közben nyomva tartod a Shift billentyűt is, akkor az egérmutató helyén megjelenő szám nem a középvonaltól, hanem a kiinduló ponttól, mint nulla ponttól méri a távolságot (4. ábra).

4. ábra: Távolságmérés segédvonallal

A segédbillentyűk kombinálhatók is, így igényeid szerint tetszőlegesen használhatod az Alt+Ctrl (segédvonal többszörözése rácspontok közötti elhelyezéssel a középvonaltól számított távolságméréssel), az Alt+Shift (segédvonal áthelyezése rácspontok közé a kiindulóponttól történő távolságméréssel), a Ctrl+Shift (segédvonal többszörözése rácsponton történő elhelyezéssel a kiindulóponttól történő távolságméréssel), sőt, még az Alt+Ctrl+Shift (segédvonal többszörözése rácspontok közé a kiindulóponttól történő méréssel) billentyűkombinációkat is.

Mennyi 30?

− Gépház! Mennyi?
− 30!
− Mi 30?
− Mi mennyi?


Megfigyelted már azokat a bűvös számokat, amelyek oly "segítőkész" módon jelennek meg az egérmutató mellett, amikor az egérrel állítasz sormagasságot vagy oszlopszélességet az Excelben? De vajon azt tudod-e, hogy melyiket milyen mértékegységben kell értelmezni? Nyomtatásban hány centiméter magas az alapértelmezett sor és hány centiméter széles az alapértelmezett oszlop? Nos, e kérdésekben már nem annyira segítőkész a Microsoft.

Látszólag a bőség zavarával kell megbirkóznunk, minthogy mindkét esetben két különböző szám is látszik. Mind a sormagasság, mind az oszlopszélesség esetében a második (zárójelben lévő) szám mögött valóban fel van tüntetve a mennyiségi egység: képpont (pixel). Előttem ugyanakkor teljes homály fedi, mit is kellene kezdenem ezzel az információval. Munkám során (ide értve a hozzám intézett számtalan kérdés megválaszolását is) soha nem merült még fel olyan igény, hogy az oszlopszélességet vagy sormagasságot képpontban határozzam meg. Tapasztalatom szerint az esetek túlnyomó részében a tartalomhoz igazodó optimális méretet használunk. Precíz méretek beállítására olyankor van szükség, amikor egy papír alapú nyomtatvány pontos képét kell előállítani, ami a kitöltést követően nyomtatásra is kerül, de ilyenkor sem képpontban számol az ember, hanem ostoba európaiként centiméterben. És pontosan ez az, amit a program nem támogat.

A másik − sorrendben első − bűvös számot illetően korántsem ennyire egyszerű a helyzet, mivel a számokat más-más mennyiségi egységben kell értelmezni a sormagasság, illetve az oszlopszélesség tekintetében.

A sormagasság esetében az első érték mennyiségi egysége pont. Ez végképp horrorisztikus.
ad 1: ez a mennyiségi egység legalább annyira haszontalan, mint a képpont. A pont egy tipográfiai mértékegység, a betűméret mennyiségi egysége. A sormagasság tekintetében történő alkalmazása értelmetlen, hiszen az Excel egy bizonyos távolságot tart a betűk alatt és felett, amit a betűméret függvényében számol ki automatikusan. Ennek mértékére − ellentétben a Word táblázattal, ahol ez beállítható − sajnos semmiféle hatásunk nincsen a táblázatkezelő programban.
A betűméret változtatásával a sormagasság is automatikusan és arányosan együtt változik (12→15, 24→30, 72→90), kivéve, ha manuálisan beavatkoztunk, azaz egy konkrét értéket mi magunk adtunk meg. (Ez utóbbi esetben a sormagasság mindaddig nem változik többé a betűméret változásának hatására, amíg ismét vissza nem térünk az automatikus sormagassághoz.)
ad 2: ha pontot, mint mennyiségi egységet hallunk emlegetni, nem árt tisztáznunk, milyen pontról is van szó. Teljes joggal gondolhatnánk, hogy a Didot-féle tipográfiai pontról van szó, de tévedünk. Tévedünk, mert megint azzal az ostoba európai fejünkkel gondolkozunk. Az MS Office programcsalád valamennyi terméke esetében, ahol betűméretet lehet állítani, PostScript pica-pontról van szó.

És végül a nyalóka: az első szám értelmezése az oszlopszélesség esetében. Ekkora kavalkád után szinte meg sem lepődünk azon, hogy egy újabb mennyiségi egységgel, a karakterszámmal van dolgunk. Az érték azt mutatja, hogy hány "n" betű (félkvirt) fér el a cellában a normál stílusban meghatározott betűtípus alkalmazása esetén.
Tekintettel arra, hogy az esetek jelentős részében arányos (proporcionális) betűtípusokat használunk, ez a mennyiségi egység is teljesen haszontalan, hiszen erre az adatra csak aránytalan (rögzített szélességű) fontok esetén lehetne alapozni. Az a tény pedig, hogy az alapértelmezett oszlopszélesség nem egész szám, egyenesen hátborzongató.

|— Csak erős idegzetűeknek! kezdete
A magyarázat a Napnál is világosabb: Az Excelben egy oszlop szélességének alapértéke 8 karakter. A program a normál stílusban megadott betűméret alapján átszámítja ezt az értéket képpontra, majd felkerekíti 8 legközelebbi egész számú többszörösére. (Ez meggyorsítja a képernyőn történő görgetést.) Az általunk látott oszlopszélesség nem más, mint a képpontban számított szélesség visszaszámítása karakterszámra. ("Oh! irgalom atyja ne hagyj el!")
Ez a magyarázata annak a − tizedes értéket is tartalmazó oszlopszélesség alkalmazása esetén olykor tapasztalható − jelenségnek, hogy az Excel nem pontosan azt az oszlopszélességet alkalmazza, amit megadtunk.
← Csak erős idegzetűeknek! vége —|

Az oszlopszélesség esetében − miként a sormagasságnál is − nyilvánvalóan a tartalomhoz igazodunk, űrlapok esetében pedig valamiféle metrikus hosszmértéket szeretnénk használni. Microsoft ősatyánk sajnos ismét nem kegyes hozzánk.

Alapértékek

Betűtípus Betűméret
(pont)
Sormagasság
(pont)
Oszlopszélesség
(karakter)
→| MSO 2003 Arial 10 12,75 8,43
MSO 2007 |→ Calibri 11 15,00 8,43


Gyakorló feladat
Alakíts át egy munkalapot négyzethálóssá. A sorok magassága és az oszlopok szélessége egyaránt 0,5 centiméter legyen! (Remekül lehet rajta amőbázni...)

nemecsek ernő

Ha a Pál utcai fiúk ezt tudták volna, szegény Nemecsek kisbetűkkel írt nevét milyen egyszerűen kijavíthatták volna!
Ha egy szövegrész kijelölését követően megnyomod a Shift+F3 billentyűkombinációt, akkor a szöveg először Nagy Kezdőbetűsre (tulajdonnevek helyesírása), újabb megnyomásás után pedig NAGYBETŰSRE (verzál) változik. A következő megnyomás ismét kisbetűsre alakítja a szöveget.
Ez a gyorsbillentyű a Wordben és a PowerPointban egyaránt működik.
A Microsoft szokásos apró bakija: a menüből kiválasztható Mondatkezdő opció nem szerepel a Shift+F3 nyújtotta lehetőségek között. Hasonlóképp hiányzik a Váltás/vÁLTÁS lehetőség is, bár ez kevésbé problémás, hiszen az okos ember ezt a Caps Lock billentyű akaratlanul bekapcsolt állapotából következő hibát a megfelelő automatikus javítási beállítással könnyedén kiküszöböli.

Dolgozni csak pontosan, szépen...

Bosszankodtál már amiatt, hogy mennyire nagyvonalúan lehet csak tabulátor pozíciókat beállítani a vonalzón?
Nos, íme egy haszontalan apróság. Próbáld ki, mi történik, ha a pozicionálás közben nyomva tartod az Alt billentyűt... Tyűha! Ez aztán a precizitás! Vagy mégsem?
Mint azt a Microsoft esetében megszokhattuk, ez az eszköz sem tökéletes. Mi itt Európában még mindig azt az "ostoba" metrikus mértékegységrendszert használjuk, így általában  (és helyesen) centiméter van beállítva alapértelmezett mértékegységként. A skála finomsága 0,01 hüvelyk (0,0254 cm), függetlenül az alapértelmezett mértékegységtől. Így - bár a pozíciók centiméterben jelennek meg - időnként két-három egység is kimarad a skálán. Ebből  következik,  hogy ha valóban milliméter pontossággal szeretnél tabulátor pozíciókat beállítani, az egyetlen megoldás továbbra is az űrlap marad.
Ha tetszik ez a lehetőség, akkor feltétlenül érdemes tudnod arról, hogy ugyanez a módszer a PowerPointan is működik a vezetővonalak pozicionálása vonatkozásában.

Nyelvi problémák I.

Előfordulhat, hogy a munkahelyeden és odahaza eltérő nyelvi verziót használsz.
Ez bizony sokszor bosszúságot, nem ritkán gondot okoz.
Az Office termékcsalád nemzeti verzióinak készítése során sokféle bakit elkövettek. Ezek egyike, hogy lefordították az Excel függvényneveit is. Szerencsére a különböző nyelvi verziók e tekintetben kompatibilisek, ezzel nincs gond. A probléma akkor jelentkezik, amikor egy angol függvénynévről nem tudod eldönteni, hogy az melyik magyar függvénynév megfelelője, vagy mondjuk az éppen használni kívánt DARAB2 függvényt hogy is hívják angolul...
Ezekben az esetekben jelent nagy segítséget a FUNCS.XLS fájl, ami valamennyi függvénynevet tartalmazza angolul, illetve az adott nemzeti verzió nyelvén is. A fájlt az MS Office program könyvtárában (általában C:\Program Files\Microsoft Office\OfficeNN; ahol NN az adott Office verzió sorszáma\) a ..\1038 mappában találod meg. A fájl nem csak az alapvető munkalap-, hanem az AnalysysToolPak (ATP) és makró függvényeket is tartalmazza. (Ne csodálkozz, hogy olyikról még sosem hallottál, magam is így vagyok ezzel...)
Ha a fájl megnyitásakor engedélyezed a makrók futtatását (közepes vagy alacsony biztonsági szint), akkor olyan kényelmi funkciók is rendelkezésedre állnak, mint a keresés, a függvénynevek rendezése nyelvenként mindkét irányba, valamint a súgó megjelenítése a függvénynéven történő dupla kattintással. (Ez a funkció sajnos nem biztos, hogy működik.)

Szökőévek I.

Mit válaszolnál, ha azt kérném tőled, mondd el a szökőév definícióját?
Bizony tévedsz, ha úgy gondolod, hogy minden néggyel osztható év szökőév!
A helyzet koránt sem ennyire egyszerű. A definíció pontosan így hangzik: szökőév minden olyan év, amely osztható 4-gyel, de nem osztható 100-zal. Kivételt képeznek a 400-zal osztható évszámok, ezek szintén szökőévek. Mindhárom esetben természetesen maradék nélküli osztásról van szó. Amennyiben ezt a számítást nem kívánod fejben elvégezni, írd be a vizsgálni kívánt évszámot az A1 cellába, és az alábbi képletet egy másik cellába:

=HA(VAGY(MARADÉK(A1;400)=0;ÉS(MARADÉK(A1;4)=0;
MARADÉK(A1;100)<>0));"szökőév"; "nem szökőév")

A képlet segítségével könnyen ellenőrizhetjük a fenti definíciót a gyakorlatban: szőkőév volt 1600, 2000, de nem volt az 1700, 1800, 1900!

Csak a tőlem elvárható szőrszálhasogatás kedvéért jegyzem meg, hogy egy további feltételvizsgálattal, vagy adatérvényesítéssel meg kellene oldani a megadott évszám ellenőrzését, azaz, hogy ne lehessen kisebb 1582-nél, minthogy XIII. Gergely pápa ebben az évben hajtotta végre a naptárreformot.

Egy későbbi alkalommal még visszatérek a témára.

Prioritások

Bosszankodtál már azon, hogy megpróbáltad beállítani egy cellára a piros betűszínt, és sehogy nem akart összejönni?
Nos, a jelenség egy lehetséges magyarázata, hogy egyidejűleg több azonos jellegű, de egymástól eltérő formátum is be van állítva a cellára. A különböző lehetőségek meghatárott prioritás szerint érvényesülnek, az erősebb mindig felülírja a gyengébb rangú beállítást. Ha tisztában vagy ezzel a sorrenddel, sok bosszúságtól kímélheted meg magad. Íme a lehetőségek (a leggyengébbtől a legerősebbig):
  1. Felhasználói formázás
  2. Makró
  3. Egyéni számformátum
  4. Feltételes formázás