Příspěvky uživatele
< návrat zpět
Mně to připadá, že chcete moc muziky najednou. Kdybyste do buňky LinkedCell přenesl vybranou možnost, mohl byste si pro ni zjistit pomocí POZVYHLEDAT řádek na zdrojovém listu a z jeho sloupců byste následně mohl čerpat potřebné hodnoty. Pro takový postup ani nepotřebujete prvek ActiveX, stačí obyčejný ComboBox pro list.
K nastavení zdroje pro seznam položek v samostatném prvku ComboBox z kolekce ActiveX nepotřebujete znalosti o VBA. V režimu návrhu umístěte prvek na list a k tomu si zavolejte službu Vlastnosti (vedle nabídky Režim návrhu). V ní vyhledejte vlastnost ListFillRange a do ní zapište oblast se zdrojovým seznamem,
např. List2!B10:B40
Pro úplnou funkci prvku je nutno zadat ještě vlastnost LinkedCell (např. E20), kam se vybraná možnost přenese.
Když pak vypnete režim návrhu a klepnete na pravý ukazatel v prvku, dostanete požadovanou nabídku.
Obsah TextBoxu je vždy a zásadně textový. Nelze dopředu nastavit, aby TextBox pracoval numericky. Pokud chci mít jistotu, že v textboxu není nenumerický obsah, měl bych při každém opuštění TextBoxu obsah testovat, aby v něm nemohly být nesmysly (událost Exit). IsNumeric je pro ten účel dobrý test. Pak bude jednoduché s takovou informací pracovat.
Se zavedením objektu tabulka (ListObject) vznikly pro třídění oblasti buněk na listu dvě třídicí syntaxe: metoda Range.Sort pro běžnou oblast na listu (jak jste ji mínil použít) a vedle ní metoda .Apply pro ListObject.Sort. Pokud je vaše tabulka tabulkou typu ListObject, musíte použít postup, který navrhuje Dingo.
Pánové xlnc a elCHa, oba jste geniální, ale na vzájemné plácání po zádech byste si mohli založit vlastní vlákno, nebo si zajít spolu na pivo! Nějak se mi ztratila souvislost s tématem vlákna...
Věřím, že se problém podaří rychle odstranit. Je až neskutečné, kolik let už Microsoft marně válčí s kompatibilitou mezi 32 a 64 bitovým Office. Sám jsem si nikdy 64bitovou verzi Office nenaistaloval a uchránil jsem se tím zřejmě od mnoha nepříjemností.
elCHa mne svým vláknem upozornil, že jsem zřejmě do fóra neposlal poslední verzi svého převodníku. V příloze je verze Transform, napsaná jako klasický doplněk Excelu, jehož funkčnost je rozšířená o možnost nastavení referenční buňky pro zápis R1C1.
Pokud někoho můj převodník zajímá, může si ho nainstalovat.
Doplněk od elCHa pro vzájemný převod mezi českým a slovenským zněním vzorců je jistě vhodnou pomůckou pro předávání vzorců "na papíře". Výskyt slovenského "IF" v textu místo českého "KDYŽ" to dobře dokládá.
Pravda ovšem také je, že jde o důsledek nevhodného předávání vzorců mezi dvěma národními prostředími. Pokud se nechceme dočkat podobných nemilých překvapení, stačí vzorce si předávat přímo na listech sešitu, a ne v textu příspěvku. Když Slovák do svého vzorce na listu napíše "IF", Čech si ho z téhož listu bez jakýchkoliv pomůcek přečte v českém Excelu po svém jako "KDYŽ".
Každá funkční pomůcka je užitečná. Převod vzorců mezi verzemi CZ a SK má zřejmě specifika, která jiné převodníky neumějí provést, a proto si jistě najde své příznivce.
Při citaci mého převodníku se správně konstatuje, že převodník pracuje s interním převodem vlastností Formula a FormulaLocal. Pracuje proto zákonitě s každou lokalizací Excelu, tedy i se slovenskou, vždy ale proti anglickému originálu.
Přímý převod mezi českou a slovenskou mutací můj převodník provést neumí. Tím, že se převodník od elCHa vymyká z klasického převodního schématu mezi originální a lokalizovanou verzí, se právem hlásí o své místo na slunci.
V příloze je nástin řešení
A abych jenom neteoretizoval. V příloze je řešení, které nedělá nic jiného, než že se drží rozumu.
Asi jsem už nejsme normální. Nebo lépe považujeme za nenormální vše, co se odchyluje od pravidel MS nebo jejich lokalizačního týmu.
Neznám nikoho, kdo by aritmetické výrazy zapisoval do Excelu římskými číslicemi (i když by to možná šlo). Pokud někdo do Excelu vkládá tabulku, kterou míní vyhodnocovat jako data, měl by dodržovat pravidla pro jejich běžné obrábění. A zejména by nikdo neměl navádět neznalé uživatele, aby nedodržovali pravidla prostředí, do kterého dobrovolně vstoupili. Pokud tohle někdo toleruje, naprosto zbytečně komplikuje věci, které jsou jinak jednoduché.
Říct "takhle ne!", když je něco zjevně blbě, umí každý soudný člověk. Složitější je poradit, jak "jinak". Když jsem řekl "A", zkusím říct i "B".
Kalendářní interval "od - do" je dost obvyklá logická konstrukce, na kterou bývají navázány takové testy, jako "uvnitř intervalu / mimo něj", případně výběr intervalu pro dané datum. Z toho titulu lze na kalendářní interval nahlížet jako na možný "pseudoformát", který lze vybavit potřebným vyhodnocovacím aparátem.
Kategorii pseudoformátů a práci s nimi se věnuje text, který přikládám. Kalendářní interval by se mohl stát jedním z takových pseudoformátů. Jeho použití by pak mohlo zásadním způsobem zjednodušit tazatelovo zadání.
Podle mne by bylo jednodušší napřed vytvořit dpf a ten pak následně tisknout, než napřed tisknout a pak z tisku vytvářet pdf.
Opravdu máte pocit, že tazatel TEho má z téhle diskuse nějaký užitek? Asi by bylo účelné, kdyby se k tomu tazatel vyjádřil...
Pokládám za bezpředmětné zabývat se zadáním, které nesplňuje ani základní zásady pro práci s daty. Vyhodnocováním slepence dvou kalendářních dat to začíná. Jedna, nebo taky dvě mezery za pomlčkou jsou pokračováním o nepochopení práce s daty. A "datum", které má před rokem mezeru, není datum.
Dokonce pokládám za škodlivé s takovými "daty" pracovat dřív, než se do nich vnese alespoň základní pořádek. Fakt, že to člověk očima přečte bez problémů, by neměl být důvodem, abychom Excel nutili k obrábění podobného datového nepodařence. Jen to svádí negramotné uživatele k přesvědčení, že Excel unese cokoliv.
Uživatelské menu
\nMenu
Formulář Faktura
Formulář Faktura IV
Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.
Helios iNuvio
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.
RSS nejnovější články