Příspěvky uživatele

@elCHa:
váš nevraživý vztah k UDF znám - viz polemiku kolem zaokrouhlování. Já naopak pokládám UDF za kulturní způsob řešení pro situace, když vzorec nelze prakticky sestavit, případně když vzorec začne růst nad rozumné meze délky a srozumitelnosti. Jde spíš o věc vkusu, než o racionální postoj. Vzdávat se dopředu použitelných věcí mi nepřipadá rozumné. Pověru o pomalosti UDF já nevyznávám.

Provedl jsem průzkum bojem. Instalovaný jazyk aplikace Excel lze zjistit např. pomocí následující procedury:
Sub X()
Dim objLangSet
Set objLangSet = Application.LanguageSettings
MsgBox objLangSet.LanguageID(msoLanguageIDInstall)
' nápověda - MsoAppLanguageID Enumeration
' CZ - 1029; SK - 1051; HU - 1038
End SubPro potřeby mezinárodního zobrazení jména měsíce v rámci kalendářního data by ale měla stačit následující UDF:
Function DatM(Dat As Date) As String
DatM = Format(Dat, "d/mmmm yyyy")
End Function
Už na úrovni VBA mi tato funkce ukazuje české znění měsíců. Z toho soudím, že v maďarském Excelu to budou maďarské měsíce (obecně znění podle lokalizace). Použití na listu je velmi prosté:
= DatM(B3)
pro 13.5.2016 v buňce B3 se mi zobrazí "13. květen 2016"
To potvrzuje moji úvahu z předchozího příspěvku. Pro dynamické chování UDF je dobré ji doplnit o příkaz Application.Volatile. Naopak není pravda to, co tvrdí nápověda pro funkci VBA Format o náhradních řetězcích "aaaa" pro lokální podobu dne v týdnu a "oooo" pro lokální podobu měsíce. Tyto náhradní řetězce jsou v mém Excelu nefunkční.

Abych nebyl úplný pesimista, mám dva nezávislé algoritmy, pomocí nichž jsem se zatím dokázal vyhrabat ze svých problémů s nechtěným propojením. Problém je v tom, že jsem měl jen málo materiálu k řešení. Proto nemohu objektivně říct, jak jsou ty algoritmy ve skutečnosti účinné. Vhodné příklady proto sbírám a testuji. Jestli se vám na disku povalují podobné "skvosty", zkuste mi je poslat. Zkusil bych (bez záruky) sešity analyzovat a případně je nalezených nevhodných propojení automatizovaně zbavit. Pokud to dokážu, mohu vám pomoci. Pokud ne, budu mít materiál pro možné vylepšení algoritmů.

Na aktivní překladatele bych vzal klacek a hnal bych je od Excelu! V takovém případě bych zkusil na to jít od lesa:
Když mohu použít VBA (což zřejmě tazatel může), naplnil bych vzorce do buněk přes Range.Formula s anglickým formátováním a doufal bych, že Excel z toho dokáže udělat čitelnou FormulaLocal podle konkrétní lokalizace Excelu. Ruku do ohně bych za Excel v tomto případě ale nedal.
Určitě by ale mělo zabrat, kdybych funkci Text s anglickým formátováním vložil do UDF (do uživatelsky definované funkce) a tu pak použil do vzorce na listu. Tohle podle mne projít musí a musí to počítat v každé lokalizaci!

Je to trochu jako s kozu na ledě. jednou napíšete, že máte sdružené buňky v cílovém sešitě, pak zase, že ve zdrojovém sešitě.
Sdružené buňky jsou prostě svině a přinášejí různé problémy. Co kdybyste si dal tu práci a sestavil něco jako ukázku? Dotazy "nevím, co chci a nedám pokoj, dokud to nedostanu" se tu opakují se železnou pravidelností.

Míst, v nichž se může propojení skrývat, je hafo. Nevím, co to znamená "dát zrušit propojení". O žádné podobné automatické službě nevím a mockrát by se opravdu hodila.
Před časem jsem sem poslal řešení, o kterém jsem si myslel, že je dobré a dostatečné. Dozvěděl jsem se o spoustě dalších možností, kde se zrada může skrývat. Přesto si myslím, že alespoň něco je lepší než nic.
Existují borci, kteří se tím problémem zabývají na zakázku. Třebas někoho takového najdete...

Až na několik výjimek platí, že si Excel vzorce na listu pamatuje v nativní podobě anglicky a navíc v notaci R1C1. Z toho plyne drobné kouzlo, že když do listu v českém Excelu vložím české vzorce, Maďarovi se v jeho Excelu moje vzorce zobrazí maďarsky. A obráceně. Komplikace přinášejí zrovna např. formátové literály, do kterých se mohou promítnout lokalizační rozdíly. Je ale pro mne překvapivé, že zrovna řetězec "mmm" maďarský Excel nebere.

Diskuse ve vláknu Úprava SVYHLEDAT Z 31.1.2016 mne inspirovala k rozšíření mé starší procedury na doplněk, který mění obsah seznamu automatických oprav. Zatím mám v doplňku tyto možnosti:
- vkládání reálných znaků Unicode s horními a dolními číselnými indexy (viz výše uvedené vlákno),
- vkládání speciálních znaků z anglické klávesnice bez nutnosti klávesnici přepínat,
- zjednodušené vkládání vybraných stringů (zatím jen ",," na ":" a "m2" na metr čtvereční).
Doplněk umožňuje uvedené skupiny záměn dynamicky aktivovat i deaktivovat. Aktivovaná skupina zůstává k dispozici i po opuštění aplikace Excel při jeho novém zavolání.
Ze zájmu jsem si zkusil ověřit, jestli podobné záměny mohu nastavit pomocí VBA i pro MS Word. Ke svému milému překvapení jsem zjistil, že změny, které jsem nastavil pro Excel, platí i pro Word. Oba nástroje zřejmě používají stejný soubor s nastavenými automatickými opravami. Tato skutečnost je pro mne nová a rozšiřuje význam aktualizací v souboru automatických oprav.
Mám prosbu: pokud by někdo měl náměty na další užitečné úpravy ručních vstupů pomocí automatických oprav, zkuste je dát "do placu". Neměl bych mít problém obecně použitelné záměny do doplňku dodat a následně celý doplněk poskytnout pro obecné použití.

Otázka, kterou klade elninoslov, kdo bude kontrolovat správnost oprav 300 tisíc jmen, představuje sama o sobě problém. Podle mne se to musí rozložit do více kroků. Prvním z nich by podle mne měl být seznam unikátů, extrahovaný z těch 300 tisíc. U takto získaných unikátů by mělo dojít nejspíš k optickému vyhodnocení správnosti jmen (např. postupem, který jsem popsal). Umím si představit, že by tato kontrola proběhla paralelně na dvou místech a redukované seznamy by se následně (tentokrát automaticky) porovnaly, aby vydaly seznam položek, které nebyly nalezeny v obou seznamech současně. Opět by se opticky vyhodnotilo, co se má opravit a co přijmout. Tak by bylo možné postupovat tak dlouho, až bychom získali verifikovaný kompletní výsledek.
Možná existuje kompaktnější řešení, ale i tenhle hybridní postup je realizovatelný řádově v hodinách (nejhůře v desítkách hodin) času.

Koukám, že jsem přílohu nepřiložil. Takže s omluvou posílám přílohu na zvláštním talířku

Stejný problém mne zaskočil, když jsem posílal do Long hodnotu 256*256. Excel je vůl a tu aritmetickou operaci s čísly Integer chce vyhodnotit také jako Integer, a to dřív, než výsledek pošle do Long. Protože to nedokáže, hlásí Overflow. Musel jsem násobit CLng(256)*256, pak jsem teprve uspěl.

Jak zajistit, aby to fungovalo jen pro daný sešit - to bych uměl; seznam literálů pro automatické opravy není problém měnit pomocí VBA. Aby to fungovalo jen pro danou oblast na listu - to opravdu neumím (a ani jsem se o to nepokusil). Pravda je navíc to, že jména jsou opravdu špatný materiál pro každý automat - to už jsem napsal dřív.
Proto v případě jmen zůstávám u druhé poloviny své odpovědi, tj. u legalizační procedury pro použitá jména. Tu jsem již také za sebe doporučil.

Kdysi jsem na přání řešil příklad s automatickým odstraněním jednoznakového překlepu v zadaném literálu (proti seznamu správných zápisů). Odstranění duplicitních sousedních znaků si umím také představit, i když tam pozor na jména jako je Otto, Anna apod.
S kontrolou pravopisu mám velmi dobré zkušenosti a aktivně ji využívám; nevím, proč ji elCHa odmítá.
Musím ale konstatovat, že právě jména jsou velmi problematický materiál pro automatickou nápravu. Již zmíněný Petr/Peter/Pete a kdovíjak ještě je dobrým příkladem špatného zdroje správných podob jména.
Manipulace se znakovými řetězci patří k mým oblíbeným úlohám. U jmen bych ale zůstal u zjištění, že takové jméno ještě neznám. Na uživateli by bylo, jestli jméno opraví, nebo ho naopak přidá do seznamu známých jmen. Tím by jméno "legalizoval" a příště už by prošlo jako známé. Napsat odpovídající proceduru pro naznačený postup by nebylo zas tak obtížné.

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje