Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

W pracy z IDE do aplikacji okienkowych, bardzo łatwo pomylić znaczenie niektórych właściwości formularza, bo wiele z nich brzmi podobnie albo wydaje się spełniać podobną funkcję. Przykładowo, pole (Name) w oknie Properties nie ma żadnego wpływu na to, co widzi użytkownik w tytule okna – to jest nazwa techniczna obiektu w kodzie, czyli identyfikator, którym odwołujemy się do formularza w trakcie programowania. To megaważna różnica! BackgroundImage natomiast służy do ustawienia grafiki jako tła, a nie koloru – czasem ktoś myli BackColor z BackgroundImage, bo oba dotyczą wyglądu, ale BackColor to czysty kolor, bez obrazków. UseWaitCursor to kolejny haczyk – ta właściwość aktywuje specjalny kursor oczekiwania (taki kręcący się kółek lub klepsydrę), a nie domyślny wskaźnik w kształcie strzałki. Ustawienie tego pola na true sprawia, że użytkownik ma wrażenie, iż aplikacja coś przetwarza – super przydatne w operacjach długotrwałych, ale nie do standardowej obsługi okna. Cursor daje pełną kontrolę nad rodzajem kursora i to jest najlepszy wybór, gdy chodzi o standardowego pointera. Wreszcie, częsty błąd to branie pod uwagę właściwości, które po prostu nie dotyczą zadanego aspektu wizualnego formularza – na przykład mylenie tego, co widzi użytkownik, z tym, jak programista nazywa obiekt. Moim zdaniem, to taki typowy skrót myślowy: patrzymy na nazwę w oknie Properties i wydaje nam się, że to musi być to, co się zmienia na ekranie, a tu czasem logika IDE płata figle. W praktyce, poprawne podejście to zawsze zajrzeć do dokumentacji lub przeprowadzić szybki test – zmienić wartość i zobaczyć, co się realnie dzieje w oknie podglądu. To podstawowa umiejętność każdego, kto na serio chce projektować wygodne i profesjonalne interfejsy, zamiast działać na ślepo.