
Czasem lepsze jest wrogiem dobrego. Trochę się o tym przekonałem walcząc z GUI pewnego projektu, który tym razem uruchamiamy na komputerze panelowym z Win10. Ale po kolei.
W przemyśle nadal powszechnie używany jest Win 7. Wiele przedsiębiorstw zdecydowało się co prawda na migrację do 10-tki, ale 7-ka ma się nadal dobrze i pewnie przez jakiś jeszcze czas tak będzie. Dobitnie świadczy o tym chociażby to, że wiele firm związanych z przemysłem (jak chociażby Siemens) podpisuje z Microsoft specjalne umowy long time support, dzięki którym sprzedają urządzenia ze starszym systemem nawet już po wycofaniu go z oficjalnej sprzedaży.
Wbrew pozorom ma to pewien sens. Duże systemy (chociażby wizualizacji) są bardzo drogie i awaria sprzętu wymagająca wymiany na nowy, może pociągać za sobą konieczność wykonywania upgrade aplikacji, a to są już całkiem niebagatelne koszty. Póki co nadal sporadycznie spotyka się systemy wizualizacji bazujące na serwerze i klientach webowych – mamy więc do czynienia (prawie zawsze) z klasycznymi aplikacjami desktopowymi – nawet w instalacjach, w których jest serwer i klienci.
Jakiś czas temu przygotowałem pewną aplikację związaną z wizualizacją i sterowaniem maszyny właśnie pod komputer panelowy z Win 7. Teraz pojawił się temat modernizacji kolejnej, niemal identycznej maszyny więc po drobnych zmianach aplikacja jest praktycznie w 100% do ponownego wykorzystania. Tak przynajmniej mi się wydawało. Jeszcze gwoli wyjaśnienia stos technologiczny to C# i WPF MVVM + MahApps z targetem na .Net Framework 4.5.2.
Zdecydowaliśmy się (po konsultacji z klientem), że tym razem skorzystamy z Win 10. Sam mocno optowałem za takim rozwiązaniem wiedząc, że 10-tka jest lepiej przystosowana (przynajmniej w teorii) do pracy z ekranami dotykowymi. Jak się później okazało, w przypadku UWP być może tak jest, jednak w przypadku klasycznego WPF – wręcz odwrotnie.
Poniżej garść doświadczeń, z adaptowania w/w aplikacji pod Win 10.
Tablet mode
No niby fajny, ale nie nadaje się kompletnie do wykorzystania na dużym ekranie 19’’ (swoją drogą, o kuriozalnej wręcz rozdzielczości 1366×760). Nie ma możliwości ukrycia paska start. Okna dialogowe otwierają się na całym ekranie. Generalnie nie, nie, nie. Być może sprawdzi się fajnie na małych ekranach i z aplikacjami zaprojektowanymi do wykorzystania w tym trybie.
Klawiatura ekranowa
W porównaniu z tym, co mieliśmy dostępne w Win7 jest naprawdę dobrze. Klawiatura fajnie współpracuje z aplikacjami, ma przełączane tryby, przyciski są duże i wygodne w obsłudze. Spodobała mi się do tego stopnia, że zrezygnowaliśmy z własnego rozwiązania i aplikacja została zaadoptowana pod klawiaturę dostępną w systemie.
Jest jednak pewien drobny szkopuł. Jeżeli korzystamy z .Net Framework < 4.6.2 to otwiera się ona dość losowo po kliknięciu w okienko edycyjne. Dopiero .Net 4.6.2 posiada ficzer, powodujący że klawiatura otwiera się zawsze także w aplikacjach WPF.
W przypadku starszych wersji frameworka, bardzo pomocna jest fajna biblioteka, którą można pobrać przez Nuget – WPFTabTip.
Korzysta się z niej bardzo prosto. W App.xaml.cs w OnStartup przypisujemy odpowiednie typy kontrolek, które mają otwierać klawiaturę
protected override void OnStartup(StartupEventArgs e) { TabTipAutomation.BindTo<TextBox>(); TabTipAutomation.BindTo<PasswordBox>(); base.OnStartup(e); }
W xaml-u możemy potem zdefiniować jaki tryb klawiatury chcemy otwierać, ustawiając parametr InputScope. Mamy do wyboru: Default, Number, Url, EmailSmtpAddress.
<TextBox InputScope="Number" />
Proste, fajne i działa 🙂
Dotyk
I tu pojawia się duży problem, który początkowo był dla mnie dużą zagadką. TextBoxy, po dotknięciu łapały fokus a następnie natychmiast traciły. Klawiatura dotykowa otwierała się i natychmiast zamykała. Przyciski działały losowo – czasami za każdym razem, a czasami dopiero po kilku próbach. Coś, czego w Win7 nie było.
Okazuje się, że winna jest tutaj właśnie „zaawansowana” obsługa dotyku, m.in. obsługa prawego przycisku myszy przez dłuższe przytrzymanie palca, lub stylusa na ekranie.
Pełna obsługa eventów dotykowych wymagała by dopisania sporo kodu, do dość rozbudowanego Gui. Na szczęście istnieje metoda, aby wyłączyć w swojej aplikacji obsługę RealTimeStylus.
Podpowiedź jak to zrobić, znajdziemy na MSDN:
https://docs.microsoft.com/pl-pl/dotnet/framework/wpf/advanced/disable-the-realtimestylus-for-wpf-applications
Po tych zabiegach aplikacja działa bardzo fajnie i rezponsywnie. Nie ma już problemów z wielokrotnym klikaniem w przyciski a systemowa klawiatura ekranowa jest naprawdę wygodna.
Być może obrana przeze mnie metoda adaptacji nie jest najpoprawniejsza, ale pozwoliła w krótkim czasie zaadaptować aplikację pod nowy system, bez konieczności walki z implementacją zdarzeń dotykowych (tak naprawdę wcale tutaj nie potrzebnych). Jak to mówią: Done is better then perfect 🙂
Jeżeli, drogi czytelniku, posiadasz jakieś własne doświadczenia w adaptacji aplikacji WPF pod ekrany dotykowe napisz proszę w komentarzu. Chętnie poczytam i chętnie podyskutuję.
Też niedawno próbowałem przenieść całą aplikacje na panel z Windows 10 (Hateland), i o dziwo wszystko było super, żądnego problemu, niestety po pewnym czasie (czasem dzień, czasem 3 dni) panel się zawieszał.
Zawieszał się w taki sposób że dokąd nie próbowałem wykonać interakcji z ekranem wyglądało ok, nawet interfejs ETH migał. Po restarcie żadne logi w Event Viewerze nie zostały wygenerowane.
Niestety po kilku próbach musiałem wrócić do 7.