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