DISKUSE
RTF Scrollbar (2)
21.01.2021 23:27

Export textu do hlavičky MS Word dokumentu pomocí ... (2)
21.01.2021 18:48

Nemá created (2)
09.01.2021 08:46

Problém s polem From v mailech posílaných přes SMT... (1)
30.11.2020 14:30

Agent log (1)
04.08.2020 13:17

Traveler se nepřipojí (2)
25.06.2020 08:20

Výběr lidí z AK tiskne jen 3 (2)
22.05.2020 07:41

Sametime 8.0.2 
20.05.2020 15:22


ŠKOLENÍ


REKLAMA


KOMENTÁŘE

Komentáře ke článku "OOP v Lotus Scriptu 3"


Jiří Plachý
15.01.2004 09:24
Finta FŇ
Vidím, že i po třech letech usilovného programování v LN se pořád mám co učit. OOP samozřejmě používám, ale o té fintě s ošetřením událostí jsem se dozvěděl až z článku. Díky

Vít Zachodil
10.02.2004 10:09
Pár praktických prostřehů a otázka ...
Přepisování událostí u UI objektů funguje celkem bez problémů v případě, pokud daná událost obsahuje kód napsaný v LS. Pokud je v ní kód např. ve formula jazyku, tak ho přemapovaný event nezmění - provede se původní formule.

Událost z uživatelské třídy, která přemapovává událost původního objektu, musí mít stejné parametry jako událost původního objektu.
Např. Sub SampleQueryOpen(Source As Notesuidocument, Mode As Integer, Isnewdoc As Variant, Continue As Variant).

"Remapující" objekt Sample asi musí být deklarovaný ve formuláři jako globální proměnná, aby existoval po celou dobu otevření formuláře (resp. UIdokumentu) a mohl "zachytávat" všechny jeho eventy.

Inicializaci objektu Sample je zřejmě možné provést až v události QueryOpen daného formuláře, protože v ní je zřejmě první příležitost pro předání objektu Source jako parametru pro konstruktor New třídy Sample. Což ovšem zřejmě znamená, že tuto událost formuláře nelze v objektu Sample přemapovat. Resp. lze ji v něm zadefinovat obdobně jako QuerySave, ale asi nikdy neproběhne (?).

Jsou i jiné možnosti, kde a jak v tomto případě daný remapující objekt třídy Sample deklarovat a inicializovat?

bubux
10.02.2004 21:16
ee...
ad1:?? muzete uvest priklad?
ad2:ANO
ad3:ANO
ad4:no tak to je finta fn pro zmenu od Lotusu...:) takze jak jiste vite formular ma dve moznosti deklaraci... prvni je jeste pred tim nez vubec formular jako objekt vznikne a druhy se uz primo vaze na form hned po jeho vzniku...
prvni - nejvrchnejsi tzv. (Globals) se pouziva asi nejvic.. tato sekce obsahuje i funkci inicializace... v teto sekci se Vam vsak nepodari uidoc inicializovat protoze jeste neexistuje...(to ma vsak svoje vyhody v jinych pripadech)
ve druhe sekci je to uz lepsi(je to pod udalosti queryclose formulare).. tam se vam podari objekt korektne inicializovat, dokonce i prepsat udalost query open... hacek je v tom ze tento kod funguje jenom pokud mate zapnuty debuger a krokujete...:( z toho jste urcite pochopil ze to mozne je jenom teoreticky.. :) mozna je tato chyba jiz v sestkach opravena ale typnul bych ze ne.. :) ono to totiz neni ani moc potreba protoze inicializaci muzete volat v queryopen a pod tim zavolat funkci queryopen ktera bude vracet parameter continue... takhle to delaji vsichni i lotusaci.. :) osobne vsak doufam ze se cela tato vec s podporou oop v lotusscriptu pohne smerem k lepsimu protoze bez oop to dal v lotusech nepujde pokud maji byt aplikace napsane profesionalne a lotusaci si to uvedomuji :)

Vít Zachodil
11.02.2004 09:23
Příklad ad1
U většina LS eventů ve formuláři je možné vybrat, jestli v nich má běžet LS nebo Formula. Když mi Váš příklad u nějaké staré testovací DB nefungoval, zjistil jsem, že event QuerySave v daném formuláři má nastavenu v poli "Run" hodnotu "Formula", která v programovacím okně obsahovala příkaz @Command([RefreshHideFormula]). Když jsem k ní přidal funkci @Prompt([OK]; "Event"; "QuerySave"), provedla se tato funkce a ne remapující skriptová metoda SampleQuerySave.
Z toho usuzuju, že remapování eventů v LS funguje, pokud je přepisovaný event přepsán eventem napsaným ve stejném programovacím prostředí a se stejnými parametry. Protože v LN v6 už je možné u některých eventů v poli "Run" vybrat i programovací nástroj "JavaScript" případně "Common JavaScript", předpokládám, že remapování takových eventů bude nutné dělat v odpovídajícím programovacím prostředí, pokud daný programovací nástroj takové remapování umožní (což např. u @formulí v současnosti nelze).

bubux
13.02.2004 18:39
eee...
jo je to tak jak rikate ale kombinace se moc nepouziva... vsechno to ma totiz jednoho spolecneho jmenovatele a to je soustredeni kodu na jedno misto... do knihovny... proto kdyz nekde umistite formuli porusite koncepci... zkuste mesic programovat timto zpusobem a pouzivat oop... uvidite k formulim se uz budete vracet jenom minimalne a ten kod ktery napisete bude logicky a simulovat "realne" mysleni... :)

Pavel Drápal
29.04.2004 12:37
Díky...
za informačně hodnotný článek, napadá mě, kdy bude další pokračovaní tohoto napínavého seriálu :).

Jinak k soustředění co nejvíce kódu do knihoven:

nevím, jestli v tomto případě; tj. ošetření událostí uiobjektu nejsou lepší knihovní procedury. Parametry se předávají odkazem, tj. můžou sloužit i jako výstupní (např. continue...).

Oproti ošetření událostí až na úrovni třídy vidím tyto výhody:

1/ procedura je volaná přímo na události uiobjektu, tj. neprovádí se někde něco, co není přímo na události uiobjektu vidět (kód aplikace je průhlednější a snáze se v něm zorientuji)

2/ můžu ošetřit i událost queryopen

Nevýhodu spatřuji zatím pouze v tom, že na všech uiobjektech (pohledy, formuláře) musím umístit volání těchto procedur na všechny události..., kdežto objekt stačí pro každý uiobjekt jendou inicializovat...

Jaký na to máte názor? Techniky OOP však v žádném případě nezahrnuji, spíše naopak.

Pavel.