Formularz na ekranie i pierwszy test

Łączymy wszystko w całość: formularz trafia na ekran, a lista nieobecności dostaje akcje „Add” i „Edit”. Pierwszy raz widzimy efekt w aplikacji.

Ekran z formularzem

• Nowy ekran E_Absence.
• W procesie ekranu:
  • zmienna wejściowa absenceIdIn (Guid),
  • zmienna wyjściowa absenceIdOut (Guid),
  • SetVariable przepisuje wejście na wyjście. Na razie proces ekranu nic więcej nie robi — tylko przekazuje parametr dalej.
• Na ekranie komponent formularza:
  • tytuł,
  • wybrany formularz F_Absence,
  • w parametrach absenceId ← zmienna procesu absenceIdOut. Parametr może też być wartością stałą.

Akcje na liście nieobecności

• „Edit” — akcja na wierszu (row action) typu ekran → E_Absence. Parametr: kolumna Id z listy.
• „Add” — akcja na całej liście → ten sam ekran. Parametr: stała, pusty Guid, bo nowy wniosek nie ma jeszcze identyfikatora.
• Obie akcje prowadzą do tego samego ekranu, procesu i formularza. Jedna logika obsługuje kilka przypadków biznesowych.

Poprawki przed zapisem

• Lista „Full name” miała na próbę wartości 1 i 2, a PersonId w kontrakcie to Guid. Wartości opcji listy muszą mieć typ zgodny z kontraktem, więc wpisujesz tam Guidy pracowników.
• AbsenceId nie był dotąd nigdzie na formularzu. Dodajesz pole tekstowe, mapujesz je na AbsenceId, a sam obiekt Absence mapujesz stałą, bo nie przechowuje wartości — grupuje tylko pozostałe pola.

Test w aplikacji

• „Edit” otwiera formularz z danymi wniosku, „Add” — pusty formularz.
• Po uzupełnieniu pól „Zapisz” zapisuje wniosek i wraca na listę, na której widać nowy rekord.

Zapamiętaj

Moduł 1 zamknięty: dodawanie i edycja, zapis do bazy, komunikat o sukcesie albo błędzie i powrót na listę. Formularz = 3 elementy, a czwarty to ekran, który go wyświetla. To wciąż bardzo prosty formularz — od następnej lekcji dodajemy mu logikę.