Příspěvky uživatele
< návrat zpět
Předpokládám, že mezi těmi, kteří se na toto fórum přicházejí ptát, jsou i lidé, kteří nemají nainstalovanou žádnou podporu pro zipování. Ti mohou jen obtížně předávat přílohy se svými sešity a zkoušejí to např. přes úložiště.
Před lety jsem se blíže zajímal o formát ZIP. Výsledkem byly dva nástroje, postavené na algoritmech Ron de Bruina: prohlížeč zipů a zipovač souborů. První z těchto služeb nyní poskytuje přímo Windows v rámci svého prohlížeče. Nevím ale, že by Windows nabízel také tvorbu zipů.
Vzhledem k tomu, že můj zipovač není nic jiného, než sešit Excelu, nepotřebuje žádnou instalaci a dá se spouštět i z flešky, kterou nosíte v kapse. Pro ty, kterým podpora pro zipování chybí, je určen soubor v příloze. Pro legraci: zip toho zipovače vznikl pomocí shodného zipovače, jako je ten zazipovaný 
.
Včera večer mi poslal správné řešení i TEDO. Pokud projeví zájem, má u mne připravenou prémii.
Předpokládám, že tím končí život tohoto vlákna, trvající prakticky měsíc. Dostal jsem pět správných řešení a všem úspěšným řešitelům gratuluji. Dvěma zájemcům, kteří o to projevili zájem, jsem také poslal prémii. Můj závazek platí dál. Stačí poslat mi mailem správné řešení a projevit zájem o můj nástroj pro zápis a čtení skrytých textů.
Přepočet vzorce kvůli změně hodnot v jeho odkazech nevyvolá žádnou událost Excelu, kterou by bylo možné indikovat. Tudy prostě cesta nevede. Pokud chceme získat reakci, je nutno indikovat změny v těch buňkách, které jsou měněny přímo. Nemohu např. indikovat změnu hodnoty součtu, který je vytvářen vzorcem. Místo toho musím hlídat přímé změny v buňkách, z nichž součet vzniká.
Jiná situace vzniká, když hodnotu buňky nepočítáte pomocí vzorce v ní, ale pomocí srovnatelného výrazu z VBA. Na takovou změnu buňky už Excel reaguje zcela automaticky vznikem události Change.
Dalším majitelem prémie se stal Adam Mladý. Jsem zvědavý, kdy (a jestli vůbec) se o prémii přihlásí se svým řešením TEDO. Nebo ještě někdo další...
: dodatečně opravené jméno s omluvou
Všiml jsem si, že někteří účastníci diskuse akceptují komprimaci pouze ve formátu ZIP, se kterým si poradí Windows bez další SW podpory. Jsem po reinstalaci svého systému a dokud si nějaký SW neopatřím, kromě zipů si z příloh přečtu už jen grafické formáty.
Pro přílohy na fóru zpravidla není rozhodující kvalita komprimace. Se čtením zipů nemá nikdo problém. Zvažte proto prosím, jestli by vám jednotné používání formátu ZIP pro komprimované přílohy dělalo nějaký problém. Pokud ne, řadě lidí byste tím zjednodušili život s přístupem k přílohám.
Získal jsem reakci čtenáře, který stejného postupu využívá pro zpřístupnění speciálních znaků anglické klávesnice, aniž by musel klávesnici přepínat. To pokládám pro vývojáře za výborný tip.
Jiný příklad: pro realitní kancelář jsem použil dvojznak "m2" pro transformaci na metry čtvereční (se znakem indexované dvojky z Unicode). Jsem od nich za to velebený. Na druhé straně mám teď na stejných počítačích problém s napsáním adresy pro buňku M2 (obejít to ale jde).
Ve svém počítači mám práci s indexovanými znaky řešenou ještě jinak: používám diakritických znaků "ˇ" a "´" před číslicí pro identifikaci horních a dolních indexů. Protože v tomto případě jde o celkem 20 znaků, mám na to nastavení napsanou proceduru ve VBA.
Zbytečně ostrá odpověď s užitečným obsahem (KeyPress / KeyDown). To kvalitativní odlišení znak / klávesa je právě to, co mi v nápovědě chybělo. Počítám, že v tom nebudu sám.
Je poněkud neobvyklé hledat podporu pro Excel v nápovědě pro Visual Studio 6. Tam bych asi pro informaci k Excelu nezabrousil. Ke svému překvapení jsem ale v zabudované nápovědě k Excelu našel třídu KeyCodeConstants s úplným výčtem hodnot stisknutých kláves, a to i s jejich logickými jmény.
Nenašel jsem tam ale žádné logické vysvětlení, proč mají klávesy numerické klávesnice jiné hodnoty KeyCode než jejich "dvojčata" z velké klávesnice. Rovněž tak nic pro fakt, že malá i velká písmena produkují stejný KeyCode. Připadá mi to, jako kdybych vlezl do jiné zoologické zahrady. Takže z ní zase tiše odcházím, když jsem se bez ní obešel dosavadních patnáct let života s Excelem.
Dobré ale je, když ted vím, co na mne číhá za rohem. Je dobré vědět, že vbKey3 je úplně jiný než vbKeyNumpad3 a že např. vbKeyNumpad2 poskytuje ASCII hodnotu pro znak "b", přestože produkuje znak "2". Takhle nějak vypadají arménské hádanky z rádia Jerevan.
Můj závěr se tentokrát plně shoduje s hodnocením od elCHa: "Obecně povolovat znaky je velmi nepraktické. Lepší je testovat, zda nový obsah je jakékoliv "číslo" a v tom případě změnu povolit."
Devil získal prémii!!! Nevšiml jsem si, že už v 20:57 v podstatě poslal své správné řešení.
Ještě někdo další se ozve? Prémie stále čeká na úspěšné řešitele.
Zcela jistě, nabídka platí dál! Oni to ti úspěšní řešitelé (pokud vím) zatím nikomu nevykecali. Byli by taky blázni, protože co kdyby to jednou potřebovali? Takové věci totiž fungují nejlíp, dokud o nich prakticky nikdo neví...
Devile, ještě jedna maličkost: podívejte se do svých vzkazů (vpravo nahoře). Máte tam už nějaký čas ode mne další podnět!
Jen pro legraci: znáte ten slavný lapsus Excelu, podle nějž pro Excel existuje neexistující 29.únor roku 1900? Někde jsem se dočetl, že tu chybu udělal už Lotus 1-2-3 a Excel ji údajně kvůli datové kompatibilitě převzal. Lotus jaksi zmizel ze světa, ale chyba v Excelu přežila...
Nepřestupného roku 2100 bych se nebál. Tou dobou nejspíš už zase Excel nebude existovat. Vzpomínám si, když kolega Bárta kolem roku 1970 řešil pro děrnoštítkový počítač z n.p. Aritma problém přechodu na rok 2000. Rok 2000 jsem já přežil, Honza Bárta nejspíš taky, ale devadesátisloupcové děrné štítky Holerith nikoliv.
Můžete mi věřit, že nápověda, jak se textu zbavit, je ta nejsilnější indicie, kterou máte po ruce. Až budete vědět, jak na to, sami to uznáte. Dokonce jsem váhal, jestli tím neprozrazuji příliš.
Mám už dvě pozitivní řešení z terénu. Jeden z těch dvou úspěšných dokonce tvrdí, že zná partu lidí, pro které by ta moje úloha byla brnkačka. To tedy nevím, ale jde o přímočarou transformaci z jednoho systému uspořádání hodnot do druhého. Slovně lze ten převod popsat jednou stručnou větou. Navíc oba ty systémy Excel používá přímo masově.
I s tím ASCII máte zase pravdu! Vy na ten výsledek přímo koukáte, akorát ho tam nevidíte. Spojte si to s nápovědou, jak se bezpečně zbavit skrytého textu a výsledek zapijte něčím šmakózním.
Za nezřízenou urputnost při řešení úlohy mám pro vás nachystaný ten udělátor, jehož použití bylo k vidění na obrázku. Totéž čeká na TEDO, pokud se mi ozve s výsledkem na mou mailovou adresu (jeho adresa tady není k mání). Ten udělátor ostatně může získat každý, kdo úlohu rozlouskne dřív, než tady někdo vykecá podstatu hry.
Pokládám za svou povinnost omluvit se za chyby, kterých jsem se dopustil při hodnocení kódu, který zaslal elninoslov. Dosud nikdy jsem nepoužil událost KeyDown pro vyhodnocení hodnot stisknutých kláves. Tiše jsem ale předpokládal, že nemohu dostat nic jiného, než ASCII hodnotu znaku, zobrazeného stiskem. Z toho pak plynuly moje výhrady k výčtu jejich hodnot.
Druhá verze kódu od elninoslov mne ale varovala, že je někde něco jinak. Napsal jsem si proto jednoduchý test na vznikající hodnoty KeyCode.
Výsledek mne dost vyděsil, protože rozvrátil můj předpoklad o obsahu předávaných KeyCode. V příloze je můj test, tady moje omluva. Z výsledku testu pro mne plynou dva závěry:
- každý soud bez ověření je riskantní soud,
- událost KeyDown jsem potkal, otestoval a nikdy ji sám nepoužiji, protože mi vnáší zmatek do míst, která mám jinak docela dobře zmapovaná.
Určitě SVYHLEDAT. V těch názvech je lehký bordel. V českém Excelu je SVYHLEDAT A VVYHLEDAT podle Svisle a Vodorovně. V anglickém Excelu je VLOOKUP a HLOOKUP podle Vertical a Horizontal. Tím vzniká ta krávovina, že VVYHLEDAT a VLOOKUP vedou každý jiným směrem a lidem z toho v hlavě vzniká zmatek.
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