Příspěvky uživatele


< návrat zpět

Strana:  1 ... « předchozí  28 29 30 31 32 33 34 35 36   další »

Ten zápis je naprosto správný. Doporučuji ho neopisovat, ale přímo zkopírovat! Za jedinou jeho vadu lze pokládat strašidelnou délku a tím i špatnou čitelnost celého příkazu. Problém je v tom, že ověření použitelnosti provedené změny na listu ani zjištění první volné buňky v řádku není ve VBA úplně triviální úloha. Čitelnosti zápisu by možná prospělo rozepsání celé konstrukce do více příkazů.

CmeldaBoris napsal/a:

Vovka napsal/a:
Kdybych zvolil kliknutím do navigátoru nějaký list a pak bych chtěl v tom listu pracovat - třeba se kurzorovými šipkami někam posunout a měl bych aktivní stále navigátor, tak se na listu s kurzorem nikam posouvat nebudu. Vám se to chová jinak?
A nebo si prostě nerozumíme:-)

Odpovídám opožděně, ale přece: to vysvětlení je dobře napsané. I u mne se to tak chová. Je zvláštní, že jsem si takového chování nevšiml nikdy předtím. Asi jsem takový fanatik do používání myši, že mne za patnáct let používání Excelu nenapadlo po přepnutí na jiný list rovnou použít kurzorové klávesy k pohybu po listu. Dík za upozornění pro příště. Nikoliv kvůli mně (já bych na to asi nikdy nenarazil), ale kvůli druhým, pro které občas něco napíšu...

Pokud chcete získat se zárukou výhradně textovou podobu datumu, použijte z VBA funkci Format, např.

cells(1,1) = Format(Cells(3, 2), "d/m/yyyy")

Anglický formátovací řetězec "d/m/yyyy" se v českém Excelu sám převede na naše lokální "d.m.rrrr"

Před pár lety jsem pro kamaráda napsal v Excelu 2007 aplikaci s makry. Kamarád je kolenovrt a používá ji s úspěchem dodnes na své trofejní technice s Excelem 97. Technika mu ale dosluhuje a on si musí koupit nový notebook. Samozřejmě za hubičku. Když jsem mu v souvislosti s tím sdělil, že nový MS Office ho bude stát přes tři tisíce, úplně ho to skácelo.
Někdo mu pak poradil, že novější OpenOffice (které je zdarma) umí mj. i OO Basic, což se něco jako VBA z pokleku. Z toho mu plyne teoretická možnost převedení mojí aplikace do prostředí Apache OO Calc. A bez investic do SW...
S tím žádnou zkušenost nemám, takže ten nápad nemohu ani potvrdit, ani vyvrátit. Ptám se proto zde, jestli někdo z vás má s takovou možností praktické zkušenosti nebo dokonce je schopný poskytnout použitelný příklad aplikace s makry OO Basic. Za technicky únosných podmínek bych totiž rád kamarádovi vyhověl (a případně si přitom rozšířil možnosti pro psaní tabulkových aplikací s makry). Jsem opravdu zvědavý, jestli se mi někdo ozve a co se při tom případně dozvím!

Pokud si stáhnete zdravá data (čísla s desetinnými čárkami místo teček), bude možné s nimi také jako s čísly zacházet. Ne že bych si s tím neuměl poradit, ale vám by to nebylo k ničemu.
Vzorec, který spočítá rozdíl mezi koncovým pátečním a začátečním pondělním kurzem ve vaší tabulce se zdravým obsahem, může vypadat např. takto:

=KDYŽ(B2="pátek";G2-INDEX(A3:D8; POZVYHLEDAT("pondělí";B3:B8;0);4);"")

Ve sloupcích D a G ovšem musejí být čísla, jak už jsem upozornil. Spočítat pak počet vypočtených kladných a záporných hodnot snad už nebude problém.

Opravdu to při podmíněném formátování nejde. Excel má ale víc tváří. Znám vývojáře, kteří místo podmíněného formátování používají událost listu Change. Tam podobná omezení neplatí a buňku lze podle nabyté hodnoty naformátovat zcela libovolně.

API pro skrytí celého UserFormu s ponecháním zobrazení jeho prvků jsem neznal. Používal jsem pouze API pro potlačení hlavičky. Tohle vypadá elegantně! Použiji při první vhodné příležitosti. Dík!
Nutnost zbytečně klikat do zavolaného listu dál nechápu. Je-li kurzor nad listem, má tvar kříže; nad UserFormem se ukazuje šipka; na co ukazuji kurzorem, to je právě aktivní. To mi bohatě stačí. Pokud nevolám nějakou specifickou metodu nebo vlastnost pro ActiveWindow, nemám potřebu starat se, co je ActiveWindow.

Tomu nerozumím! Nebo je smyslem věci seznam ukázat, ale nedovolit ho používat? Pak ovšem nechápu filozofii takové nabídky. A k čemu je pak nakonec dobrá ta aktivace, když má být stále neaktivní??? Nějak se nechytám...

Co se týká aktivace nemodálního formuláře: pokud ho použiji běžným způsobem, aktivuje se automaticky kliknutím na jakoukoliv svoji aktivní součást a list stejně tak kliknutím na jeho plochu. To automatické přepínání pokládám za jednu z nejlepších vlastností nemodálního formuláře. Dokonce tento režim ani neumím změnit (možná to souvisí se zmíněným AppActivate Application.Caption z vašeho dotazu).

to elninoslov: asi máte pravdu s tím zip, šlo jen o okamžitý nápad bez dalších souvislostí. Jinak jsem se u zaslané přílohy opravdu dočetl, jak vznikla, takže tam žádný zmatek nehrozil.
Co vedlo autora tohoto fóra k tomu, že formát excelského sešitu nezařadil mezi přípustné formáty, nevím. Všichni si tady kvůli tomu musejí dávat trochu nohu za krk. Jinak klobouk dolů, komunikuje se tady pohodlně a s komfortem!

Mně se naopak nápad s přejmenováním sešitu docela líbil, protože je to jednodušší postup, než komprimace. Jen bych místo koncovky .txt pro ribbonové sešity doporučil přejmenování na .zip, protože ve skutečnosti to opravdu jsou soubory ve formátu zip.

Dodatek ke smyslu vašeho formuláře: zkusil jste klepnout pravým tlačítkem na některou z ikonek pro posun oušek se jmény listů (vlevo dole na monitoru)? Měl byste dostat podobnou nabídku jako při použití svého nemodálního formuláře.

Z výčtu události pro UserForm lze využít událost kliknutí na tělo formuláře (UserForm_Click) a kliknutí na zavírací křížek vpravo nahoře (UserForm_QueryClose). Za záhlaví můžete naopak formulář zachytit a přesunout. Událost pro kliknutí na záhlaví neznám.

Omluva: samozřejmě jsem měl na mysli obrat ActiveCell.Offset, kterými se kód hemží.

Ten kód je na můj vkus napsaný velmi exoticky. Očekával jsem rozsáhlé cykly, místo nich jsem našel zamilované hraní se zápisem ActiveShett.Offset, zato žádná pole ani definované oblasti na listu. Zápis by šlo několikanásobně zkrátit, ale významné zrychlení algoritmu by to nejspíš nepřineslo.
Přechod od Double k Single by přinesl jen nepatrné zrychlení, které vůbec nestojí za námahu. Zato zmenšení rozsahů v datech pro grafy ve vašem případě skrývá velký rychlostní potenciál. Deset tisíc prvků v sériích je podle mého soudu řádově vyšší, než lze na listu odlišitelně zobrazit. Cesta redukce rozsahů dat pro grafy je podle mne tím správným krokem za zrychlením výpočtů.


Strana:  1 ... « předchozí  28 29 30 31 32 33 34 35 36   další »

Uživatelské menu

Nejste přihlášen(a)
avatar\n

Menu

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.

Aktivní diskuse