Příspěvky uživatele

Princip, jak to navrhuje elninoslov, plně akceptuji. Jen bych jinak hledal místo pro vzorec. Když bude tabulka začínat v buňce LHRoh, pak lze polohu pro umístění vzorce určit

Radek = LHRoh.CurrentRegion.Rows.Count + 1
Sloupec = LHRoh.CurrentRegion.Columns.Count

a buňku volat

Cells(Radek, Sloupec)

Bez VBA mne nenapadá nic. Pomocí VBA by to snadno zvládla kombinace události Worksheet.SelectionChange např. s TextBoxem, Který by událost plnila a také zobrazovala/skrývala. Něco takového už jsem dělal a dopadlo to uživatelsky přívětivě.

Přístup do zavřeného sešitu je velká benevolence od Excelu. Podle všeho, co vím, jde výhradně o přístup Read Only k hodnotám buněk. Žádné jiné aktivity uvnitř zavřeného sešitu podle mne provádět nelze. Umíte si představit, jak by se mohli na vašich zavřených sešitech vyskotačit různí vtipálkové?

Rada na přejímání podmíněného formátu zpravidla zní tak, že přijímající buňka má zopakovat testy ze zdrojového podmíněného formátu (nikoliv celý zdrojový podmíněný formát) a podle jejich výsledu nastavit svůj vlastní formát. Je to nepoměrně jednodušší, než rozluštit samo podmíněné formátování. Pro XP jsem se o to kdysi pokusil. S novými možnostmi podmíněného formátování E-2007 už jsem to už ani nezkoušel.
Druhá možnost je místo podmíněného formátování použít událost Change a měnit barvy přímo v buňce. Pak mohu metodou Copy přenést buňku i s jejím naformátováním. Znám lidi, kteří podmíněné formátování obcházejí právě tímto způsobem.

Většinou lidem nevadí chytit spodní pravý úchyt a táhnout. Samozřejmě to jde udělat jedním příkazem pomocí VBA a ani se na to nemusí psát makro. A když makro napíšu, mohou se vzorce v celé oblasti měnit dynamicky podle algoritmu. Jde jen o to, k čemu má ta změna sloužit (kromě toho, že se v buňkách asi změní výsledky).

to DAAL:
dík za čerstvý vítr do stojatých vod VBA/VBE. O VSTO už pár let vím, na stole v knihovničce mi po léta tiše odpočívá knížka o VisualBasic.NET. Nikdy jsem se ale nedostal do stavu aktivní nouze s VBA, abych se na VSTO vrhl jak studiem, tak nákupem SW. Mám pocit, že už bych se výsledků vloženého úsilí u sebe nedožil.
Sám za sebe říkám, že už to s VBA doklepu. Mám pár aplikací pro natěšené zákazníky rozdělaných a když k tomu připočtu provoz tady na fóru, opravdu se nenudím.
DAAL je v tom směru daal :-). Je to dobře a je taky dobře, že tady potkávám ctitele VSTO.

Na přímou otázku přímá odpověď: takhle to podle mne nejde. Protože ale v Excelu je možné skoro všechno, určitě by to šlo obelstít oklikou přes VBA. Jde o to, jestli to za to stojí...

Jen drobný doplněk ke správné odpovědi:
Obecně platí, že funkce listu vyhodnocují hodnoty jiných buněk bez ohledu na to, jakým způsobem vznikly. Je jedno, jestli jde o vloženou konstantu nebo o výsledek výpočtu podle vloženého vzorce.

Tabulkové procesory jako takové vždycky sloužily pro operativní zpracování dat a jejich pružnost při experimentování s daty patří k základním znakům tohoto prostředí. Zabudování vzorců do tabulkových procesorů umožnilo automatizaci výpočtů výsledků při měnících se hodnotách vstupů. Makra, bez kterých dnes neexistuje snad žádný tabulkový procesor, umožnila provádět opakovaně stanovené sledy úkonů v tabulkovém procesoru.
VBA umožňuje nejen makra vytvářet, ale realizovat daleko složitější konstrukce nad daty, které se mohou chovat jako ucelený nástroj k obsluze celých agend. Takovým nástrojům se zpravidla říká aplikace. Lze si postavit otázku, zda je Excel vhodným prostředím pro tvorbu aplikací.
Je mnoho důvodů prohlásit, že není. Excel není datově bezpečné prostředí a nemá dostatečné vybavení pro skutečnou ochranu dat. Ochrany v Excelu jsou určeny pouze k tomu, aby k narušení dat nemohlo dojít náhodně a nechtěně. Excel rovněž není nejvhodnějším místem pro ukládání dat. A nakonec, Excel není ani tím nejrychlejším prostředkem pro zpracování dat. Jeho doménou je pružnost a snadnost práce s daty.
Ať se to komu líbí nebo ne, Excel je přesto prostředím, ve kterém aplikace vznikají jako houby po dešti. Děje se tak už dlouhé roky a pokud se nenaplní některé katastrofické scénáře, nebude se tento proud nových aplikací ztenčovat. Tak to pochopil i J.Walkenbach, zvaný Mr.Spreadsheet, který věnuje ve své monografii o Excelu přímo tvorbě aplikací několik desítek stran velmi výživného textu.
Důležitá je totiž praxe. Kdyby neexistovala po těchto aplikacích poptávka, nevznikaly by. Kdyby nebyla poptávka, vyschly by zdroje příjmů pro armádu lidí, kteří je tvoří. Existují velké světové agentury, které soustřeďují poptávku po nich a které vývojářům v tvrdém konkurenčním prostředí umožňují vydělávat si nemalé peníze jejich tvorbou. Rozhoduje rychlost a kvalita odvedené práce. Je známo, že jsou to zejména Indové, kteří na poli excelských aplikací představují absolutní špičku kvality.
Nemá význam vést teoretické polemiky o vhodnosti prostředí Excelu pro tvorbu aplikací. Existuje jejich rozvinutý trh z významnou a trvalou poptávkou i velmi silnou vývojářskou základnou. A to bez ohledu na to, jak je takovému stavu nakloněn Microsoft. Jen mne lehce překvapuje, že tuto skutečnost lépe nereflektuje.

Máte plnou pravdu, že zavedených pohledů na Excel bude mnoho podle toho, jaká profese se na něj dívá. Vcelku dobře to strukturuje např. Walkenbach, když charakterizuje oblasti profesí, kterým může Excel sloužit včetně odpovídajících technik řešení. Výbornou stať na téma psaní profesionálních aplikací v Excelu jsem četl z pera J.Číhaře (zkusil jsem ji najít na jeho Dataspectru, ale nenašel jsem ji).
Sám nejsem typický vývojář pro Excel. Pracuji sám na volné noze a nemám zázemí v nákupu nového softwaru. Co si chci pořídit, na to si musím vydělat.
Koncept společné vývojové základny a spolupráce členů MS Office mne před 17 lety nadchly. Žít 17 let z jednoho hrnce kdysi skvělé polévky je ale opravdu trochu nad poměry giganta typu Microsoft.
Mým snem o Excelu budoucnosti byla představa provozně-vývojového prostředí, kde by bylo možné věci zkoušet, vyvíjet a ladit, abych na závěr mohl vyvinuté dílo řádně zkompilovat do .EXE formy a v ní ho předat uživateli k provozování. Výsledná aplikace by měla být zcela oproštěná od prvků pro experimentování a měla by být plně podřízena logice, kterou do ní vloží vývojář. Léta jsem doufal, že tímto směrem má Excel namířeno. Nestalo se to a zřejmě se to ani nestane. Cesta, po které se Microsoft s MS Office vydal, je z mého pohledu velkým krokem stranou místo vpřed.

Ještě jednu věc jsem si uvědomil. Přístup k výběru listů podporují hned dvě místní nabídky: ta známější se otevře po pravém kliknutí na ouška. Tu druhou otevřu pravým kliknutím na posuvníky oušek úplně vlevo vedle oušek. Takže bych měl chytat dva zajíce najednou!

Přece jenom se k tématu vracím. Problém nevhodného výběru listů mne trápí stejně jako to trápí kp57. Tam, kde je to klíčové, tam opravdu ouška schovám a přechod na jiný list řeším dialogem na uživatelském formuláři. Tím mohu omezit výběr na jediný list a získávám prostor pro dodatečné logické vyhodnocení vhodnosti výběru listu.
Dotaz ale podobné řešení hned v úvodu vylučuje. Podle mne tím vylévá vaničku i s dítětem...

Pohled na problém, jak ho vidí DAAL, odpovídá zavedenému pohledu na pozici a význam Excelu ve zpracování dat. S argumentací o makrovirech se všichni uživatelé Excelu léta potkávali na cedulích, kterými Microsoft uváděl a uvádí spouštění sešitů s VBA. Už dávno ty cedule nečtu, takže nevím, jestli se na těch cedulích termín makrovirus pořád ještě nachází, ale o makrech jako o něčem nepravém se na nich jistě mluvit nepřestalo. Moc tomu nerozumím. Připomíná mi to varování hoteliéra, že u nich v hotelu mají štěnice.
Naprosto souhlasím s argumentací o amatérské tvorbě špatných kódů VBA. To je svatá pravda, jako je svatá pravda, že neméně špatnou úroveň mívá i používání vzorců na listech. Zatím jsem téměř vždy rozluštil špatně napsanou proceduru VBA. Přiznám se ale, že řadu vzorečkových propletenců, okořeněných mocnými megavzorci, jsem nedokázal ani zčásti pochopit, natož je rozplést. Špatný řemeslník ohrožuje každé řemeslo, ať se ohání srpem, nebo kladivem...
Naprosto souhlasím, že dlouho nerozvíjené VBA již povážlivě kulhá za dobou. Je ovšem stále integrovanou součástí tabulkového procesoru od Microsoftu. Mohu získat zdarma OpenOffice, placený MS Office se zabudovaným VBA (v ceně), nebo si případně k němu pořídit ještě placenější Visual Studio.
Atmosféra v malých firmách asi bude vždycky nakloněná levnějším řešením zpracování dat. Excel bez VBA je ve srovnání s OO ekonomický nesmysl, protože zadarmo mohu dostat prakticky to samé, co si jinak mohu od MS za slušný peníz koupit. Nevidím důvod proč to dělat, když se dobrovolně vzdám funkčního (i když trochu fousatého) VBE s VBA.
Tady jsme na fóru, věnovaném Excelu. Proto doporučuji, abychom se tady věnovali možnostem, které nám tento nástroj v rámci svých možností nabízí a nevylučovali jsme dopředu jakékoliv jeho schopnosti.

Hledáním v moudrých knihách jsem zjistil:
Místní nabídky jsou obsahem kolekce CommandBars s tím, že jejich typ je msoBarTypePopup. Dostupnost místní nabídky lze nastavit pomocí její vlastnosti Enabled.
Pokusně jsem vypnul všechny své místní nabídky. Ověřil jsem tím, že se místní nabídka na ouškách opravdu přestala zobrazovat. Takže jeden ze zakázaných prvků to byl.
Vypsal jsem si jména zakázaných prvků, kterých bylo 65. Bohužel jsem mezi jmény nenašel žádné takové, které by prozradilo příslušnost k ouškům. Nezbylo, než zkoušet ta nic neříkající. Nakonec jsem objevil CommandBar("Select") s číslem 124, který tu místní nabídku obsluhuje.
Moje hledání bylo ještě delší než moje povídání. Výsledek už je velmi stručný:

CommandBars(124).Enabled = False

To vypadá dobře jen do chvíle, dokud spolu s CTRL neklepnu na ouško. V tom okamžiku zase místní nabídka ožije. To mne otrávilo. Jestli někdo chce v mém zkoumání pokračovat, má možnost. Mně to přestalo bavit...

Podle mých letitých zkušeností má odmítání práce s VBA řadu příčin, z nichž některé pokládám za zástupné. Základní je to, že se sám Microsoft od VBA dost distancuje. Přitom jeho hrozba makroviry mi připomíná varování před yettim v Krkonoších. Dělal jsem průzkum na jiném fóru o střetu s makroviry mezi opravdovými borci z oboru. S výjimkou jednoho deset let starého případu kolem jednoho francouzského sešitu nikdo z nich nikdy na makrovirus v praxi nenarazil. Někteří z oslovených jsou zapojeni do mezinárodního obchodu s aplikacemi, psanými v Excelu a píší své sešity pro kohokoliv na světě, kdo si to zaplatí. Ani oni na makroviry nenarazili.
Z úplně stejného důvodu aplikace s VBA často odmítají někteří manažéři. Jde jen o rozšířený strach z ničeho.
Jiný argument je, že moji aplikaci by mohl chtít používat někdo, kdo nemá Excel (zpravidla jde o vlastníky bezplatného OO. To je lepší argument, ale je otázkou, jestli to je dostatečný důvod k odmítnutí VBA. Podle mne nikoliv, pokud jde o využití "pouze pro čtení". V tom případě existují spolehlivé prostředky, jak takové čtení zajistit.
Při řadě školení jsem se přesvědčil, že značná část těch, kteří VBA odmítali, to dělala proto, že se jim do VBA prostě nepodařilo proniknout. Samozřejmě to nepřiznali a schovali se za veřejně rozšířenou pověru o jeho potenciální škodlivosti. Když se jim otevřela vrátka, silně většinou pookřáli.
Mezi vývojáři v Excelu je jakési skoro tabu o pochopení práce s VBA jenom promluvit. Zdá se, že by to byla hanba, kdyby někdo nevěděl. A tak raději VBA zavrhnou. Znám skvělého "vzorečkáře", který prostě odmítl VBA, protože se odmítl vžít do myšlení programátora. Hodně jsem se od něj o vzorcích naučil. On ode mne z VBA nepochytil nic. Ale to je naprostá výjimka, potvrzující pravidlo.
Pro jedno ze svých dávných školení jsem vytvořil obrázkový návodný text, jak do VBA proniknout alespoň na jeho krajíček. Chtěl jsem ho sem poslat jako přílohu, ale ty obrázky prostě překročily povolenou velikost místních příloh. Spouštěčem pro ten nápad byl dotaz, jak spustit proceduru s parametry z listu. Zkusil jsem tedy ten text předělat, aby se bez obrázků obešel a ještě pořád něco říkal. Nevím, jestli se mi to povedlo. Nevím, jestli to vůbec někdo zkusí číst. Kdyby to ale alespoň jednomu člověku na fóru něco přineslo, budu spokojený.

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje