Czynności

• Kod czynności (pole ACTION)

Określ kod akcji, który ma zostać zdefiniowany.

• Opis (pole ZINTITA)

• Kod działań (pole CODACT)

Jeśli kod czynności rozpoczyna się literą X, Y lub Z, podczas sprawdzania poprawności zawartości folderu programu ADONIX nie nastąpi aktualizacja czynności.

• Moduł (pole MODULE)

Służy do określenia modułu, który korzysta z tego działania. Jeżeli z działania korzysta kilka modułów, należy ustawić wartość „Administrator”.

• Szablon (pole TYP)

Pole to jest ważne, ponieważ służy do identyfikacji procesu, który ma zostać uruchomiony po wykonaniu tej czynności. Patrz: szczegóły projektu. Dopuszczalne wartości na tym poziomie to:

Zarządzanie obiektami
Zapytanie
Proces standardowy (może zostać uruchomiony w trybie przetwarzania w tle)
Wpis w oknie
Wybór z listy (okno wyboru)
Wybór z tabeli (okno wyboru)
Wyświetlanie innych (wywoływane z podprogramu funkcjonalnego przez Gosub)

Proces dodatkowy (wywoływany z podprogramu funkcjonalnego przez Call)

„Proces dodatkowy” służy do bezpośredniego uruchamiania procesu funkcjonalnego bez konieczności stosowania szablonu; czynności tego typu nie można wywołać z poziomu funkcji.

• Tytuł przycisku (pole ZINTITC)

• Kod zapytania (pole PARAM1)

Służy do identyfikacji zapytania, które ma zostać wprowadzone do czynności szablonu „Zapytanie”.

• Typ (pole TYPUTI)

• Główne okno (pole PARAM2)

Pole to służy do zidentyfikowania głównego okna wprowadzania dla „Wprowadzania w oknie” w szablonach „Procesu standardowego”.

• Pierwszy wpis (pole PARAM3)

Do wprowadzenia dla szablonu „Procesu standardowego”. Czy jest to zapis początkowy? Jakiego typu? Dopuszczane wartości to:

Brak początkowego zapisu

Potwierdzenie Tak/Nie (komunikat z możliwością zatwierdzenia wykonywania czynności)
Okno dialogowe (ograniczone możliwości wpisu w oknie: przyciski „OK” oraz „END”, brak menu, pojedynczy ekran).
Wpis w oknie (wpis w oknie za pomocą szablonu „Wpis w oknie”).
Wybór listy (okno wyboru)
Wybór tabeli (okno wyboru)

• Okno kryteriów (pole PARAM4)

Do wprowadzenia, jeżeli zapis początkowy to:
Okno dialogowe
Wpis w oknie

• Standardowy skrypt (pole CODTRT)

Proces standardowy, za pomocą którego podczas projektowania Adonix można opisać model administratora lub dodatki podprogramu. Patrz: szczegóły projektu.

• Podprogramy (pole SUBPRG)

Pole to może zostać wypełnione w toku działania typu „procesy dodatkowe”. Żaden proces administratora nie jest powiązany z tą czynnością, a jedynie z podprogramem. Opcję tę definiuje się za pośrednictwem procesu standardowego lub specyficznego/niestandardowego.

Uruchamiany jest pojedynczy podprogram: Jest on specyficzny/niestandardowy, jeżeli istnieje odpowiedni proces, lub — w przeciwnym wypadku — standardowy. Dodanie opcji niestandardowych do czynności standardowej typu „Procesy dodatkowe” zostaje następnie unieważnione i zamienione.

• Właściwy skrypt (pole SPETRT)

Specyficzny/dostosowany do potrzeb użytkownika proces, w którym personalizacja zapisuje szablon administratora lub dodatki podprogramu. Aktualizacja specyficznego/dostosowanego do potrzeb użytkownika procesu nie wymaga ochrony za pomocą kodu czynności.  

Patrz: szczegóły projektu.

• Wyrażenie (pole INSTRU)

Pole to może zostać wypełnione w toku działania typu „procesy dodatkowe”. Może pojawić się jako dodatek do podprogramu. W takim przypadku zostanie wykonane po podprogramie.

• Identyfikator czynn. (pole PARAM5)

Służy do określania jednej lub kilku czynności w ramach danego procesu, za pomocą następujących zmiennych:

• TABLE dla czynności typu „Wybór tabeli”
• LISTE dla czynności typu „Wybór listy”
• TRAIT dla czynności typu „Wyświetlanie innych”

• Czynność, następna (pole ACTSUI)

Pole to służy do określania innej czynności słownika. W ten sposób można podłączyć do 5 czynności. W tym przypadku wartości parametrów wszystkich tych działań są wprowadzane przy uruchamianiu. Podłączone w ten sposób działania mogą pochodzić z innego szablonu.

Jeżeli główne działanie znajduje się w polu, wówczas istnieje możliwość niewykonywania połączonych działań przez ustawienie zmiennej mkstat .

Jeżeli główne działanie znajduje się na dole ekranu lub w menu, istnieje możliwość niewykonywania połączonych działań przez ustawienie zmiennej OK = 0 w działaniu BEFORE NEXT.

• Przepływ (pole AMSFLG)

Flaga stosowana do zatwierdzenia (lub nie) czynności w przepływie danych (workflow). Tego rodzaju zatwierdzenie możliwe jest jedynie dla czynności typu „Proces dodatkowy”. Flagę tę zaznacza się w szczególności po utworzeniu reguły workflow.

• Serwer wsadowy (pole ABTFLG)

Flaga stosowana do zatwierdzenia (lub nie) czynności w trybie przetwarzania w tle. Tego rodzaju zatwierdzenie możliwe jest jedynie dla czynności typu „Proces standardowy”. Flagę tę zaznacza się w szczególności po utworzeniu zadania przetwarzania w tle.

• Publiczne (pole PUBFLG)

Flaga ta wskazuje, że element ten jest publikowany. Dlatego może być on ponownie użyty przez niestandardowe / specjalne pole. Dostępna jest powiązana z tym dokumentacja.

• Wsad obowiązkowy w WEB (pole NOWEB)

Jeżeli flaga ta jest ustawiona, odnośna czynność nie zostanie wykonana w trybie interaktywnym, lecz w trybie Klient/Serwer. Nie zostanie również wykonana w wersjach Web (Native Web, usługi w sieci Web). Pozwala to uniknąć obciążającego przetwarzania w trybie interaktywnym w wersji Web.

• pole TEXTE

Tekst ładujący akapit PRE „prezentacji” w pomocy rekordu. W zarządzaniu dokumentacjąpomoc rekordu jest identyfikowana za pomocą:

• typu dokumentacji = ACT
• kodu dokumentacji = nazwa czynności

• Bieżące pole (pole TYPACT)

Jeżeli pole to jest zaznaczone, za pierwszy parametr uznaje się bieżące pole. Jeżeli działanie to jest umieszczone w polu, pierwszy parametr wprowadzany jest automatycznie przez wartość bieżącego pola. Nie pojawia się on zatem w słowniku ekranu na liście parametrów do wprowadzenia w danym polu.

• Pole czynności przed/po (pole PARAM6)

Możliwość dodania procesu przed i/lub po danym Obiekcie, Zapytaniu, Procesie standardowym, Szablonie okna wprowadzania, kiedy czynność ta jest umieszczona w menu kontekstowym dla danego pola. Umożliwia to przygotowanie kontekstu (np. przypisanie wartości GCONSULT) przed wykonaniem czynności i/lub uruchomieniem np. okna po wykonaniu czynności.

Kod czynności „przed” stanowi nazwa etykiety z prefiksem A. Kod czynności „po” to nazwa etykiety z prefiksem B.

Przykład: jeżeli czynność połączona jest z przyciskiem 2 w polu CHP, etykiety „przed” i „po” będą miały postać AB2_CHP oraz BB2_CHP. Opcja ta musi zostać zaprogramowania w etykiecie $ACTION procesu standardowego lub specyficznego/niestandardowego.

• Nr (pole NUMLIG)

• Kod (pole CODPAR)

kody parametrów dla czynności.

Bardzo ważna jest kolejność wprowadzania kodów parametrów do tabeli: Musi odpowiadać ona kolejności, w jakiej wprowadzono parametry do podprogramu, który umożliwia wykonanie czynności.

Każdy parametr musi także zostać uprzednio zadeklarowany w słowniku parametrów. W celu uniknięcia powtórzeń, przed wygenerowaniem tego kodu parametru należy zweryfikować, czy już nie istnieje on pod innym kodem. W celu wyświetlenia listy należy nacisnąć przycisk wyboru.

• Typ parametru (pole TYPPAR)

Wskazuje rodzaj parametru: znak, liczba całkowita, liczba dziesiętna itd. Informację tę można wprowadzić tylko na etapie tworzenia parametru w słowniku parametrów.

Uwaga! Parametr typu clob/bob może być zastosowany w toku czynności jedynie w następujących dwóch przypadkach:

• W toku działania typu „procesy dodatkowe”, na wszystkich parametrach,
• W innym, dowolnym działaniu pod warunkiem, że w pierwszym parametrze zaznaczono okno „Bieżące pole”.

• Typ argumentu (pole ADRVAL)

Wskazuje, w jaki sposób przenoszony jest parametr.

Według adresu (aby możliwe było przeniesienie parametru, musi istnieć zmienna). Po opuszczeniu podprogramu wartość każdego zmodyfikowanego parametru zostaje zwrócona procesowi wywołującemu).

Według wartości (parametr zostaje przekazany według zmiennej lub stałej. Po opuszczeniu podprogramu wartość parametru nie zostaje zwrócona procesowi wywołującemu, nawet jeśli parametr został zmodyfikowany).

• Wszystkie istniejące języki (pole ALLLAN)

Jeżeli pole to zostało zaznaczone, to wszystkie języki są brane pod uwagę przez operację.

Jeśli to pole nie jest zaznaczone, w zależności od przypadku:

• jeśli kod języka nie jest wprowadzony odręcznie, zostanie użyty język domyślny,
• w przeciwnym wypadku stosowany jest język wprowadzony.

• Język (pole LAN)

Służy do definiowania języka generowania (jeżeli nie zaznaczono opcji generowania wszystkich języków).

• Wszystkie typy (pole ALLTYP)

Jeżeli pole to jest zaznaczone, wszystkie typy są brane pod uwagę przy generowaniu. Należy zwrócić uwagę na fakt, że w tym wypadku obowiązuje limit podczas generowania standardowej dokumentacji (uwzględniana jest tylko dokumentacja, która oznaczona jest kodem większym niż X).

• Typ (pole TYPEDOC)

Stosowany do definiowania typu dokumentacji, która zostanie uwzględniona w procesie (pole nie zaznaczone uwzględnia wszystko).

• Kody dokumentacji od (pole FUNDEB)

Stosowany do określenia zakresu kodów, uwzględnianych przy generowaniu dokumentacji.

• Kody dokumentacji do (pole FUNFIN)

• pole GENDOC

Radioprzycisk jest stosowany do tworzenia/aktualizacji ram dokumentacji (struktury hierarchicznej akapitów) na podstawie elementów technicznych, znalezionych w słowniku danych. Istnieje możliwość albo ograniczenia się wyłącznie do aktualizacji istniejących dokumentacji lub - w razie potrzeby - tworzenia nowych.

Powiązania dokumentacji są również brane pod uwagę. Akapity co do których istnieje prawdopodobieństwo utworzenia są definiowane w odpowiednim załączniku technicznym.

• Do wszystkich grup (pole ALLCREGRP)

Pole to umożliwia wybór między:

• Przetworzeniem wszystkich dokumentacji lub pomocy dla pól, niezależnie od grupy przynależności użytkownika.
• Przetworzeniem wyłącznie dokumentacji lub pomocy dla pól, których grupa użytkownika odpowiada grupie autora dokumentacji, która znajduje się w tabeli AOBJGRPDEV.

• pole GENFIN

Radioprzycisk jest stosowany do generowania ostatecznej dokumentacji na podstawie akapitów dokumentacji. Dokumentacja ta jest tworzona w różnych pod-katalogach katalogu zdefiniowanego przez parametr użytkownika DIRDOC .

Generowanie 'według kodu działania' należy stosować w celu uzyskania generacji dokumentacji tych funkcji o kodach działania >= 'X'
Generowanie 'kompletne' dotyczy wyłącznie standardowych kodów działania.

• Tylko zweryfikowane dokumentacje (pole HLPVLD)

Stosowany do generowania ostatecznego dokumentu jedynie dla zwalidowanych dokumentacji.

• Pomoc dla pól połączona z dokumentacją (pole HLPLNKFLD)

Jeśli to pole zostało zaznaczone przetwarzane są tylko pomoce dla pól dotyczące dokumentacji dla funkcji lub przetwarzanych obiektów. Aby dowiedzieć się, które pomoce dla pola powinny zostać przetworzone, należy przejrzeć ekrany powiązane z odpowiadającymi paragrafami dokumentacji.

• Pomoc dla innych pół (pole HLPFLD)

Jeżeli okno to zostało zaznaczone, to utworzona zostanie ostateczna dokumentacja na podstawie zawartości akapitów dokumentacji. Dokumentacja ta zostanie utworzona w podkatalogu FLD katalogu zdefiniowanego parametrem użytkownika. REPDOC.

• Kody dokumentacji od (pole HLPDEB)

Stosowany do określenia zakresu kodów, uwzględnianych przy generowaniu dokumentacji.

• Kody pomocy do pola do (pole HLPFIN)

• Katalog generowania (pole REPERT)