Příspěvky uživatele
< návrat zpět
Přece jenom jsem se zamyslel nad tím, jestli bych nedokázal rozšířit záběr nástroje na další objekty při odstraňování vzdálených propojení. Ze svých snah jsem dopředu vyloučil externí linky pro grafické a další objekty. Soustředil jsem se na ty vlastnosti, které připouštějí existenci vzorců ve svém obsahu. Z tohoto výběru jsem se nakonec rozhodl řešit otázku vzdálených odkazů pro následující objekty:
buňky na listech; názvy listu i sešitu; ověření; podmíněné formáty; série v samostatných i zabudovaných grafech; pole v KT.
Vznikl mi ovšem hloupý problém: nemám k dispozici sešity s nechtěným propojením pro většinu z vyjmenovaných případů. Nemohu proto ověřit, jestli napsané rutiny opravdu dělají to, co od nich požaduji. Obracím se proto na ty, kteří mají k dispozici sešity s nechtěným propojením, jestli by nebyli ochotni zaslat některé z nich na mou adresu. Já bych získal materiál k testování a vy byste v příznivém případě dostali zpět "uzdravené" sešity. Pokud bude můj testovací proces zdárně ukončen, jsem rozhodnutý nástroj uvolnit pro obecné použití.
Pokud můj první algoritmus počítal pomalu, pak nabízím rychlejší, včetně měření času, abychom se nemuseli dohadovat, co je pomalu, a co rychle. Při nastavení N=20000 celá ta legrace u mne trvala 0,78 sec, pro zadaných 185 záznamů 0,03 sec. Mně to pomalu nepřipadne.
Nějak jsem nepochopil, v čem je problém.
Souhlasím s marjankajem. že bez znalosti smyslu dotazu nelze najít odpověď na něj. Pro sebe jsem dokončil svůj průzkum poznatkem, že pokud objekt Comment zviditelním pomocí Visible=True, zpřístupním tím spřažený objekt Comment.Shape, který má Type=4. Ten objekt je nadále propojený se zdrojovou buňkou, ale mohu s ním nakládat podobně jako s jinými kresbami v kolekci Shapes. Objekty Comment a Comment.Shape tedy mají společný obsah, ale odlišné chování. Nejsem si ale jistý, jak moc tohle pomůže tazateli.
Přece jenom se m podařilo najít nějaký (i když zvláštní) pořádek v chování komentáře. V podstatě pracuje ve dvou módech:
1. Základní mód je ten, jak jeho chování popisuje nápověda, v němž se komentář zobrazí při přechodu kurzoru přes jeho buňku, ale v místě, které nelze nastavit.
2. Při ovládání komentáře pomocí vlastnosti Visible má odlišné chování: ve stavu True se objeví v místě, kam jsme ho předtím umístili a ze kterého můžeme v tomto stavu komentář přemístit jinam. Přepnutím na False se komentář vrátí ke svému klasickému chování.
Buď je tedy komentář trvale zobrazený na místě, které jsme mu sami vybrali, nebo se ukazuje jen při přechodu kurzoru přes buňku, ovšem tam, kde sám chce. Vše závisí na aktuálním stavu vlastnosti Bunka.Comment.Visible.
Teď jsem udělal "objev". Když se má komentář automaticky objevit po najetí kurzoru nad buňku, zobrazí se vždy tak, jak sám chce. To odpovídá mé zkušenosti i příspěvku od xlnc.
Když ale zobrazím komentář pomocí .Visible=True, zobrazí se komentář v místě, kde jsem ho zanechal po posledním přesunu jeho polohy!!! To zase odpovídá tomu, na co přišel marjankaj. Kde si Excel pamatuje tuhle polohu, jsem ale neobjevil. Taky mne nenapadá, jak této možnosti rozumně využít v praxi.
Upozorňuji na významný rozdíl: marjankaj nabízí způsob, jak opravdu hodnotu skrýt (ale zachovat ji). Tak zní téma vlákna. Ostatní odpovědi zápornou hodnotu ruší, jak zní vysvětlení autora dotazu. Přemýšlejte prosím nad tím, na co se ptáte. Na víceznačné dotazy existují víceznačné odpovědi...
Objekt Comment, pokud vím, nemá (a nikdy neměl) žádnou možnost, jak nastavit jeho pevnou polohu vůči buňce, k níž se vztahuje. Před mnoha lety jsem se o to taky marně pokoušel. Dnes jsem se šel podívat do objektového modelu a opravdu jsem tam nenašel nic, čeho by se šlo chytit. To, že při zadávání obsahu komentáře mohu polohu nastavit, vyvolává jen marné iluze...
Je zvláštní, že mi druhý ze dvou lidí, kteří se ozvali, vyčítá stejnou chybu, která ovšem není chybou nabídnuté metody. Kritizované zamíchání dat na místě je jen jednou z nekonečného množství způsobů náhrady dat, kterou moje metoda nabízí. A každý si může volně vybrat, jestli nepoužije jakákoliv jiná typově podobná data s naprosto odlišným obsahem. Záleží jen na posouzení, o jak háklivá data ve zdroji jde. To ovšem může vyhodnotit jen ten, kdo příslušná data obsluhuje.
Pokud by to mělo třiceti až padesáti procentům lidí, postižených nechtěným propojením, přinést pomoc (dopočet do sta procent), pak budu nadmíru spokojený. Jsem si vědomý, že míst, kde se může propojení skrývat, je opravdu velké množství a já zkoumám jen jedno z nich. Takže váš odhad účinnosti pro zaslaný nástroj pokládám za velkou poctu pro něj.
Myslím, že se to stalo každému, kdo někomu něco narychlo vytvořil "ze svých zásob". Něco se zkopíruje, něco se přidá, rychle se zkontroluje, jestli to počítá a pryč s tím, protože kdo rychle dává, dvakrát dává. Lehce ale přitom může dojít k rozčarování, když příjemce takového dárku narazí na zprávu o existujících propojeních, s čímž sám těžko něco udělá.
Klasickou příčinou takového stavu jsou zpravidla vzorce ze zdrojového sešitu, které se odvolávají na jiné listy v rámci svého sešitu. Při jejich kopírování dává Excel přednost odkazu na zdroj před odkazem na listy nově vznikajícího sešitu. Při testování funkčnosti nemusíme poznat nic, protože ty propojovací odkazy najdou zdroj a fungují správně. Jakmile se ale sešit s takovými odkazy od nás odstěhuje, problém je na světě.
V příloze je rutina, která výše uvedený problém odstraňuje tím, že propojovací odkazy ve vzorcích vybrané oblasti "lokalizuje", tj. převádí je na odkazy v rámci svého sešitu. Několikrát už mi tenhle postup vytrhl trn z paty, a to zejména u sešitů, které jsem s popsanou vadou obdržel od jiných. Pokud si na to riziko vzpomenu, proženu tou procedurou své odvozené sešity dřív, než je pustím z ruky. Občas se to vyplatí...
Pokud vím, Excel kolekci Workbook.Colors od verze 2007 přestal aktivně používat a vede ji podstatě jen kvůli kompatibilitě se starým Excelem. Velmi by mne proto překvapilo, kdyby běžný zásah do obsahu sešitu cokoliv změnil na vlastnosti ColorIndex. Rád se ovšem nechám v tom smyslu poučit.
Přece jenom posílám řešení bez KT. Ani ne tak kvůli tomu řešení, ale spíš kvůli návrhu na vhodnější uspořádání tabulky s daty. To nově navržené je menší a přehlednější. Navíc se lépe kontroluje úplnost dat a líp se s ním taky počítá.
Přimlouvám se za kontingenční tabulku. Vzorečkové řešení se SUMIF jsem si napsal, když jsem ověřoval dodržení párovací logiky ON/OFF v datech. Funguje to, ale KT poskytuje vše, co tazatel na začátku požadoval.
To je řešitelná úloha! Pokud v ní budou dodržena logická pravidla o párech ON/OFF, lze ji řešit jak pomocí vzorců, tak samozřejmě i VBA. Zkusím ten druhý postup. Očekávám, že pro řešení pomocí vzorců se najde víc zájemců.
Uživatelské menu
\nMenu
On-line nástroje
Formulář Faktura
Formulář Faktura IV
Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.
RSS nejnovější články