Věřím, že se problém podaří rychle odstranit. Je až neskutečné, kolik let už Microsoft marně válčí s kompatibilitou mezi 32 a 64 bitovým Office. Sám jsem si nikdy 64bitovou verzi Office nenaistaloval a uchránil jsem se tím zřejmě od mnoha nepříjemností.
elCHa mne svým vláknem upozornil, že jsem zřejmě do fóra neposlal poslední verzi svého převodníku. V příloze je verze Transform, napsaná jako klasický doplněk Excelu, jehož funkčnost je rozšířená o možnost nastavení referenční buňky pro zápis R1C1.
Pokud někoho můj převodník zajímá, může si ho nainstalovat.
Doplněk od elCHa pro vzájemný převod mezi českým a slovenským zněním vzorců je jistě vhodnou pomůckou pro předávání vzorců "na papíře". Výskyt slovenského "IF" v textu místo českého "KDYŽ" to dobře dokládá.
Pravda ovšem také je, že jde o důsledek nevhodného předávání vzorců mezi dvěma národními prostředími. Pokud se nechceme dočkat podobných nemilých překvapení, stačí vzorce si předávat přímo na listech sešitu, a ne v textu příspěvku. Když Slovák do svého vzorce na listu napíše "IF", Čech si ho z téhož listu bez jakýchkoliv pomůcek přečte v českém Excelu po svém jako "KDYŽ".
Každá funkční pomůcka je užitečná. Převod vzorců mezi verzemi CZ a SK má zřejmě specifika, která jiné převodníky neumějí provést, a proto si jistě najde své příznivce.
Při citaci mého převodníku se správně konstatuje, že převodník pracuje s interním převodem vlastností Formula a FormulaLocal. Pracuje proto zákonitě s každou lokalizací Excelu, tedy i se slovenskou, vždy ale proti anglickému originálu.
Přímý převod mezi českou a slovenskou mutací můj převodník provést neumí. Tím, že se převodník od elCHa vymyká z klasického převodního schématu mezi originální a lokalizovanou verzí, se právem hlásí o své místo na slunci.
V příloze je nástin řešení
A abych jenom neteoretizoval. V příloze je řešení, které nedělá nic jiného, než že se drží rozumu.
Asi jsem už nejsme normální. Nebo lépe považujeme za nenormální vše, co se odchyluje od pravidel MS nebo jejich lokalizačního týmu.
Říct "takhle ne!", když je něco zjevně blbě, umí každý soudný člověk. Složitější je poradit, jak "jinak". Když jsem řekl "A", zkusím říct i "B".
Kalendářní interval "od - do" je dost obvyklá logická konstrukce, na kterou bývají navázány takové testy, jako "uvnitř intervalu / mimo něj", případně výběr intervalu pro dané datum. Z toho titulu lze na kalendářní interval nahlížet jako na možný "pseudoformát", který lze vybavit potřebným vyhodnocovacím aparátem.
Kategorii pseudoformátů a práci s nimi se věnuje text, který přikládám. Kalendářní interval by se mohl stát jedním z takových pseudoformátů. Jeho použití by pak mohlo zásadním způsobem zjednodušit tazatelovo zadání.
Podle mne by bylo jednodušší napřed vytvořit dpf a ten pak následně tisknout, než napřed tisknout a pak z tisku vytvářet pdf.
Opravdu máte pocit, že tazatel TEho má z téhle diskuse nějaký užitek? Asi by bylo účelné, kdyby se k tomu tazatel vyjádřil...
Pokládám za bezpředmětné zabývat se zadáním, které nesplňuje ani základní zásady pro práci s daty. Vyhodnocováním slepence dvou kalendářních dat to začíná. Jedna, nebo taky dvě mezery za pomlčkou jsou pokračováním o nepochopení práce s daty. A "datum", které má před rokem mezeru, není datum.
Dokonce pokládám za škodlivé s takovými "daty" pracovat dřív, než se do nich vnese alespoň základní pořádek. Fakt, že to člověk očima přečte bez problémů, by neměl být důvodem, abychom Excel nutili k obrábění podobného datového nepodařence. Jen to svádí negramotné uživatele k přesvědčení, že Excel unese cokoliv.
Jako tatar ne, jen s tatarským přízvukem . Chci tomu rozumět tak, že vyplníte řádek v "pokladna-soupis" a chcete tento řádek převést do podoby pokladního dokladu (s využitím vyplněných hodnot z pokladny).
Pro podobné případy používám vyvolání události BeforeRightClick (nebo BeforeDoubleClick) na listu pokladna. Náplní události je přenos údajů z místa vzniku události do listu s dokladem, spojený s fyzickým přechodem na tento list.
Pokuste se o to vlastními silami. Když to nepůjde, zkuste upřesnit, kde jste uvázla, případně co jsem špatně pochopil.
Opravdu jsem měl na mysli to, co použil cmuch1 ve svém kódu. Operátor Like umí kromě "divokých znaků" ? a * i další konstrukce srovnávacího řetězce a významně tak rozšiřuje možnosti testování obsahu řetězců.
Využití schopností Like jsem se pokusil přenést také do oblasti funkcí listu v podobě své UDF ULike(Řetězec;Vzor), jak ji lze najít v doplňku UDFstandard1.
Ani operátor Like ovšem netvoří špici pro práci s neurčitým obsahem řetězce. Tu představují (podle toho, co vím) tzv. regulární výrazy, jejichž knihovnu si lze pro Excel vypůjčit z VBScriptu. Nedávno jsem dokonce objevil UDF, která umožňuje pracovat s regulárními výrazy v rámci funkcí listu. Regulární výrazy jsou ale velmi košaté téma, vyžadující pečlivé nastudování. Znám jen velmi málo příkladů práce s touto strukturou. Já jsem si zatím s možností Like bohatě vystačil.
Opakuje se stejná otázka, na kterou je stále jediná odpověď. Neexistuje rozumná možnost, jak testovat barvu buňky z podmíněného formátování. Jediná rozumná možnost je použít stejnou podmínku, která je použitá pro podmíněné formátování také pro objekt, který se má chovat ve shodě s naformátovanou buňkou. Doufám, že jsem to napsal srozumitelně.
Doporučuji nastudovat práci s operátorem Like, který poskytuje pro úlohy podobného typu velmi účinnou volbou testu.
Bez vyhledávacích funkcí si lze jen obtížně představit inteligentní využití práce s daty v Excelu. Před pár lety jsem napsal animovaný návod pro práci s touto kategorií funkcí. Dávám ji do přílohy,
Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.
Používáte podnikový systém Helios iNuvio? Potřebujete pomoci se správou nebo vyvinout SQL proceduru? Více informací naleznete na stránce Helios iNuvio.