Příspěvky uživatele

Mně vyšel pro 2.řádek příkladu tento vzorec:
=12*ROK(B2)+MĚSÍC(B2)-(12*ROK(A2)+MĚSÍC(A2))+KDYŽ(DEN(B2)>=C2;1;0)
Vzorec lze roztáhnout pro celou tabulku. Oprava o 1 se týká případu, kdy datum poslední splátky zahrnuje i den běžné splátky.
Můj vzorec říká, kolik splátek celkem má být splaceno, nikoliv počet splátek k dnešnímu dni, jak bylo požadováno. To zadání jsem nějak nepochopil.

Ten druhý postup je lepší a opravdu vloží konstantu, nikoliv zorec, jak jsem se původně domníval, že udělá když je volaný jako Formula. Nejjednodušší znění ovšem je ActiveCell = Date

Teď mi došlo že když na MACu není klávesa pro středník, že může být problém napsat SendKeys "^;".
Pokud by to problém opravdu byl, naplňte SendKeys takto:
SendKeys (Chr(94) & Chr(59))

Ve Windows lze nápad s makrem na zkratku pro "Ctrl;" realizovat dvěma spolupracujícími makry:
Sub Dnes()
SendKeys ("^;")
End Sub

Sub Pouzij()
Application.OnKey "^{DOWN}", "Dnes"
End Sub
Makro Pouzij zprovozní zkratku "Ctrl-šipka dolů" tak, že bude volat makro Dnes. Místo makra Pouzij bude dobré příkaz umístit do událostní procedury Workbook_Open. Makro Dnes pak vytvoří požadovanou klávesovou zkratku "Ctrl;"
V tomto provedení mi to ve Windows pracuje správně. Zkratka "Ctrl-šipka dolů" mi produkuje dnešní datum.

Excel pro MAC neznám. Předpokládám ale, že má českou nápovědu. Zkuste v ní prohlédnout heslo "klávesové zkratky" nebo "shortcuts". Odpověď by tam mohla být.

Možné to samozřejmě je. Pro odladění by se hodila adresa vstupního souboru z netu a požadovaná výsledná podoba výstupu (předpokládám, že to je "nějaká" excelská tabulka "někde" v sešitu, ale může to být libovolný, např. textový soubor).
Úplně bez programování by mohl posloužit i můj doplněk ImportZwebu, jehož využití je podmíněno jen tím, že požadovaný obsah z netu je možné pomocí Ctrl-C umístit do systémové schránky. Doplněk má řadu nástrojů, jak získaná data modifikovat do požadované výstupní podoby na listu excelského sešitu.
Pro opakované stahování téhož formátu je ovšem ta první cesta uživatelsky pohodlnější.

Vůbec si nemyslím, že by zkušení vývojáři spolupráci Excelu s SQL databázemi nevyužívali. Dodávají tím svým aplikacím mnoho vynikajících vlastností a schopností. Nejde mi o tyto "zasvěcence". To by bylo nošení dříví do lesa. Pokusil jsem se vzbudit zájem v těch, kteří zatím s databázemi nepracují. Tam cítím velký potenciál pro zapojení účinných technologií do práce s Excelem.
Také netvrdím, že svět osm let spal a že moje archeologie je objevná. Chtěl jsem jenom říct, že jsem před osmi lety pro sebe objevil něco, co jiní znali léta přede mnou a co mnozí současníci neobjevili dodnes. Mne prostě překvapuje, že ani po tolika letech nepatří aktivní spolupráce Excelu s databázemi ke standardní výbavě běžných vývojářů.
A nakonec: chtěl jsem podat ruku těm, kteří by to rádi zkusili, ale nevědí, jak do toho. Nabízím ovšem cestu starou osm let. Tu mám osahanou, k té se umím vyjádřit a tu také v případě potřeby stále využívám. Zatím jsem si bohatě vystačil. Kdo se na to cítí, může si jistě najít novější možnosti.
Podstata problému podle mne nespočívá v tom, jaký přístup k databázím zvolím. Podstatou je to, zda vlastní databáze pro své aplikace vytvářet a používat umím.

Ještě příloha na zvláštním talířku

Riskuji další téma bez odezvy. Přesto, že to pokládám za stěžejní pro bezpečnost a spolehlivost práce s daty v Excelu, je dané téma jen velmi zřídka předmětem diskusí na excelských fórech. Nevěřím, že by to bylo způsobeno všeobecnou znalostí a bezkonfliktností práce s daty, uloženými v SQL databázi. Spíš to bude tím, že vývojáři o této možnosti nevědí dost, aby ji více využívali.
I já jsem dlouho vycházel z představy, že k tomu, abych takovou databázi mohl využívat, musím k ní získat přístup z externího zdroje, když sám žádný prostředek pro její založení a obsluhu nemám. Tuto představu u mne změnila účast na jednom setkání vývojářů Excelu a na něm mimochodem vyslovená jediná věta. Stalo se to v roce 2007 a změnilo to tehdy zásadně můj pohled na práci s daty v Excelu. O řádovém posunutí práce s daty v SQL databázi proti jejich uložení v Excelu jsem nepochyboval ani předtím. Dozvěděl jsem se tehdy tu "zásadní maličkost", že Excel je plně vybaven prostředky, aby si sám vytvořil SQL databázi accessového typu (.MDB) a sám ji také plnohodnotně obsluhoval. Tím padl můj základní argument, že bych jinak musel MS Access kvůli tomu pořídit.
Vše stálo a padalo s knihovnou DAO, kterou má Excel ve výbavě snad od zrodu objektového modelu Excelu a kterou stále obsahuje (již mnoho let ve verzi 3.6). Tato knihovna je určena přímo pro práci se soubory typu .MDB a pro tento účel je jednodušší a rychlejší, než později zavedená knihovna ADO.
Před osmi lety jsem se tomuto tématu pár týdnů intenzivně věnoval. Výsledkem byly (kromě zpracování několika školních sešitů s příklady pro vytvoření a využití databáze .MDB v Excelu) i dva texty, které shrnovaly vše zásadní, co jsem k tématu tehdy zjistil. Teď jsem si tu osm let starou práci prohlédl. S trochou překvapení i nostalgie jsem zjistil, že na jejich znění ještě dnes nemám potřebu změnit ani čárku. Úvodní text z tohoto balíčku sem dávám k nahlédnutí. V případě zájmu (na který ovšem moc nevěřím) mohu plynule navázat popisem práce s knihovnou DAO, případně se zmíněnými školními sešity.

to elninoslov:
podle mne nejlepší rada tady na fóru za dlouhou dobu! Za stovku ušetřit hodiny vymýšlení a ladění - to jsou dobře investované peníze!!!

Obávám se, že představa, kterou má Tlumic01, bude jen ztěží realizovatelná bez VBA. I pěkný rozbor od elCHa to naznačuje. Několik úloh podobného typu jsem už řešil a na dostatečně pružné řešení "bez hřebíků" (tj. bez maker) bych si nevsadil.

Možná by stačilo pozorněji číst. Zamixování dat "na místě" je jen jedna výjimečná možnost, jak data zaměnit. Seznam jmen např. mohu použít z úplně jiného sešitu a s úplně jinými jmény, stejně jako mohu tabulku dat změnit za úplně jiná data. To, že bych neměl v přijímajícím sešitě zničit vzorce, by snad měl pochopit i laik.
Navíc jsem (alespoň si to myslím), nabídl generátor náhodně rozmístěných čísel zvoleného rozsahu pro zvolenou oblast dat. Takže mohu oblast naplnit zcela náhodným obsahem. Nakonec bych chtěl říct, že jsem si ty nástroje vyzkoušel na vlastních sešitech. Kdybych si nebyl jistý, že výsledek mohu dostat do stavu "nezneužitelné", asi bych to nenabízel.
Přesto jsem rád, že se alespoň někdo ozval. Neposílal jsem to na fórum, abych ukázal, jak jsem dobrej, ale jako prostředek, aby tazatel mohl poslat na fórum vzorek sešitu, který jinak kvůli důvěrným datům poslat nejde.

Dlouhou oklikou jsme se dostali zpět do výchozího bodu. Elninoslov má naprostou pravdu v tom, že nikdo z nás neví, k čemu to Tlumic01 potřebuje. Určitě tu není hlavním problémem zavřený sešit. Řešení přes textový soubor (Hav-ran) je nejspíš postačující. Řešení přes DB (elninoslov) je ještě lepší. Pokud jde o unikátní čísla faktur, je to zase úplně jiná pohádka. Elninoslov má pravdu. Počkejme, co na to tlumic01.

Tak na to jsem zvědavý. Až doteď jsem byl hluboce přesvědčený, že do zavřeného sešitu nic zapsat nejde. Jestli na vlastní oči tenhle trik uvidím, tak asi začnu věřit na nadpřirozené síly.

Hezká ukázka situace, kdy se dva experti na VBA dohadují mezi sebou o detailech, zatímco tazatel sotva tuší, o čem je řeč! Asi by stálo za úvahu, aby tazatel upozornil na své hranice stravitelnosti získaných odpovědí...

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje