Příspěvky uživatele

Včera večer jsem do vlastního vlákna přidal jeden komentář a založil jsem nové vlákno. Dnes ráno jsem zjistil, že pověřený administrátor eLCHa to staré vláno uzavřel a to nové zcela zrušil.
Odvolávám se na podmínky provozování tohoto fóra, které říkají:
"Příspěvky s vulgárními výrazy, warez, spam, komerční reklama a jiné příspěvky, které jsou v rozporu se slušnými mravy budou odstraněny. V krajních případech bude být uživateli udělen BAN."
Ani jeden z mých včerejších příspěvků se žádným způsobem proti citovaným podmínkám neprohřešil. Nové vlákno dokonce obsahovalo originální nástroj, určený k obecnému použití. Dovolávám se toho, aby žádný administrátor nezneužíval svých oprávnění k tomu, aby kohokoliv, kdo dodržuje pravidla hry, vylučoval z komunikace. Zejména ne z důvodu osobních antipatií.
Pokud i tento příspěvek eLCHa zruší, budu nucen použít další kroky pro zajištění práva na svůj svobodný projev.

Tohle je trochu demagogie. Ti, kdo opravdu chtěli pomoci, poradili. Skutečné rady jsem vyzkoušel a taky jsem za ně poděkoval. Ty jsi hodně kritizoval a moc jsi neradil. Zato si to budeš pamatovat. To je dost charakteristický postoj.

Tak nevím, jestli jsem nepřechválil. Je možné, že jsem si něco z vašeho rozboru vyložil blbě. Cesta přes Names mi ale vázne. Nikoliv v tom, že bych tím postupem nedokázal dlouhý maticový vzorec vložit. To šlape. Cesta přes NAMES mi ale zaplevelí vzorec odkazy na jména listu, a navíc nějak zvláštně posouvá relativní adresy ve vzorci. A aby toho nebylo málo, pokud jde o jeden maticový vzorec pro celou oblast buněk, vznikne mi tím postupem extra vzorec pro každou buňku v dané oblasti. Asi to používám v jiném kontextu než vy, protože jinak byste si jistě takových "drobniček" dávno sami všimli.
Zatím jsem tedy musel setrvat u svého postupu, který výše uvedená zvěrstva nedělá, který ale vyžaduje potvrzení importovaného dlouhého maticového vzorce zkratkou Ctrl+Shift+Enter.

Abych pravdu řekl, už jsem to pustil z hlavy. Číselné indikátory pro hledání typu SVYHLEDAT mohou dělat paseku. Věc jsem obešel a sešit už dáno slouží. Ale rád se poučím, když přestaneš známkovat

Když nejsi jedovatý, je s Tebou docela sranda

Jsou věci, které vypadají složitě, ale udělat jdou. A také věci, které vypadají jednoduše, ale vymykají se z rámce logiky úlohy. K nim patří právě ono +1/SVYHLEDAT. Respektovat pořadí významnosti aritmetických operátorů ve výrazu (a řádek dělit podle toho) by znamenalo neskutečnou komplikaci celého posuzovaného analyzátoru.
K mému rozpisu vzorců je vhodné přistupovat trochu s nadhledem, asi jako k záznamníku maker. Udělá černou práci, ale někdy potřebuje ruční doladění. Ovládací prvek RefEdit, který je pro zobrazení vzorce použit, má běžné editovací schopnosti jednoduchého textového editoru. Pokud chci pro publikační účely rozpis vzorce upravit, lze to udělat velmi jednoduše. Dokonce lze změnit i logický obsah vzorce a pak zkontrolovat, jestli jeho obsah bude počítačem dál pokládán za vzorec. Cílem je, aby bylo možné vzorec po úpravách vrátit zpět na zdrojové místo, které bylo pro zobrazení vzorce použito.
V příloze jsou obrázky několika megavzorců, automaticky rozepsaných nejnovější verzí posuzovaného analyzátoru. Při prakticky nekonečné variabilitě zápisu vzorců jde podle mne o poměrně zdařilé rozpisy. Neumím ovšem vyloučit, že někdo dokáže napsat vzorec tak, že jeho rozklad nedopadne dobře. Zatím ale nevím o žádné případné díře do mých necek

@JoKe
Změnil jsem kritérium pro rozdělování řádků, končících středníkem. Místo aritmetického operátoru za funkcí jsem použil aritmetický operátor před jménem funkce. Váš vzorec se v tom případě rozložil následovně (viz příloha). Při přímém zobrazení kódu se totiž deformuje vstupní odsazení řádků.
Vypadá to daleko přirozeněji (i když i na této podobě lze najít mouchy).Možná ještě něco poladím a pak bych to nejspíš dal k obecnému použití. Dík za inspiraci!

@eLCHa
ve xml jsem ten vzdálený odkaz našel na tom nejpravděpodobnějším listu ze 146, i když na dost zvláštním místě zcela na jeho konci. Musím si ale najít nějaký vhodný editor, kde bych lépe viděl logiku xml. V té podobě, jak jsem si to zobrazil, nic rozumně editovat nejde. Každopádně dík, vím kde to leží.

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ý.

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje