Mně se stávalo, že když jsem zpracovával hodně velký texty (pdf něco přes 700 stran a v tom tučnost a kurzíva kterou jsem musel zachovat) tak jsem to pdf ve FoxitReaderu označil Ctrl+A a pak Ctrl+C (což již trvalo nějakých pár minut na mém starém laptopu) a do editoru PSPad jsem to vložil jako HTML -> taky to vkládalo pár minut + ale nějak poté, co se to konečně tvářilo již plně vložený, jsem beztak ještě musel chvíli čekat, než to skutečně bylo zapracovaný celý. Poznal jsem to podle toho, že jsem roloval kolečkem myši v PSPadu a když se rolování už nesekalo, tak to teprve bylo skutečně zpracovaný programem celý.
To samý mi dělají pestrý dokumenty v Libre. Když otevřu větší dokument ve kterým mám velmi pestrý formátování, tak on se načte a zobrazí, ale až když jím mohu v klidu plynule rolovat kolečkem myši (a neseká se ani rolování) tak vím, že to Libre (či grafická karta? či systém?) má zapracovaný skutečně celý. Takže v případě maker bych se nedivil, kdyby se provádělo makro ale něco z obsáhlýho dokumentu prostě ještě nebylo někde zpracovaný.
Ale alespoň uvolnit tu schránku by mělo jít jednoduše tak, že se do ní prostě nakopíruje něco dalšího a pouze malýho, což je asi jednodušší než ji zkoušet nějak vymazat. Problém by mohlo být kdyby tam byla nějak zaznamenávána historie schránky, třeba nějakým dalším programem, což ale asi není.
]]> Ještě jsem měl asi napsat že zdroj má 245 stran a je to výstup z Finereader 14. Po výstupu obsahuje původní zdroj docx skrytá pole (licencovaného PDF), dále plno obrázků (mimo jiné v každém záhlaví), a "shape" které nelze identifikovat - jsou to jen prázdné obdélníčky - ale jestli to byla textová pole, nebo nějaký typ rámců nevím. Výstup obsahuje i několik sekcí. Takže tyto nežádoucí "shape, sekce a anchory" jsem manuálně odstranil abych vyloučil vliv na makra. Bez výsledku.
Objem může mít vliv proto se pídím po uvolnění schránky. Přes to že se zdroj seká v určitém okamžiku, tak nepadá. Bude to nějaká chybička podobně jako s těmi URL. Dnes se ještě podívám jestli by to nešlo obejít službou obsluhy kláves z OS. Tam nešlo pouze vybavit klávesy ENTER a ESC i když i na to jsem našel návod - ale stačí to DELETE. Jako poslední bych přistoupil k mazání cyklem - separátně po opětovném načtení zdroje. Ale musí to jít lépe.
Pro kontrolu výstupů použiji ještě makro které původní zdroj z MS rozseká na jednotlivé stránky které se budou volat klikačkou k jednotlivým záložkám pro kontrolu (- zpětná návaznost na zdrojový text jako číslo stránky a řádek). Tohle je převzatý systém, který funguje dobře dík tomu, že odděluje celé stránky. Ale přizpůsobovat ho k oddělení záložek (nebo speciálních polí) dost dobře nelze. Záložky často přechází ze stránky na stránku, nebo jsou 2 i více na jedné stránce.
Moc lidí toto nezajímá, mimo toho oficiální zdroje prakticky tuto stránku používání nereflektují. Takže snad to pomůže i někomu jinému.
]]>Ale děkuji za podněty.
]]>sub pokus
dim document, dispatcher
document=ThisComponent.CurrentController.Frame
dispatcher=createUnoService("com.sun.star.frame.DispatchHelper")
dispatcher.executeDispatch(document, ".uno:Delete", "", 0, Array()) 'del
dispatcher.executeDispatch(document, ".uno:SwBackspace", "", 0, Array()) 'bksp
end sub
Kopírovat přes schránku je spíš nespolehlivé, přes to getTransferable() je to záležitostí Libre a i když třeba mezi Calcem a Writerem neskopíruje úplně všechno formátování, nemělo by to dělat problémy při různých OS. Je fakt že přes tu schránku je to ale asi rychlejší.
]]> Mezi tím jsem přišel na to, že některé chyby se dají řešit důsledným dopracováním generovaných souborů. To jsem zjistil v souvislosti s načítáním URL z nadřazené knihovny. Podivné chování to je. Soubory jsou vygenerovány ale nespouštějí se. Přes to vyskočí chyba tam kde to nečekám. Postupně jak ladím výstupy tak dopíšu něco co má syntaktickou chybu. Místo toho aby se objevila chyba v místě po spuštění vyskočí hlášení "unsupported<>" již při generování chyby - já jsem na to přišel asi před hodinou. Vždy jsem se vrátil k chybě načítání v hlavní knihovně - tedy stále je co se učit :-(
Možnost mazat text ve Writeru (opravdu se jedná o Writer nikoliv o Calc) jsem uváděl :
B2. - Podobné je to s některými makry které ale nestabilitu vykazovaly již dříve (i na Ubuntu). Například celkem snadno vyberu a zkopíruji obsah části textu od poslední záložky do konce dokumentu, vytvořím nový sešit, obsah tam uložím (vše je OK i s uložením). Ale nyní potřebuji zkopírovanou část ve zdrojovém sešitě smazat (je stále vybrána jako select a smazat ji mohu až po uložení kopie). Vím z minulosti, že čistý Basic uměl smazat jenom text (nikoliv objekty ap.)
Právě proto jsem používal UNO, které vyjme vše pomocí CUT, ale já bych potřeboval DELETE. Přímo naroubované UNO mi způsobuje zamrznutí což Linux také nedělal. Tuto část bych měl mít do září tak snad najdu řešení zatím používám obnovu makrem, ale to potřebuje hodně času a stejně musí uživatel kliknout do sešitu zdroje. To znamená uspané obnovování obrazovky. Obávám se toho, že chyby které jsou na W7 budou jiné na W10 a tak používám 2 počítače. Při tom pracovat to bude také na jiné mašině a mělo by to pracovat na W10 vždy.
Tohle projekt neřeší, ale byla by to fušeřina když by se muselo ladit na každé různé mašině. Takže až dodělám verzi pro W10 upravím to pro Linux jenže až se k tomu dostanu. Nyní mne trápí nejvíc ta schránka. Tam je problém s tím, že služby pro clipboard poskytuje OS. Mám staženo vše co se týká schránky service ClipboardManager ale je to psané pro AOO 4.1.5 a LO to může mít jinak i když je to často shodné. Přes to je to cesta která nemusí vést k úspěchu právě kvůli OS. UNO by mělo spolupracovat s každým OS ale právě podle DELETE vidím, že to nefunguje.
Ještě jednou děkuji za reakci.
]]>sub kopirujAsmaz
dim oDoc, oCur, kopirovane
oDoc=thisComponent
oCur=oDoc.text.createTextCursor() 'textový kurzor
oCur.goToStart(false) 'kurzor na začátek dokumentu
oCur.goToEnd(true) 'kurzor na konec s kurzorovým označením
oDoc.CurrentController.select(oCur) 'označí viditelně kurzor
kopirovane=oDoc.CurrentController.getTransferable() 'zkopíruje
oCur.string="" 'prázný řetězec na celý kurzor čili v podstatě Del
end sub
Pokud umožňuje kopírování do schránky pouze přes "Cut", tak bych schránku uvolnil tak, že bych do ní po zkopírování potřebného ještě zkopíroval prázdný řetězec nebo třeba jenom poslední písmenko.
Víc bohužel nevím. Podle mně to budou chyby Win10 a netuším, zda-li by pomohlo je v nejhorším celý přeinstalovat, ale myslím si, že ne. Generovat knihovny maker přímo ze sešitu a chtít aby to pod Win hladce jelo - vzhledem k tomu jak si tvůrci Windows od první verze libují v tom, že se při jakékoliv trochu důležitější změně musí samotný Win restartovat a nejsou schopný s pamětí a jejím všelijakým měněním pěkně dynamicky pracovat, bych v to, že to budou zvládat jednotlivý programy (a navíc že jim to vydrží i přes všelijaký aktualizace) vůbec nedoufal.
Než ty knihovny tedy vytvářet a spouštět ze sešitu, tak by zřejmě bylo spolehlivější z nich radši udělat doplněk.
]]>A. - Jedním sešitem Calc vygeneruji hlavní knihovnu v Moje Makra a dialogy Standard, následuje vygenerování procovního zdroje Writer. Pracovní zdroj Writer generuje výstupy Writer které také obsahují makra.
Po vygenerování nelze makra v čerstvých souborech spustit. Musí se vše nejprve restartovat jako celý systém LO. Potom už "fungují" i když ne vždy tak jak fungují na Linuxu. Není to nyní tak frekventovaný problém, protože generátor (Calc) se spouští pouze na začátku a pak už dostává jen reporty jako skrytý i když i zde je problém viz B1.
B1. - Tento problém je mnohem horší a jedná se asi o více záležitostí. Makra pro Writer fungují podle počasí. Neznám důvod proč konstantně vygenerované adresy URL (v hlavní knihovně) vícekrát za sebou fungují a potom se z nějakáho důvodu objeví hláška že jsou unsupported <>. Nejprve jsem adresy vytvářel jako PUBLIC Function - tehdy jsem zjistil poprvé takové chování. Otestoval jsem Tedy deklarace GLOBAL Function. Totéž v modrém. Chvíli to chodilo a potom opět "nepodporováno".
Původně jsem zadával adresy jako file///:, když to nefungovalo otestoval jsem adresy typu C\:. Neměl by v tom být rozdíl jde jen o to zda zadám MyURL = oDoc.URL, nebo MyURL = ConvertFromURL(oDoc.URL). Druhý případ je méně výhodný protože se musí zpětně konvertovat pomocí ConvertToURL(MyURL).
Testoval jsem například samostatně makro (které je normálně součástí řetězených Subroutine a Function) po vzniklé chybě. A vše v pořádku - normálně se provedlo. Nastavil jsem dost dlouhé časy (vteřiny) mezi jednotlivými procedurami - ale také to nepomohlo.
B2. - Podobné je to s některými makry které ale nestabilitu vykazovaly již dříve (i na Ubuntu). Například celkem snadno vyberu a zkopíruji obsah části textu od poslední záložky do konce dokumentu, vytvořím nový sešit, obsah tam uložím (vše je OK i s uložením). Ale nyní potřebuji zkopírovanou část ve zdrojovém sešitě smazat (je stále vybrána jako select a smazat ji mohu až po uložení kopie). Vím z minulosti, že čistý Basic uměl smazat jenom text (nikoliv objekty ap.) Proto jsem používal UNO, ale to mi už také nefunguje. Tedy musím upřesnit že funguje příkaz "Cut", ale nikoliv "Pasete", nebo "DELETE". Takže místo smazání skutečně vyselektovaný obsah vystříhnu (zůstane ve chránce). To je jediné řešení na které jsem přišel, ale jde o průšvih s obsahem schránky.
Nevím jestli někdo zná odpovědi, ale pomohlo by mi například uvolnění a smazání obsahu schránky například pomocí Shellu přímo, nebo zavoláním nějaké externí rutiny - v rámci OS. Podobně možná exituje řešení pro pro blokaci podle bodu A. Nevím jestli je to dáno OS, nebo LO, ale domnívám se že to dělají desítky.
Předem díky za ochotu.
]]>