Příspěvky uživatele

To vypadá jako hodně hloupá otázka. Když odpovím, že ano, ale jen zhruba, vyvolám nejspíš dost emocí.
Jako už několikrát v minulosti, obrátila se na mne opět jedna z účetních, která bez Excelu při pomocných rozborech nedá ránu. Napsala si rafinovanou kontrolu dat, završenou testem na shodu křížových součtů. A co čert nechtěl, součty neseděly. Žádné pátrání po chybě nevedlo k cíli. Nakonec paní účetní vzala do ruky kalkulačku a výsledky z Excelu přepočítala. Asi už tušíte, že jí součty klaply. Lhal Excel, když jeho součty neseděly.
Kdo zná základy numerické matematiky, ten ví, že součtem libovolného počtu čísel s omezeným počtem desetinných míst nemůže vzniknout číslo s větším počtem desetinných míst. Takovou zásadu Excel nevyznává a snadno dodá součet zhruba správný, ale o fous jiný, než by se slušelo. Tohle Excel provedl paní účetní a její test shody proto nedopadl, jak dopadnout měl.
Rada nebyla složitá technicky, ale filozoficky. Musel jsem paní účetní sdělit, že Excelu nesmí až tak moc věřit a pokud v něm posčítá hodně čísel, musí výsledek navíc pro sichr zaokrouhlit, aby ho zbavila technických nečistot, které na sebe během sčítání mohly nabalit. Mám bohužel pocit, že jsem v paní účetní vyvolal pocit, že už nemůže věřit vůbec ničemu.
Sám jsem tímto šokem prošel před léty a od té doby si všechny účetnické úlohy převádím do celých čísel ("na haléře") a v nich provádím své výpočty. Teprve hotové výsledky vracím do řádu korun.
Nedávno mne tady na fóru upozornil Lubo na datový typ VBA Currency, na který jsem úplně zapomněl. Testy s tímto typem na přesnost součtu samozřejmě dopadly správně a bez rozostření dat. Nic takového na listu k dispozici není. Takže jinou spolehlivou možnost, než počítání v celých číslech k dosažení přesných hodnot, pro list neznám. Berlička se zaokrouhlováním moc cti Excelu nedělá.

Dík za poznatek, že názvy tabulek nejsou povinné. Vyjmenované akce jsem vyzkoušel, ale nezabraly. Formálně je možnost Odstranit šedá (neaktivní), takže ji nelze vybrat. Pokus o Workbook.Name.Delete chybu nevyvolá, ale neprovede se. Jména tabulek se mi hlásí na úrovni Workbook.

Souhlasit s názorem o chybě je odpověď chytré horákyně. Když už tu chybu Excel přijal, měl ji přijmout důsledně. Ale je to jednou tak a podruhé jinak! To je o stupeň větší bordel než chyba sama! A to je důvod, proč jsem příspěvek poslal. Chtěl jsem upozornit na tuto skutečnost, když už jsem si jí všiml...
A co se týká logického rozsahu položky Date od 1.1.100, tu mám ověřenou a opravdu platí. Má jenom takový háček: dost dobře ji nelze jako datum zobrazit. A navíc to nijak nesouvisí s 29.únorem 1900.
Kdyby to někoho zajímalo, mám k dispozici kalendářní systém s rozsahem plus minus 8 milionů let, který umí juliánský i gregoriánský kalendář a který vadou 29.2.1900 netrpí.

Jako vedlejší produkt algoritmu se mi do Workbook.Names uložily názvy vzniklých tabulek (ListObjects). Tyto názvy pro další použití sešitu nepotřebuji a chci se jich zbavit. Správce názvů se mi ale otevírá se zablokovanou možností Odstranit. Neumím najít příčinu tohoto stavu. Umí mi někdo poradit, co mám udělat, abych mohl názvy zrušit? Nebo je to tak, že ListObject má název ve Workbook.Names povinný? Pak bych alespoň potřeboval dát těm názvům lepší jména. Ani to mi ale nejde.

Slavná chyba Excelu, údajně zděděná z Lotus 1-2-3, pokládá datum 29.2.1900 za existující, i když rok 1900 není přestupný.
Při ladění algoritmu, který pracuje s funkcí VBA Format jsem právě zjistil, že den nula se v ní posunul z 31.12.1899 na 30.12.1899. Zpozorněl jsem a zkusil jsem zadat slavné 29.2.1900. A ejhle! Funkce Format toto datum pokládá za nepřípustné. Den s pořadovým číslem 60 je 28.2.1900, číslo 61 má 1.3.1900. Slavná chyba pro funkci Format neplatí!
Bohužel jsem se radoval jen chvilku. Pro přímé zadání datumu do buňky, naformátované jako "d.mm.rrrr", dál platí, že den 0 je 31.12.1899 a že den 60 je dále neexistující 29.2.1900.
K nápravě fakticky nedošlo, jen Excel má rozostřené vidění prvních 60 dnů v systému 1900. V tomto období numerický formát buňky vidí datum od 31.12.1899 do 29.2.1900, zatímco funkce Format stejné období vidí od 30.12.1899 do 28.2.1900. Počínaje dnem 61 funguje převod na datum shodně a správně pro oba typy zobrazení.
Dodatek: až doteď jsem se domníval, že funkce Format ve VBA a funkce listu HODNOTA.NA.TEXT pracují ve shodě. V případě dne 60 to neplatí! Tento den nadále funkce listu převádí na neexistující 29.2.1900...

Bylo by dobré poslat ukázku toho, co se chová nevhodně. Úplně něco jiného jsou ovládací prvky Excelu a Shapes, ovládací prvky ActiveX a třebas formuláře. Vliv může mít i rozdělení obrazovky příčkami. Jde o pytel blech, pro který je obtížné najít obecnou odpověď. Co se týká přepínání obrazové plochy mezi monitory nebo souběžné zobrazení na dvou monitorech, jde o velmi specifický problém, pro jehož zkoumání má technické vybavení jen málo uživatelů Excelu. Patřím k té nedostatečně vybavené většině...

Souhlasím s elCHa. Jinak si myslím, že Excel se chová v tomto směru vcelku rozumně. Pokud si daný sešit otevřu jako první uživatel a přímo nepovolím sdílení (což bych měl dělat pouze výjimečně), mám k němu jako jediný plná práva. Každý, kdo se o otevření pokusí po mně, má sešit pouze k prohlížení, takže nemůže napáchat žádné škody. Dokud sám sešit nezavřu, do té doby si nikdo další se změnami neškrtne. Je proto otázka, proč bych vůbec měl pokus o takové otevření monitorovat.

Je samozřejmě věcí uživatele, jak chce, aby byla chápána přípustnost a role "nadbytečných" oddělovačů. Po mém soudu by bylo dobré držet se toho, jak jim standardně rozumí Excel. Toto chování si lze snadno ověřit pomocí služby Data / Text do sloupců. Z něj jednoznačně plyne, že počet prvků, do kterých Excel rozdělí text s oddělovači, přesně odpovídá úvodnímu vzorci vlákna, tedy o jeden víc, než je počet oddělovačů. Prvky, vytvořené v rámci této služby "nadbytečnými" oddělovači, vzniknou, jen mají nulovou délku.
Úplně stejně se vůči oddělovačům chová VBA ve své funkci Split, která ze stringu s oddělovači vytváří pole. Dalším příkladem analogického chování je vynechání parametrů v seznamu parametrů pomocí opakování oddělovače.
Odlišné vyhodnocení oddělovačů pro určení počtu prvků je sice možné, bez skutečně vážného důvodu bych ho ale nedoporučoval.
Edit: služba Data / Text do sloupců sice umožňuje volbu "posloupnost oddělovačů jako jeden", jde ale o nastavení, které si musíme vyžádat a které se tím liší od standardu pro vyhodnocení oddělovačů. Aniž bych zkoumal složitější vzorce od elCHa, předpokládám, že směřují k tomuto způsobu vyhodnocení oddělovačů.

To dokážete sám s pomocí makrokamery. Otevřete současně oba sešity, přepněte se do sešitu se zdrojem dat a spusťte makrokameru. Proveďte ručně požadovanou operaci včetně návratu do zdrojového sešitu. Ukončete nahrávání a do zdrojového sešitu přidejte tlačítko, jemuž přidělíte do vlastnosti Makro jméno vygenerované procedury. K provádění kódu z makra bude nutné, aby přijímající sešit byl otevřený (nahrát data do zavřeného sešitu nejde).

Runtime Error 9 je velmi obvyklá chyba a objevuje se vždycky, když chcete z nějaké kolekce použít jejího nedostupného nebo neexistujícího člena. Z kontextu vašeho dotazu to vypadá tak, že chcete na skrytém listu provádět něco takovým způsobem, který vyžaduje, aby list skrytý nebyl. Zcela klasický příklad je pokus o Select buňky na skrytém listu.

Hav-Ran radí jako obvykle správně, ale pro slovenský Excel. Česky se to řekne
=KDYŽ(POČET2(G3:J9);"Je tam něco";"Prázdné")
Zápis využívá toho, že nula v POČET2 se vyhodnotí jako False, nenulová hodnota jako True.

Pokud pomohlo smazání listu a jeho nové vytvoření, pak bych téměř s jistotou nad přírodou zvítězil. Škoda, že jste mi tu legrácku neposlal. Měl bych další dušičku do složky s propojenými sešity a vám by to ušetřilo práci. Na druhé straně bych se nejspíš nedozvěděl žádné novinky o tom, co ještě spravit neumím...

Zase z diskuse vzniká polemika. Dotaz zněl na to, jak dosáhnout, aby v buňce mohl být jak slovenský, tak maďarský tvar měsíce. Domnívám se, že jsem otázku zodpověděl uspokojivě. Krkolomné řešení pro Text řeší, jak anglický text nahradit českým.
O zobrazení roku se dotaz nezmiňuje. Proto jsem mu ani já nevěnoval pozornost. Argument proti funkci Format zní, že pracuje podivně s formátovacími řetězci "y" a "yyy". Za patnáct let práce s Excelem jsem takové formátování nepotkal.
Taková zavádějící polemika je podle mne zbytečná a samoúčelná. Svoje poznatky a názory k problému jsem uvedl a za sebe pokládám další svou účast v tomto vláknu za zbytečnou. Je na tazateli, aby zhodnotil, jestli mu toto vlákno odpovědělo na jeho otázky.

Váš argument pro použití funkce Text zněl, že zápis je "pro uživatele schůdnější". Tak teď nevím...

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje