Makro funguje rychle (cca 3,5 min) a dobře až na hlavičku, kde je 377x "Počet_x" a "Cena_x" (u cca 80 tis. řádků). Dá se to jednoduše ošetřit?
Pokud ne, tak to tak necháme. Hlavička se dá rychle upravit.
Děkuji.
Nevím přesně oč Vám jde. Jde o rychlost s jakou se vybavuje hlavička, nebo spíš o šířku sloupce. Ne šířku sloupce lze jednoduše kliknout do porůsečíku řádků a sloupců, nebo stejně efektivně Ctrl+A - najet na hlavičky sloupců a pravým tlačítkem zavolat kontextové menu > OPTIMÁLNÍ ŠÍŘKA. je to za dvě sekundy. Samozřejmě makro na to existuje také. Nemám s tím problém.
Pokud by se jednalo o rychlost výbavy hlavičky chtěl jsem celkově systém makra přebudovat do array, kde by to bylo formou "metelesku blesku" vše včetně hlavičky. Tipuji v řádech malých sekund.
Makro v tomto případě funguje bez problémů, počet opakování materiálu je max 12 a v "List2" je počet párů sloupců "Počet" a "Cena" taky 12.
1) Problém nastává u celého objemu dat u cca 80 tis. řádků (počet různých 8965, max opakování 6), kdy v hlavičce je 377 párů sloupců. 377 je hodnota "opak".
Počet opakování jednoho materiálu může být max. 12.
Pozitivní je, že konverze ceníku do řádků nyní proběhne celá v rozmezí 3-3,5 min, což je super.
2) V listu "vystup_Cíl" jsem přesunul sloupce "Jedn." a "Měna", aby se kopírovali pouze 1x.
Nevím, jak upravit makro.
Riziko je sice minimální, ale přes to se může stát toto : Počet jednotek je číslo většinou rozeznatelné ve formě podílu – čísla s desetinnou čárkou, ale počty kusů jsou celé číslo ap. S cenou je to podobné. Když ponecháme jen čísla snadno zaměníme dva sousední údaje z různých případů. Tedy například spojíme (cena_5)+(jednotka_6).
Tomu se dá zabránit nejlépe barevným odlišením sloupců jednotek (například jemnou barvou) přímo v zápisu na řádku. List totiž zajíždí pod zafixované řádky i sloupce. Proto barva sloupce z hlavičky nebude souhlasit s posunutým listem.
Už vidím jak spustíte hledání podle množství, nebo ceny a jak list zajede „doleva a nahoru". Budete mít svou hodnotu, ale nebudete vědět jestli je to počet, nebo cena. Vyřeší to buď podbarvení, nebo formát buňky který by řešil i jinou chybu.
Dalším problémem je skutečnost, že se u stejného materiálu zřejmě může vyskytovat také různá měna. Jak je vidět – používáte Eura, ale u nás platí Kč a může jít možná i o jinou měnu USD apod. V případě stejného materiálu a různého druhu měny by vznikly dva (nebo i více) řádků stejného materiálu. Jediným nejvhodnějším řešením je formát buňky s připojenou jednotkou a druhem měny.
Například |2,65 m2|17,5 E|, nebo |5,2 kg|123,07 Kč| v takovém případě je možné záznam vytvořit buď formátováním (což vyžádá více kódu), nebo lépe ve formátu string (text), ale potom musíme hledat opravdu text. Opět jde o to k čemu potřebujeme hledání. Formát string ušetří kód makra. Oba způsoby mají výhodu a nevýhodu a jde zejména o strojní prohledávání.
Problém hledání zřejmě není možné provádět jinak, nežli makrem vzhledem k počtu buněk. Makro pro hledání nebylo požadováno, ale manuální hledání je velice hektické i když je uspořádání tabulky sofistikované.
A. Hledá se přesný typ materiálu (sloupec A). Dál je možné v řádku hledat buď podle jednotek, nebo podle velikosti, a nebo obojí. Zkratku (jednotka & druh měny) je možné přidat samostatně do sloupce B, nebo ji přilepit přímo k materiálu ve sloupci A. Když budou formátované jednotlivé buňky není takové opatření potřeba, ale přes to bych do sloupce B doporučil vložit počet položek.
B. Strojní hledání nepotřebuje odlišit sloupec jednotky ani ceny. Takové hledání by se provádělo například za účelem dohledání materiálu u kterého známe pouze počet jednotek, nebo cenový objem. Bylo by to dohledávání chyb z dřívějšího zpracování.
Makro vyhledávání je pro všechny různé případy nutné postavit jinak. Proto je koncepce tabulky stěžejní. Také je důležité upřesnit jak má vypadat výstup z makra. Může to být například extra list s výpisem, nebo skok na položku a její podbarvení v 1. listu (zdroj). Samozřejmě jde o to proč se takové úpravy vůbec dělají.
Takže zvažte potřebu makra už při návrhu koncepce výstupní tabulky. Makra pro uspořádání tabulky je celkem snadné upravit do nové podoby a bylo by to asi tak na hodinu práce. Makro by také nemělo trvat dlouho.
Na základě Vaší odpovědi mě napadlo toto řešení:
Sloupce Jednotka a Měna jsou pro 1 položku vždy stejné, mohli by se zkopírovat pouze jednou za sloupec "Materiál". Pak by smyčka (opakování) byla pouze na Množství a Cenu.
Bude to takto fungovat?
Pokud ne, rozdělím soubor na 2 části a pak data spojím.
Jedná se o největší počet řádků (do 40 tisíc).
Zpravidla pro tento typ převodu mám menší počet řádků.
Snažím se najít řešení, které bude fungovat delší dobu.
Formát dat není rozhodující, pokud to zrychlí makro. Formát dat se dá velice rychle dodělat.
....... Vyskočilo hlášení s číslem 377 a následně stejná chyba (chyba_2a.jpg)
https://drive.google.com/file/d/1d3rKPu … sp=sharing....
Odkaz vyžaduje přístup. Zatím jsem nic neobdržel, ale to co píšete je jasné. Těch 377 řádků ze sloupce A reprezentuje 377 x 4 = 1508 sloupců. To nemohlo projít, protože list má pouze 1024 sloupců.
Máte problém, který je nutné řešit jinak. Možností je více, ale veskrze jsou praktickým řešením pouze 2 - 3 verze.
A. Za řádkem 255 (ve sloupci A) pokračovat na dalším listu.
B. přidat k hlavičce zkratku jednotek Materiál + k(jako kusy), E(jako Eura) a podobně. zbudou 2 sloupce (to už stačí k pokrytí většího množství - cca 511 řádků ze sloupce A).
C. Výstup transponovat – místo do řádku dělat výpis do sloupců.
D. Pokračovat druhým řádkem a spojit (sloužit) dvě buňky pod sebou do jedné, aby sloupec šlo procházet plynule.
E. Sloučit hodnotu s jednotkou. Lze to vytvořit formátem, ale čte se jen číslo bez přídavku.
Každé řešení má svá pro a proti. Pokračování na novém listu je méně komfortní, ale jde jen o to s těmito údaji budete dělat. 1024 / 4 = 256 přesně, ale v prvním sloupci je materiál. Takže do řádku se vejde opravdu jen 255 x 4 = 1020 + 1 (materiál) a proto na konci zbudou 3 prázdné sloupce kde může být klikací odkaz do dalšího listu, nebo počet záznamů – potřebný zejména v načatém řádku.
Pokud bychom transponovali do sloupců, potkáme se asi také se stejným problémem. Předpokládám, že by 38 tisíc řádků ve sloupci A by musel každý obsahovat 40 záznamů, aby se to vešlo do listu a zřejmě to může postupně růst. Takže zbývají úvahy o zkrácení hlaviček na polovinu (zkrátit ze 4 na 3 ani tak nestačí bylo by to 1131 sloupců).
Prakticky zbývá jen zkrácení hlaviček na dvě položky. To by stačilo až na 511 stejných záznamů, nebo pokračovat na dalším řádku (což je vlastně duplicita, které se chcete vyhnout). Navíc by se značně zpomalilo makro dík formátům, ale něco bych určitě odladil. Bohu žel se změnami verzí nemusí formátovaná čísla fungovat stejně dobře, což se projeví třeba za pár let (doufejme, že nikdy).
Takže je na Vás jakou zvolíte koncepci.
]]>Vyskočilo hlášení s číslem 377 a následně stejná chyba (chyba_2a.jpg)
https://drive.google.com/file/d/1d3rKPu … sp=sharing
Vzhledem k tomu, že do originálního souboru "Cenik_sloupce_úprava3.ods" jsem jsem nakopíroval do listu "vstup" pouze nová data od ř. 2, opravil hlavičku makra dle doporučení, výsledek byl tento:
20 tis. řádků - chyba 2a;
15 tis. řádků - makro proběhne;
jsem začal hledat jinde a napadlo mě zkontrolovat verzi SW.
Měl jsem LibreOffice v. 7.3.0.3 (progresivní) a tak jsem ji nahradil v. 7.2.6.2 (stabilní)
Makro u 20 tis. řádků nyní proběhne, ale u 38 tis. řádků se objeví stejná chyba.
Nechápu.
Sub hlavicka(ByVal opak as long) 'původně integer
který přepište tak jak je uvedeno - tedy původní integer přepište na long.
Proměnná je ve zdrojovém makru deklarována jako long. Předává se voláním a je to ten "opak" as integer, což je pře deklarování (moje chyba). Přesto když to chodí u mne, tak funguje také pro hodnoty do velikosti "integer" - tedy cca do 32000 (- proto Vám to původní makro vypadlo při počtu 38 tisíc). Ale hlavička je jen v řádku, který má maximálně 1024 buněk (sloupců) a přetéct by to nemělo ani náhodou.
Jedinou možností je, že počet opakování jedné proměnné je 256 řádků (nebo více). Potom by přetekl list.
Otestujte to takto :
Sub hlavicka(ByVal opak as long)
print opak
Jednoduše print opak napište hned do prvního řádku. Spusťte makro a vyskočí Vám hlášení, které musí být číslem menším, nežli 1023 - jinak je to právě příčina přetečení indexu sloupce.
Ale pokud to není tato chyba (když to chodí u mne u Vás by mělo také), tak nevidím na Vašem obrázku něco co ukazuje, že je chybně index (.IndexOutOfBoundsException) => index mimo rozsah nelze akceptovat. Jde tedy nejspíš o číslo listu, které by mělo být (1), ale to nevidím přes hlášku která to překrývá.
Pokud jste opravoval makro v živém sešitě, udělal jste možná chybu. V takovém případě bych doporučil nakopírovat všechna makra (celý obsah modulule1) do knihovny v živém sešitě. Pokud jste něco doplňoval, použijte kopii v novém modulu a ten potom porovnejte řádek po řádku.
]]>Zrychlení makra není nutné. I kdybych to dělal 1x denně, ušetří mi to spoustu času.
]]>Otestujte a dejte vědět zda je to v pořádku. Dále uvádíte, že makro běželo cca 2 minuty při cca 25% řádků. To znamená, že celý (nezkrácený) soubor by měl měl běžet cca 6 až 8 minut. To je hodně, ale jde spíš o to, jak často se takové operace dělají. Pokud je to jednorázový účel - nemá to cenu zrychlovat. Pokud se to dělá denně, nebo alespoň "často" v uvedeném rozsahu desítek tisíc, tak by to bylo zralé na zrychlení. Dejte vědět.
]]>