Fórum pro uživatele kancelářského balíku OpenOffice | LibreOffice
 

#1 23. 8. 2018 09:14:35

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Problémy s programováním v LO 6.0.6.2 pod Windows 10

Konkrétní sestava Verze: 6.0.6.2 (x64)
ID sestavení: 0c292870b25a325b5ed35f6b45599d2ea4458e77
Vlákna CPU: 2; OS: Windows 7 a další stroj Windows 10; Vykreslování UI: výchozí - bez akcelerace;
Národní prostředí: cs-CZ (cs_CZ)
     S Windows 10 jsem celkem málo obeznámený ale dělám na projektu kde je nutné pracovat s tím co dům dal - tedy Windows 10. Celkem s hrůzou jsem zjistil nestandardní chování IDE, respektive maker. Problémů je více druhů. Docela mne dostávají 2 okruhy problematiky.


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.

Editoval neutr (23. 8. 2018 09:20:26)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#2 23. 8. 2018 13:52:37

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Ad. B2 - ve Writeru vybírám pomocí TextCursor a mažu mnohdy tak, že dám kurzoru prázdný řetězec oCur.string="". Možná by něco podobného šlo i v Calcu, jestli má také vlastnost string pro vybraný obsah, tak mu dát prázdný řetězec "". Malý příklad co zkopíruje ve Writeru vše z aktuálního dokumentu přes getTransferable() a obsah smázne prázdným řetězcem.

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.

Editoval kamlan (23. 8. 2018 13:53:54)

Offline

#3 23. 8. 2018 16:49:07

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Děkuji za reakci.
     Ano máte asi pravdu. Windows 10 není nejšťastnější volbou, ale podmínky projektu (výši a rozpad nákladů) zadávala fakulta. Mohlo mne napadnout, že na hmotný majetek bude minimum - asi proto aby šlo pouze o majetek který se dá okamžitě odepsat. Na služby je 4x více. Takže jsem musel změnit koncepci a pracovat s tím co je k dispozici.


     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 :

neutr napsal(a)

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.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#4 23. 8. 2018 19:52:47

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Jedu sice na Libre 6.1 win7, ale to mazání tím kurzorovým vložením prázdného řetězce mi fungovalo myslím už v 5.x. Prostě vytvořím ten textový kurzor, roztáhnu ho na to co chci smazat a tím přiřazením mu prázdného řetězce smaže i objekty v tom.

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ší.

Offline

#5 23. 8. 2018 20:00:17

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Ještě mě napadlo když nejde Del tak zkusit Bksp :-). Doufám že tím UNO myslíte to co já, tedy následující.


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

Offline

#6 24. 8. 2018 08:46:20

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Dnes jsem na stroji s W10 a testuji od rána - zatím bez úspěchu. Hodně jsem si sliboval od BackSpace (to mne nikdy nenapadlo) ale bohu žel. Tady mi nefunguje žádný příkaz UNO. Asi budu muset mazat znak po znaku slovo od slova a když se objeví objekt tak ho také odstraním. Mělo by to jít lépe.

Ale děkuji za podněty.

Editoval neutr (24. 8. 2018 08:49:12)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#7 24. 8. 2018 11:34:09

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Nemohl by být problém ještě s přepnutím zpět do zdrojového okna? Ze zdroje když to nakopírujete do schránky, tak se musíte přepnout na cílové okno a tam to ze schránky vložit a poté se přepnout zase na okno zdroje a udělat to smáznutí. Kdyby se to pod těmi win10 nepřeplo zpět do toho zdrojového okna, tak by bylo logické, že nebude fungovat žádný UNO příkaz.

Offline

#8 24. 8. 2018 14:28:06

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Ne tohle jsem testoval jako první. Klasicky vykopíruji makrem které je podobné s tím které jste posílal. Jde jen o to že start je na poslední záložce a konec je End vždy (ukusuje se od konce). Každý krok vytvoří 1 soubor v prvním případě (první - tedy poslední startovní žáložka) jsem měl otevřeny 3 soubory současně. Takže zde to hrozilo a tak jsem dával pozor abych to udělal sprvně.
     První najetí je po restartu LO a zdrojový Writer do Calcu vygeneroval seznam záložek, stránku na které se tato nachází a její text. Takže když byla nejeta poslední záložka bez váhání jsem ji použil k vygenerování prvního výstupu. Následně jsem Calc uložil a zavřel a zůstal otevřený pouze zdroj a první výstup. Při tom jsem se musel vrátit do zdroje a smazat poslední záložku a nakonec skočit na začátek dokumentu.
     To se také jakoby provedlo, ale zdroj se mi sekal - ale byl uložen. Po manuálním zadání obnovit jsem musel kliknout do textu a kurzor skočil na začátek (je tam tlačítko start). Toto bylo vše v UNO. Takže poslední příkaz s po obnově provedl ale ty ostatní nikoliv. Přepsal jsem skok na začátek do Basicu a nechal jako poslední UNO DELETE - to se ale neprovedlo.
     Následně jsem to přepsal (v té době mi vyskakovaly chyby z hlavního adresáře. Od té doby jsem změnil to, že první výstup dělám až po restartu a strukturu jsem testoval na přepínání bez provádění operací kopírování a mazání (přeskakoval jsem je. Takže tohle chodí.


     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.

Editoval neutr (24. 8. 2018 14:33:55)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#9 24. 8. 2018 15:36:33

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Problémy s programováním v LO 6.0.6.2 pod Windows 10

Uf. Jestli je to takhle velký a pestrý, tak to se tomu bučusu nedivím. To než se vše zkopíruje či zapracuje do paměti a grafiky atd., tak to může trvat pěkně dlouho a přitom se to ještě při zpracovávání falešně tvářit, že to je hotovo aniž by bylo.


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í.

Offline

Zápatí