Pole a podmínky a Vstupní seznam

Trambus · 2. 10. 2020 08:43:33

Zdravím všechny,

poprosil bych zkušenější o radu ve Writeru.

1. Mám kmenový dokument ve kterém je vstupní seznam s pár hodnotama. Chci vytvořit nový dokument, kde bych rád použil vstupní seznam z kmenového dokumentu tím způsobem, že se na něj odkážu a dále s ním pracoval jako se samostatným vstupním seznamem (v podstatě duplikát). DDE odkaz není to pravé ořechové podle mě.

2. Podmínky. V kmenovém dokumentu mám různá pole (nastavit proměnou a pak zobrazuju proměné). Lze další (nevím jaký typ) pole zapodmínkovat? Např. pole s názvem Ovoce mám s hodnotou "Jablka". Další pole s názvem Barva by určovalo, že pokud je pole s názvem Ovoce "Jablka" tak pole Barva bude "červená". Prostě funkce IF, ale neumím to zasadit do Writeru. Makrem?

Děkuju, snad je to pochopitelné, ono se to snadno píše, ale pokud by byl potřeba vzor, vytvořím. Vytváření databáze v Base bych se v rámci jednoduchosti rád vyhnul.

Děkuju Vám.

Pavel

Editoval Trambus (2. 10. 2020 08:43:58)

kamlan · 2. 10. 2020 11:31:16

Co jsem zatím objevil tak jinak než makry mi to nešlo. Vzorce ve Writeru umožňují primitivní podmínku která umí vypsat akorát 0 nebo 1 podle toho zda se rovná či nerovná vstup něčemu, ale neumí vypsat uživatelem definovaný výstup, nebo to prostě neumím.
Co se týká makra tak ty Vstupní seznamy jsou v dokumentu jakožto položky TextField, a k těm textfieldům se trochu hůř přistupuje, musí se to procházet v enumerační smyčce a kontrolovat podle názvu toho vstupního pole. Takto se dá dostat k potřebnému Vstupnímu poli. Pomocí fce SelectedItem se pozná jaká položka je v tom poli vybraná a tou samou vlastností se dá nastavit (kdyžtak xrayovat proměnnou oField).

Po tom zkopírování to chce vybrat hodnotu, což se mi nepodařilo odstranit. Takže makrem se dá Vstupní seznam zkopírovat a stejně tak se dá zjistit jaká hodnota je vybraná a pak třeba podle toho změnit jiný seznam, to jsem zatím nedodělával.

Ukázka zde: https://uloz.to/file/LfLUWddjuJPZ/jedno … seznam-odt

neutr · 3. 10. 2020 09:48:38

Posílám šablonu dokumentu kde by se měl uživatel zorientovat. Připouštím, že práce s poli je veliký nesmysl už z principu. Kdysi to chodilo téměř dokonale, ale nyní je stav této funkcionality popsatelný jen expresivními výrazy : -(

Šablona je zde Test podmínky a seznamy

Ad 1 :- Prakticky všechna pole (nejen seznamy) jsou příznačná pouze pro individuální dokument - jsou prakticky nepřenositelná v rámci jiného dokumentu. Jedinou výjimkou jsou šablony, ale i zde musíme vědět, že pole musí mít aktivní položku v dokumentu jinak se nedají použít. Většinou se zcela ztratí. Některé "proměnné" si zachovají "master" (v praxi jde o název pole), ale ten se nedá použít pokud nemá "aktivní slave" (vlastní hodnotu).

Někdy lze zajistit existenci samotného "masteru" a sice v případě že tělo dokumentu obsahuje prázdné "slave", ale ne všechny typy polí tohle umožňují.

Šablona by v praxi měla být otevírána s volbou ZOBRAZIT > NÁZVY POLÍ, aby uživatel věděl co má k dispozici. Jen opakuji že šablona vždy musí něco málo obsahovat, tedy v případě seznamu jedno z hesel (doporučuji na první místo umístit něco jako „Vyber zde"…..).

Vložené pole musíte okamžitě uložit – jinak se ztratí. Teoreticky by všechna pole měla jít exportovat do PDF – ale zda fungují stejně jsem nezkoušel – jde o volbu typu PDF.

V nápovědě jsou staré údaje. Například podmínka funguje na „nulu" = True. Původně to byla jednička. Je možné, že se změnila i původní syntaxe. Možná se už nemusí vypisovat ani to, že podmínka je True. Logicky totiž stačí že je výraz v kolonce „podmínka" – a tím pádem je vždy pravdivá. Je toho ale více a já jsem polím už věnoval hodně času. Dnes mne to spíš irituje.
Původní funkcionality spočívající na podmínce (skryté texty) fungovaly hned jak se podmínka splnila, nebo nesplnila. Nyní to vypadá, že se musí aktualizovat dokument a i tak se stane, že pokud je původně podmínka splněna („Slave" je vidět) a podmíněný výraz smažeme – „slave se ani nehne" i když by mělo zmizet. Připouštím, že to může být v současnosti koncipováno úplně jinak, ale už nemám ani chuť ani čas študovat jestli je to chyba systému nebo uživatele.

Některé věci chodí docela obstojně – například uživatelské proměnné pole databáze, čísla stránek, názvy kapitol apod., ale to je nedostatečné.

Trambus · 5. 10. 2020 10:12:34

Děkuju pánové za pomoc, očividně je to složitější než jsem si myslel a řešení, které by bylo uživatelsky jednoduché ještě není v rámci Libre k dispozici. Já si ty pole hodně oblíbil, pracuju s nima rád, dost mi usnadňují práci.

Možná by nakonec stačila jedna věc:
Jak by vypadalo makro, které by řeklo - IF pole z názvem ovoce = jablka THEN pole z názvem barva = červené

Tohle by šlo v mém případě trošku rozvinout :-)

Děkuju!!!

neutr · 5. 10. 2020 15:51:39

Makro není problém - zítra ho pošlu. Jen potřebuji vědět, zda má to makro pracovat v relaci na seznam, nebo obyčejné uživatelské pole.

kamlan · 5. 10. 2020 17:15:56

Tak tady je to makrem https://uloz.to/file/hFmFHUfUjEkV/podmi … a-pole-odt, když vyberete hodnotu z toho prvního řádku ze vstupního seznamu, tak pak z menu PODMÍNKY spusťte makro podminky nebo klikněte na ohraničené pole makro a ono se vám to přenastaví.

V makru podminky je nutné zadávat o jaký druh pole se jedná což je trochu uživatelsky nepříjemné, ale umožňuje to mít různé druhy polí stejně pojmenované. V případě že byste byl ochoten mít všelijaká pole pojmenovaná jen unikátními názvy, tak by se to bez těch běžněUživatelských šílenosti "com.sun.start.text...." obešlo :-). Zatím je to na uživatelská pole a vstupní seznam, pokud byste do toho potřeboval zahrnout vícero druhů těch polí, tak by se mi hodil nejlépe dokument s ukázkou všech těch druhů polí. Ono každé to pole má totiž trochu jinou API strukturu a k vlastnostem jak se jmenuje nebo co obsahuje se tedy přistupuje trochu jinak - a nechce se mi xrayovat a zkoušet struktury které třeba ani nepoužíváte.

V jeden okamžik když jsem zkoušel měnit položky v tom vstupním seznamu tak mi to pak makro nepřenastavilo ale začlo to fungovat až po uložení souboru. Nevím jestli jsem něco dělal blbě nebo to mohla být chyba Libre. Ale více jsem to nezkoušel. Takže když makro nebude chodit, zkuste uložit dokument i Nástroje/ Aktualizovat vše.

neutr · 6. 10. 2020 07:55:38

pro kamlan :
Nemyslím si, že je Vámi uvedené řešení správné. Autor poptával :
ad 1. seznam - respektive přenos hodnot do jiných sešitů.
ad 2. Podmínky. V kmenovém dokumentu mám různá pole (nastavit proměnou a pak zobrazuju proměnné). Lze další (nevím jaký typ) pole zapodmínkovat? Např. pole s názvem Ovoce mám s hodnotou "Jablka". Další pole s názvem Barva by určovalo, že pokud je pole s názvem Ovoce "Jablka" tak pole Barva bude "červená". Prostě funkce IF, ale neumím to zasadit do Writeru. Makrem?

Ta jednička je myslím jasná. Druhý dotaz je složitější. Autor poptává podmínku, respektive skrytý a tím pádem také skrývaný text. Volně řečeno "něco jako heslo vypíšu do dokumentu a následkem toho se objeví skrytý text". Tedy když to bude pod podmínkou, mělo by se to nejen zobrazovat, ale také skrývat a sice bez záměrné aktualizace.

Původní funkcionalita nezávisela na "poli jako takovém", ale na tom, zda text na stránce obsahoval podmínku (kdekoliv a to i za polem které "se vyplnilo textem" když před tím bylo jen šedivým svislítkem.
Autor v posledním příspěvku upřesnil, že podmínka se váže na určité pole (ovoce, barva) a plnění ukrývaného textu by mělo být v jiném poli. Jde mu tedy o relaci mezi dvěma poli ve vícenásobné verzi řešení. To, že by primárním polem měl být seznam jsem tak nějak spíš odhadl, ale moc přesvědčený nejsem.

Skrývaný text je prakticky krypto-logická, nebo spíš steganografická záležitost. Původní záměr byl zřejmě v tom, aby skrytý text četli jen oprávněné osoby. Například v dialogu "Pole" (Ctrl+F2) je karta DOKUMENT, s položkou ODESILATEL, která obsahuje korporativní údaje (Společnost, jméno, příjmení, obec ap.) Tyto údaje se načítají z údajů pod položkou NÁSTROJE > MOŽNOSTI > UŽIVATELSKÉ ÚDAJE > ...
Takže když autor umístí pole typu, společnost (a třeba další - jméno příjmení,...) tak se uživateli automaticky zobrazí skrytý text. Pokud uživatel otevírá z jiného, nežli oprávněného stroje - má smůlu - dostane kamuflovaný text.
Snadno lze použít "heslo", tedy údaj který aktivuje skrytý text a při tom "heslo" není součástí dokumentu. Samozřejmě to je asi prapůvod. Prakticky půjde o relevantnost podle cílové skupiny. Jsou - li cílovou skupinou instalatéři dostanou jiný termín nežli elektrikáři, nebo pokrývači. Autor může pro všechny skupiny vytvořit stejný dokument a pomocí polí odfiltrovat relevantní informaci (irelevantní informace nejsou sice tajné, ale cílovou skupinu nezajímají.

kamlan · 6. 10. 2020 10:06:49

pro neutr:
ta má druhá ukázka je čistě na Trambusovo upřesnění

Trambus napsal(a)

Jak by vypadalo makro, které by řeklo - IF pole z názvem ovoce = jablka THEN pole z názvem barva = červené

A makro podminky je ukázka jak takové makro může vypadat :-) -> s popsáním problému se stejnými názvy různých polí a potřebě při stejných názvech různých polí zadávat i druh pole ze kterého se má zjišťovat hodnota.

Kdyby šlo v těch podmínkách pro třeba ten skrytý text zjistit jaké hodnoty obsahují složitější pole jako vstupní seznam + kdyby šlo do těch podmínek zadat vícero IF něco THEN, tak by myslím nebylo potřeba zkoušet to makrem.

Ten přenos do jiných sešitů jste myslím nejlépe ukázal tou šablonou, makrem to elegantněji nepůjde, neb při přidání něčeho nového (třeba nějak netypického) by také mohlo dojít k tomu, že kopírovací makro které to pole označí přes pohyb kurzoru o jeden krok vpravo, by mohlo na něčem co nepůjde označit jen tím jedním krokem, spáchat neplechu. A označit nějaký ten TextField přes metodu oDoc.CurrentController.Select() mi nefungovalo.

Jinak já vůbec nepřemýšlel nad tím k čemu to autor potřebuje, jestli odfiltrovat nějaká skrytá firemní data nebo třeba skrýt nějaká irelevantní.

V případě toho firemního tutlání bych se na to hned vybodl a vůbec se tomu nevěnoval - podle mě je to ztráta času, zkomplikovávání si života které nelze nijak vykompenzovat ani vynahradit, a jen se čím dál horší motání se v něčem co rozvoji zdravého rozumu skutečně neprospívá.

V případě nijak neheslovaného "skrytí" těch irelevantních dat na Vašem příkladu aby třeba něco elektrikářského nešlo zbytečně pokrývačům je to však zajímavé a jistě v různých případech užitečné

Mimochodem ještě jsem neznal slovo steganografie :-), koukl jsem na první definici co mi gůgl podšoupl https://wikisofia.cz/wiki/Steganografie a již ta definice mi přijde taková pološílená, též od něčeho takového dávám ruce pryč :-)

Editoval kamlan (6. 10. 2020 10:07:57)

Trambus · 6. 10. 2020 12:14:40

Pánové, mockrát děkuju, to v první řadě! Kamlanovo poslední řešení je opravdu asi to co jsem potřeboval, ještě to zkusím implementovat do těch mým skutečných dokumentů a dám vědět jak jsem pochodil.

Není v tom žádná složitost, žádná firemní data, nic takového. Opravdu mám pouze dokument (pár dokumentů), které dokola přepisuju a tím vznikají další a další dokumenty (stavařské projekty - technické zprávy, průvodní zprávy apod.) Do placu to dát ale nemůžu, přeci jenom malé know-how v tom mám Neutr ví, tomu jsem to již soukromě jednou posílal, pokud by chtěl Kamlan nahlédnout - pošlu.

Každopádně opravdu děkuju. Já večer zkusím ty podmínky na vstupní seznam a pak dám vědět.

OpenOffice.cz - web věnovaný kancelářským balíkům OpenOffice.org

#1 2. 10. 2020 08:43:33

Pole a podmínky a Vstupní seznam

#2 2. 10. 2020 11:31:16

Re: Pole a podmínky a Vstupní seznam

#3 3. 10. 2020 09:48:38

Re: Pole a podmínky a Vstupní seznam

#4 5. 10. 2020 10:12:34

Re: Pole a podmínky a Vstupní seznam

#5 5. 10. 2020 15:51:39

Re: Pole a podmínky a Vstupní seznam

#6 5. 10. 2020 17:15:56

Re: Pole a podmínky a Vstupní seznam

#7 6. 10. 2020 07:55:38

Re: Pole a podmínky a Vstupní seznam

#8 6. 10. 2020 10:06:49

Re: Pole a podmínky a Vstupní seznam

#9 6. 10. 2020 12:14:40

Re: Pole a podmínky a Vstupní seznam

Zápatí