Příspěvky uživatele

Omlouvám se za přestřelku s xlnc. Nevyvolal jsem ji, ale když už jsem byl prohlášen za břídila, měl jsem potřebu reagovat. S Petrem si asi nikdy nepřestaneme okopávat kotníky

.
@ Marjankaj
Vaším návrhem na Vztah As Long to začalo, když jsem to napsal. Proto jsem Vztah počítal jako aritmetický výraz. Zlobilo to, a ani návrat k Vztah As Long nepomohl.
@ elninoslov
obrat Vztah * 1 nic nezlepšil. Teprve Val(Vztah) v kombinaci s Vztah as String zabral. Způsob plnění proměnné Vztah nesehrál žádnou roli. SLÁVA A DÍK !!!
Moje předchozí informace, že k chybě dochází jen pokud na listu Úroky jsou data, byla mylná. Vznikla totiž nevídaná situace, že se program zastavil při chybě výpočtu VLookUp, aniž by došlo ke zprávě o výpočetní chybě. Ale to už je jiný příběh.
Velmi děkuji za konstruktivní nápady a pomoc. Snad zase začnu věřit VLookUpu. Věc jsem mimochodem už včera obešel tím, že místo VLookUp jsem použij konstrukci Select Case přímo v makru.

Buď si paličatej, jak chceš, ale v tom ta chyba nespočívá (i když jde o nepominutelný nesoulad). Vba umí implicitně převádět čísla na texty, takže stringová proměnná by měla převzít číselný výraz jako text. Je pravda, že to není zrovna standardní, ale je to tak. Jiná věc je, že by se ten string nemusel líbit porovnávací tabulce s formátem General. Zjistil jsem ale, že změna naformátování srovnávacího sloupce na text rovněž nezabrala. Tyhle hokus pokusy jsem udělal daleko dřív, než jsem se šel zeptat na fórum. Chyba trvá dál i přes doporučenou změnu!

Synku, to že nakonec jsou testovací hodnoty a výběrové hodnoty pro VLookUp rozdílného typu, je důsledek toho, že jsem se pokoušel hýbat úplně se vším a tohle byl jeden z těch pokusů. Možná Tě to zarazí, ale kupodivu to nezpůsobovalo vůbec nic. Původně byla v tabulce čísla, a tak jsem vytvořil číselnou hodnotu pro testování. Takže v tom rozhodně ta chyba nespočívá. Konvence pro používání proměnných jsem za padesát let programování používal po dobu asi půl roku poté, co jsem se o tom vynálezu dozvěděl. Nepřineslo mi to vůbec nic, a tak jsem toho nechal. Příště místo Rrr použiju Vrr! Skutečné kódy si komentuji dost pečlivě. U desetiřádkového kousku mne to nenapadlo dělat. K mému stylu programování obecně - na Pandoře si ho mnozí pochvalovali jako dobře čtivý.
Na CurrentRegion se spoléhám velmi často a nikdy jsem si o to nerozbil za dvacet let s VBA hubu. A nakonec - co se Ti nelíbí na tom, když ze dvou trojmístných indikátorů udělám jeden šestimístný? Jistě jsem mohl použít spojení řetězců a v tabulce mít číselný text. Smyslem bylo ušetřit na testování!
Dohromady jsi mi toho vytkl spoustu zbytečného a neporadil nic užitečného. Asi máš profesní tik a nutkavou potřebu známkovat. To ale neznamená, že Tě nemám rád. Prostě takový jsi!

Ty vole, Petře, víš, že nejsem programátorskej začátečník. V okně modulu je uvedený text makra. V okně Immediate jsou uvedeny veškeré okamžité hodnoty, které v makru ovlivňují ten VLookUp (včetně hodnot v tabulce, ve které VLookUp hledá).
Nedělá to nic jiného, než že v tabulce účetních souvztažností (v příkladu má jen 6 řádků) hledá, jestli se účetní položka finančně chová jako kladná nebo záporná. Jde samozřejmě o testovací proceduru, která nevede dál, než k zjištěné chybě.
Buď blbnu já, nebo blbne Excel. Rozsuď nás!
Udělal jsem testovací sešit, který obsahuje to nejnutnější. Makro se volá z listu Soupis tlačítkem. Jak jsem přitom zjistil, chyba vznikne pouze tehdy, když už jsou na listu Úroky nějaká data. Zatím netuším proč, ale tím směrem se vydám!

VLookUp jsem použil milionkrát. Teď mi nefunguje v naprosto triviálním makru. Něco dělám blbě, ale nedokážu najít co. Zkusil jsem změnit snad všechno, ale nedaří se mi najít jádro pudla. Obrázek dole snad zachycuje vzniklou situaci dostatečně názorně. Co je špatně???

V mezidobí jsem provedl významné úpravy nástroje, které jeho funkce zpřesnily a rozšířily. Teď piluji ta rozšíření právě proto, aby pak už nebylo nutné volat po doladění. Dělám na tom po chvilkách, když zrovna není nic spěchavějšího. Až budu sám spokojený, dám to do placu. I v současném stavu jsem tu hračku už párkrát použil, abych se vyznal ve změti svých vlastních uvozovek a středníků. Takže mám osobní zájem, aby to běhalo spolehlivě a maximálně názorně.
V úvodní verzi jsem řádkoval výhradně při výskytu středníku. Výskyt dlouhých aritmetických výrazů ve vzorcích mne přiměl, abych takové výrazy také rozkládal do řádků. Pak mi ale vznikalo tolik řádků, že rozklad přestával být přehledný "na výšku". Zvolené kompromisy někdy dopadají přehledně, jindy je to horší. Ve vašem příkladu by odřádkování před +ZPRAVA přehlednosti vzorce opravdu prospělo.
Dík za příklad. Třebas mne inspiruje k vylepšení výstupu.

@ elninoslov
Ten rozklad pro vkládání dlouhých maticových vzorců je velmi cenný a ode mne má potlesk! Zasloužil by si, aby se dostal do manuálů k Excelu, jak je srozumitelně napsaný.

Dík za tipy. Sešit je napsán tak, aby do něj nikdo vlastní objekty typu grafů nebo obrazců nevkládal. Zajímavý tip jsou podmíněné formáty, které mne nenapadly. Pochybuji však, že by se někdo z uživatelů toho sešitu do podobného dobrodružství pouštěl. Možné to ale je!
Hledání pomocí xml je zřejmě správná cesta, ale má své velké "ale". Pokud mám pomocí xml prohledávat konkrétní list, pak těch listů má příslušný sešit v této chvíli celkem 146 a s výjimkou jeho tří VeryHidden listů jsou v podezření všechny ostatní. Tak to je tedy náruč práce!
Zatím jsem zvolil pohodlnější cestu. Kromě vstupní žádosti o řešení otázky propojení nemá to nedostupné propojení žádný vliv na chod sešitu. Nastavil jsem proto sešit do režimu, kdy se sešit ani neptá, ani se nepokouší žádná propojení aktualizovat. Uživatelsky je tak sešit v pohodě.
Samozřejmě jsem jen strčil hlavu do písku, aby problém nebylo vidět, když nikomu neškodí. Věřím, že časem objevím, kde je problém zakletý.

V sešitě, který v kopiích putuje mezi řadou uživatelů, se po řadě měsíců intenzivního využívání náhle objevila žádost na aktivaci propojení. Zdrojový sešit, o který se jedná, opravdu k agendě nepatří a dostal se tam zjevně omylem. Protože se ten zdroj nachází v kolekci LinkSources(xlExcelLinks), hledal jsem ho jako součást odkazu ve vzorcích sešitu. K mému překvapení jsem ho neobjevil. Prohlédl jsem neúspěšně i názvy (Names) a seznam volatelných maker. Kde ještě by se mohl vyskytovat název souboru, který je evidován v kolekci LinkSources(xlExcelLinks)?

Petře, mně tentokrát šlo o ty LinkSources. S tím, že propojení mohou ležet i jinde, jsem se dost obíral a s řadou takových míst si poradit umím. Ale na ty LinkSources jsem si nebyl stavu vzpomenout. Dík za pomoc!

Vzpomínám si, že v objektovém modelu Excelu existují nejméně dvě kolekce s informacemi o propojeních sešitu. Už den se marně pokouším vzpomenout si, jak se jmenují. Pomůže mi někdo?

Zkuste najít inspiraci v přiloženém sešitě!

Nevím, jak pro koho, ale pro mne je toto vlákno velmi výživné. Rozbor chování Names byl pro mne objevný dík příspěvkům od elninoslov a eLCHa.
Obrázek, který si tady stáhlo víc lidí, zpracovává jiný maticový vzorec, než který lze nalézt v sešitě, jejž přiložil elninoslov. Jde o odpověď na dotaz v jiném fóru z 31.1.2018. Ten vzorec v lokálním řádkovém zobrazení zní:
{=--DOSADIT(DOSADIT(ZPRAVA(ZLEVA(A3;DÉLKA(A3)-POZVYHLEDAT(PRAVDA;ČÁST(A3;DÉLKA(A3)+1-ŘÁDEK(A$1:INDEX(A:A;DÉLKA(A3)));1)=" ";0));POZVYHLEDAT(PRAVDA;ČÁST(ZLEVA(A3;DÉLKA(A3)-POZVYHLEDAT(PRAVDA;ČÁST(A3;DÉLKA(A3)+1-ŘÁDEK(A$1:INDEX(A:A;DÉLKA(A3)));1)=" ";0));DÉLKA(ZLEVA(A3;DÉLKA(A3)-POZVYHLEDAT(PRAVDA;ČÁST(A3;DÉLKA(A3)+1-ŘÁDEK(A$1:INDEX(A:A;DÉLKA(A3)));1)=" ";0)))+1-ŘÁDEK(A$1:INDEX(A:A;DÉLKA(ZLEVA(A3;DÉLKA(A3)-POZVYHLEDAT(PRAVDA;ČÁST(A3;DÉLKA(A3)+1-ŘÁDEK(A$1:INDEX(A:A;DÉLKA(A3)));1)=" ";0)))));1)>"9";0)-1);",";"");".";",")}

Posouzení čitelnosti a rozluštitelnosti vzorce nechávám na vás.

Musím přiznat, že pojmenovaný vzorec s "maticovým charakterem" se mi po zavolání opravdu chová jako maticový. Současně platí moje dlouholetá zkušenost, že pojmenované vzorce, které takový charakter nemají, se po zavolání chovají jako běžné nematicové vzorce.
Důvod, proč jsem si maticového chování pojmenovaných vzorců nevšiml, je velmi prostý. Maticové vzorce používám jen zcela výjimečně a vůbec už mne nenapadlo takový vzorec vložit do Name. Teď jsem hledal, jak to docílit a žádný speciální obrat jsem neobjevil. Nenapadlo mne, že není co objevovat, protože se to udělá samo. Nevzpomínám si, že bych o tom v nějakém manuálu našel zmínku.

Vyzkoušel jsem. Vytvořit přímo pojmenovaný maticový vzorec, uložený jako obsah Name, se mi ale nepovedlo. Co ovšem šlo, bylo uložení obsahu vzorce (bez maticového označení) do názvu (např. Honza). Teprve při vložení vzorce do buňky (=Honza) musím tento vzorec potvrdit Ctrl+Shift+Enter, aby se to začalo chovat maticově.
Podobnou možnost využívám i já, aniž bych použil Names. Český obsah budoucího maticového vzorce vytvořím někde ve VBA a následně ho přenesu ve VBA do buňky jako FormulaLocal. Musím ale skončit tím, že ručně pomocí Ctrl+Shift+Enter z toho vzorce udělám vzorec maticový.

Právě ten ruční konec dělá z automatu poloautomat. Tím takové řešení (proti vložení do FormulaArray) je nedotažené. Zatím ale pro maticové vzorce, delší než 255 znaků, neznám lepší možnost.

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje