Kończysz edycję dokumentu, a aplikacja pyta, czy zapisać zmiany. W takiej chwili okno dialogowe zwykle zatrzymuje pracę w głównym oknie, ale są też sytuacje, w których powinno pozostać otwarte obok niego.
O rodzaju okna decyduje zadanie, które ma wykonać użytkownik
- Modalne blokuje pracę w oknie nadrzędnym do czasu odpowiedzi.
- Modeless pozwala wrócić do głównego okna bez zamykania panelu.
- MessageBox pasuje do krótkiej informacji lub prostego pytania.
- OpenFileDialog daje systemowy wybór pliku; własne okno zostaw na zadania specyficzne dla aplikacji.
- WPF: wynik
ShowDialog()pozwala odróżnić zatwierdzenie od anulowania.
Modalność zależy od tego, czy użytkownik musi odpowiedzieć teraz
Gdy aplikacja pyta o zapis przed zamknięciem dokumentu, odpowiedź zmienia dalszy przebieg operacji. WPF otwiera takie okno metodą ShowDialog(): użytkownik obsługuje dialog, zanim wróci do okna, które go wywołało.
Inaczej działa Show(). Pokazuje zwykłe, niemodalne okno, a kod wywołujący biegnie dalej, więc takie rozwiązanie pasuje na przykład do pływającego panelu narzędzi, z którego korzysta się podczas pracy. Jeśli decyzja jest warunkiem bezpiecznego wykonania polecenia, wybierz modalność; jeśli panel ma pomagać w powtarzanej pracy, zostaw go niemodalnego.
Ten podział jest łatwy do pomylenia, bo oba warianty mogą wyglądać jak małe okna. W dokumentacji WPF metoda otwarcia określa jednak także sposób obsługi odpowiedzi, a zamkniętej instancji okna nie można otworzyć ponownie.
Typowe okno systemowe oszczędza własnej implementacji
Przy poleceniu „Otwórz plik” użytkownik oczekuje zachowania znanego z innych programów: przeglądania folderów, filtrowania plików i zatwierdzenia wyboru. WPF udostępnia do tego klasę Microsoft.Win32.OpenFileDialog, a systemowe okna obejmują także zapisywanie pliku, wybór folderu i drukowanie.
Krótki komunikat albo proste pytanie obsłuży MessageBox. Gdy potrzebny jest formularz z polami specyficznymi dla aplikacji, na przykład wybór formatu eksportu wraz z dodatkowymi ustawieniami, uzasadnione staje się własne okno WPF. Domyślnie wybrałbym gotowy dialog systemowy, bo użytkownik zna jego układ, a aplikacja nie musi odtwarzać obsługi przeglądania plików.
Granica jest praktyczna: systemowe okno służy do standardowej czynności, własne do decyzji zależnej od logiki produktu. Microsoft opisuje te standardowe kontrolki jako wspólne dla wielu aplikacji, co tłumaczy ich przewidywalność.
Wynik dialogu trzeba obsłużyć tak samo starannie jak kliknięcie
Własne okno ustawień może zostać zaakceptowane przyciskiem „OK”, odrzucone przez „Anuluj” albo zamknięte krzyżykiem. W WPF ShowDialog() zwraca wartość logiczną nullable: true oznacza akceptację, a brak akceptacji nie powinien uruchamiać zapisu zmian.
Przykładowy przepływ wygląda tak: tworzysz okno edycji, przypisujesz mu właściciela przez Owner = this, wywołujesz ShowDialog(), a zmiany zatwierdzasz dopiero wtedy, gdy wynik to true. To rozdziela wprowadzone dane od zapisanych ustawień i ogranicza ryzyko, że samo zamknięcie okna zostanie potraktowane jak zgoda.
| Sytuacja | Prawdopodobny problem | Co zrobić |
|---|---|---|
| Po zamknięciu własnego okna ustawienia nadal się zmieniają | Zmiany są stosowane podczas edycji zamiast po akceptacji | Trzymaj robocze wartości osobno i zatwierdź je po wyniku true |
| Dialog otwiera się za głównym oknem lub trudno go znaleźć | Okno nie ma poprawnie ustawionego właściciela | Przypisz Owner do okna wywołującego |
| Panel narzędzi blokuje edycję dokumentu | Użyto okna modalnego do zadania, które nie wymaga natychmiastowej odpowiedzi | Rozważ Show() i modeless zamiast ShowDialog() |
| Użytkownik nie może wznowić pracy, dopóki nie zamknie komunikatu | Informacja niepotrzebnie przerywa przepływ | Użyj mniej blokującego powiadomienia, gdy odpowiedź nie jest wymagana |
Zamknięcie okna nie jest równoznaczne z zatwierdzeniem. To drobne rozróżnienie decyduje, czy „Anuluj” naprawdę odwraca operację, czy tylko chowa formularz.
Częste przerywanie pracy sprawia, że komunikaty tracą sens
Modalne okno przyciąga uwagę, ale każde takie przerwanie zmusza do porzucenia bieżącego zadania. W wytycznych projektowych Windows modalność jest zalecana przy krytycznych, rzadkich czynnościach, a niemodalne okna przy zadaniach powtarzanych i ciągłych.
Dlatego nie pytałbym „Czy na pewno?” po każdej łatwej do cofnięcia zmianie. Potwierdzenie zostawiłbym dla poleceń, których skutków użytkownik nie odwróci prostym „Cofnij”, na przykład trwałego usunięcia danych; zwykłą informację o zakończeniu pracy pokazałbym bez blokowania aplikacji.
W dyskusjach programistów często wraca też kłopot z oknem, które zachowuje się inaczej, niż sugeruje metoda jego otwarcia. W praktyce najpierw sprawdź właściciela i wybór między Show() a ShowDialog(), a dopiero później szukaj błędu w samym układzie kontrolek.
Dobrze dobrane okno zostawia użytkownikowi jasny następny krok
Przed dodaniem dialogu ustal jedną rzecz: czy aplikacja naprawdę musi poczekać na odpowiedź? Jeśli tak, pokaż zwięzły powód, nazwij przyciski według skutku i obsłuż anulowanie. Jeśli nie, informacja w głównym widoku albo niemodalny panel zwykle mniej przeszkadza.
Własny dialog powinien skupiać się na jednym zadaniu i nie wymagać przewijania, by dotrzeć do przycisków. Dzięki temu pytanie o zapis pozostaje krótką decyzją, a nie przeszkodą, którą użytkownik odruchowo zamyka.
