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É