neutr: O Štítcích jsem vůbec netušil a musel bych se s nimi naučit, což by bylo na déle než ten postup přes html :-). Nicméně včera večer už jsem byl přetaženej a tak jsem se na třeba pokus o odstranění těch zalomení stránek makrem už nevzmohl, kdežto s html docela umím (vysvětleno dále). Dnes jsem byl úspěšnější, ukázkový spoubor zde https://uloz.to/file/UBpFCI4aH843/tabul … navodu-odt. Jinak makro z něj tady
Sub odstranitZalomeniStranekVtabulkach
rem odstraní zalomení stránek která jsou dána nastavením vlastností tabulek
rem v Tabulka/ Vlastnosti -> Tok textu/ Rozpojit
dim oDoc, oTables, oTable, i%
oDoc=thisComponent
oTables=oDoc.TextTables
for i=0 to oTables.count-1 'procházet tabulky
oTable=oTables(i) 'tabulka
rem tohle odstraní to zalomení stránek
oTable.breakType=0 : oTable.pageDescName=""
next i
End Sub
Při vkládání makrem pod tabulku možná ani není potřeba vkládat řádek, stačí nastavit spodní okraj tabulky
Sub tabulkaOdsazeniSpodku
dim oDoc, otext, i%, oTable
oDoc=StarDesktop.LoadComponentFromUrl("private:factory/swriter", "_blank", 0, array()) 'nový soubor Writeru jako neviditelný
oText=oDoc.text
for i=0 to 1
oTable=oDoc.createInstance("com.sun.star.text.TextTable") 'vytvářená tabulka ve Writeru
oTable.initialize(2,2) '2 řádky, 2 sloupce
oText.insertTextContent(oText.getEnd(),oTable,false) 'vložit tabulku do dokumentu
oTable.setDataArray(Array(Array("aa","bb"), Array("cc","dd"))
oTable.bottomMargin=300 'mezera pod tabulkou
next i
End Sub
Chtělo by to v těch námi vytvořených makrech případně i nastavit, aby se tabulka nerozdělovala přes stránky a sloupce, ale to už nyní dělat nebudu.
K tomu redim preserve.
neutr napsal(a)To co je v kódu vedeno ukazuje na další proměnnou která v ukázce není definovaná. Ukazuje jak se dynamicky přidávají například property - tedy třeba celé array.
Jistě, pomocí redim preserve se dají dynamicky přidávat další proměnné, ale zmiňoval jste pod ukázkou "... respektive si naklonovat nějaký existující ..." a já myslel, že ta ukázku měla udělat i ono naklonování objektu s tím, že nově přidanému objektu se budou dát měnit vlastnosti aniž by to měnilo objekt vzorový - a to ta ukázka jak jsem ukázal neudělá -> přidá sice někam nějaký další prvek, ovšem při změně vlastností toho přidaného prvku se změní i vlastnosti vzorového prvku. Kdybych tam do toho x dal tu vytvořenou tabulku, a pak jí přidal tím postupem do y, tak při změně nějakého parametru v y by se mi to změnilo i v x, protože by to neudělalo modifikovatelný klon, ale pouze do dvou proměnných umístilo jedno a to samé, což by tedy měnilo stále jen první tabulku. Když jsou v tom poli jen jednoduché proměnné nafrkané tam z jiného pole, tak to redim preserve skutečně udělá klon těch jednoduchých proměnných.
Sub klon1 'naklonuje pole když jsou v něm jednoduché proměnné (tedy bez objektových struktur) (https://forum.openoffice.org/en/forum/viewtopic.php?f=21&t=93610)
dim x(2), y(2)
x=array("a","b","c")
y=x 'tohle neudělá nezávislou kopii pole
y(1)="Q"
msgbox x(1) & chr(13) & y(1) 'došlo sice ke změně v y, ale také v původním x
redim preserve y(ubound(y())) 'tohle už to pole osamostatní (udělá tedy modifikovatelný klon který již při změně vlastností nezmění vlastnosti v původním vzoru)
y(1)="W"
msgbox x(1) & chr(13) & y(1) 'došlo ke změně jen v y
End Sub
rem jenže 'osamostatnění' pole nefachá na objekty
Type tVzor
s$ i%
End Type
Sub klon2neAne 'nevytvoření modifikovatelné kopie objektu přes redim preserve
dim o1 as new tVzor, o2 as variant, x(2), y(2)
o1.s="abc" : o1.i=123
x(0)=o1 'dám objekt do pole
y=x 'dám pole do druhého pole
redim preserve y(2) 'zkusím fintu jako v proceduře klon1 o osamostatnění prvků pole
o2=y(0) 'dám do druhého objektu rádoby osamostatněný prvek pole
msgbox o1.s & o1.i & chr(13) & o2.s & o2.i 'o1 i o2 jsou stejné takže se to může jevit jako úspěšné zkopírování o1 do o2
o2.i=456 'změna o2
msgbox o1.s & o1.i & chr(13) & o2.s & o2.i 'o1 i o2 jsou opět stejné, takže o2 není klonem o1 ale jen redundantním o1
End Sub
kamlan napsal(a)Stačí v tom kódu co jste uvedl změnit nějakou vlastnost a změní se to u obou objektů.
neutr napsal(a)Ale v tom je to řešení právě výhodné
. Ale k čemu by mělo být výhodné mít ve dvou proměnných jedno a to samé? Nebo jinak, k čemu by mělo být výhodné mít duplicitní proměnné? Kdyby šlo o neblahý přístup typu samotných MS Windows "RAMky je přece dost!" tak jistě ano :-), ale jinak v tom smysl nějak nevidím. Možná jsem ale špatně pochopil vaše původní popsání.
neutr napsal(a)Správným řešením by bylo nastavení parametrů pro objekt vlastní tabulky a tu potom pouze replikovat.
Já si z tohoto vyvodil, že rychlejší by mohlo být udělat kopii proměnné oTable a ve smyčce for..next pak měnit pouze pár vlastností kopie namísto použitého vytváření pokaždé nové proměnné oTable=oDoc.createInstance("com.sun.star.text.TextTable") právě uvnitř for..next.
Jak jsme to udělali oba:
for ...
oTable=oDoc.createInstance("com.sun.star.text.TextTable")
...
oText.insertTextContent(oCurs, oTable, False)
next
Jak jsem si myslel že jste to urychlení myslel :-)
oTable=oDoc.createInstance("com.sun.star.text.TextTable")
oKOPIE=kopieObjektu(oTable)
for ...
oKOPIE.zmenNeco
oText.insertTextContent(oCurs, oKOPIE, False)
next
No a na vytvoření toho modifikovatelného klonu(kopie) oKOPIE jsem si myslel že zobrazujete právě tu ukázku Type FieldPairType .... Ale možná jsem ten váš myšlený postup blbě pochopil, nevím.
Tu kopii proměnné oTable z oTable=CreateInstance(...) se mi prostě vytvořit nepodařilo a možná to prostě možné není, neboť sám program Libre (zřejmě soffice.exe či soffice.bin) dle některých jejích částí něco vykonává a jistě by docházelo ke kolizím, kdyby se udělal nezávislý klon a v jedné z těch dvou verzí došlo k nějaké změně. Jak by se pak Libre mělo zachovat? Otevřít pro tu jednu změněnou verzi třeba úplně nový Writer? Či prostě druhou z verzí ignorovat? Nebo se snad ptát uživatele: "hele jsou dvě programátorský možnosti, kterou z nich si vybereš?"
Jinak co jsem ještě zjistil tak masivnější nasazení redim preserve dokáže být docela pomalé, ale to spíš jen tak pro zajímavost když jsem načítal data aniž bych věděl předem kolik jich bude a používal pro každý další načtený údaj redim preserve.
sub ee 'pomalé redim preserve
dim p(0), i%, a as date, a0 as date
a0=now
for i=0 to 10000 '10tis za 16 vteřin, 20tis již za 1:16
p(i)="text" & i
redim preserve p(i+1)
next i
a=now-a0
msgbox CStr(timeSerial(Hour(a),Minute(a),Second(a)))
end sub
No a co se týká vícerozměrných polí, tak já zkusil do pole načíst textový soubor který měl 23tis. řádků a když jsem je dal zobrazit v Kukátku, tak mi to zobrazilo že jsou správně načtené jen do indexu 16368 a od 16369 že jen neustále načítán jen první řádek. To samé se mi dělo když jsem zkusil různé pole polí array(array(...), array(...), ...), vždycky to načetlo správně jen těch 16369 řádků a tak jsem si chybně myslel, že tedy array má nějakou omezenou velikost. Jenže ono to načtení do pole očividně funguje dobře, ale Kukátko nejspíš holt zobrazuje špatně https://uloz.to/file/aSiRi8hV4Otk/chyba-png. Tudíž mé nadlimitní multiPole byl vlastně zbytečný výtvor :-). No ale alespoň vím, že v Kukátku je tedy zásadní chyba. Xray tolik proměnných nevypíše, krátí výpis dlouhých polí asi na 2000 řádků.
Já si vzpomněl jak to bylo s mým setDataArray a getDataArray :-). Narazil jsem na to když jsem se učil getTransferable na konci článku https://www.openoffice.cz/doplnky/kopirovani-dat , ale jelikož jsem tehdy nedělal v Calcu a měl jsem ho navíc z mně neznámých důvodů v nelibosti, tak jsem to tehdy spíše hrubě odmávl s tím, že o tom "vím" a že kdybych to potřeboval, tak se k tomu holt někdy vrátím. To byla chyba :-). Dnes už Calc mám ve velké oblibě.
Co se týká mého programování, tak sice se tomu věnuji od dětství, ale od opuštění škol ryze svérázně amatérsky. Začal jsem před 30-ti lety jako dítko chodit ještě do socialistického Domu dětí a mládeže na kroužek programování a co možná dějiny (ne)chtěly -> mohu dokonce tvrdit, že pár týdnů nato spadl celý systém :-); avšak nevnímám, že bych se na pádu tehdejšího systému jakkoliv podílel :-). No pak jsem vystudoval keply na elektroprůmce - ale nebylo to moc pokrokový, třeba praktickou maturu jsem měl v roce 1999 z instalace starších verzí Ms-Dosu, kde jsem z 5-ti disket instaloval a různě konfiguroval systémy ms-dos 3.0, 5.0 a 6.22. Na VŠ do mě začali bušit objekty, jenže já tam tehdy pochopil akorát ukazatele a dynamický proměnný a objekty už na mě byly moc těžký -> možná i tím, že jsem je krom školy nikde v ničem nepotřeboval a nebavilo mě to. Možná i tím, že tehdy jsme se pořád učili v Pascalu a nikde se v těch školách v daných předmětech neučilo žádné grafické API, tudíž mě programování ve kterém byl výstup maximálně někde do prostředí Dosu ani nebavilo. Ale dal jsem se na HTML/CSS/JavaScript/PHP a v tom si bastlil nějaký svý weby. Tehdy PHP taky objekty rozvinuté nemělo a na ty svý výtvory jsem to ani nepotřeboval. Takže někdy věci řeším tak, že to prostě dám do html a v tom to zpracovat umím.
K většímu využívání objektů se dostávám až teď (byť tedy v Libre Basicu) a teprve nyní tomu přicházím na chuť. Jenže neučím se nic nijak systematicky, třeba slovo instance ani nevím co znamená, já z oficiální programátorské terminologie vůbec znám velmi málo; a že něco je např. DLL v Javě, tak to jsem sice schopen pochopit, ale jinak s tím žádné zkušnosti nemám :-). Veškeré mé programování je v podstatě podřízeno vytváření mého transkripčního superbastlu, kde na to jdu většinou tak jak jsem to uměl ze škol + Javascriptu či PHP a kde si člověk pořád před lety musel vytvářet své funkce které vše dělaly krok po kroku (pokud si to nechtěl zpomalovat nějakými předtvořenými knihovnami ze kterých využil jen něco). Tudíž některé věci které někdo považuje třeba za "jasný učebnicový základ" nebo jak vy třeba nazýváte "typická práce v Calcu" ani neznám a jsem kolikrát velmi příjmeně překvapen, že Libre má všelijaké funkce které jednoduše udělají to, co by se jinde muselo dělat mnohem obsáhleji a ve více krocích.
.