Problémem každého fóra o Excelu, které poskytuje rady druhým, je situace, kdy nelze odpovědět bez ukázky a ukázku nelze poslat kvůli důvěrnému obsahu sešitu.
V příloze se nachází MixerX, který by měl být schopný popsaný rozpor překlenout. V principu umožňuje nahradit důvěrná data v cílové oblasti náhodně uspořádanými daty ze zdrojové oblasti. MixerX je surový nástroj a neptá se na obsah cílové oblasti. Na druhé straně plně zachovává nastavené vlastnosti buněk v cílové oblasti. Nikdy bychom neměli mixerem míchat jablka s hruškami. Nikdy bychom neměli pro cílovou oblast použít buňky se vzorečky (vzorečky bychom tím nemilosrdně zlikvidovali).
Jinak se mixování meze nekladou. Cílová oblast může mít jiný tvar než ta zdrojová. Podmínkou však je, že cílová oblast nesmí mít víc buněk než má zdroj. Zdrojová oblast může ležet na jiném listě a dokonce v jiném, aktuálně otevřeném sešitě. Přesně to samé platí i o cílové oblasti. Pokud současně otevřu mixer, zdrojový sešit a cílový sešit, mohu data ze zdrojového sešitu pomocí mixeru přenést v náhodném sledu do určené oblasti v cílovém sešitě. Ale také mohu jen promíchat existující data na místě, když zvolím shodnou zdrojovou i cílovou oblast.
Smyslem všeho je získat demonstrační kopii sešitu, jehož funkčnost je nenarušená, ale který obsahuje nezneužitelná data. Takový sešit pak lze s lehkým svědomím prezentovat.
MixerX lze využít i jinak. Všichni víme, že napsaný sešit nelze odzkoušet bez dat. Vymýšlení cvičných dat je manuální nádeničina. Mixer nabízí možnost, jak použít pro tento účel příbuzná data ze svých jiných sešitů. Domnívám se dokonce, že tento způsob využití mixeru je dokonce významnější, než demonstrační modifikace sešitů s důvěrnými daty.
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...
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.