Zmiana koloru TPaneli

0

Nie mam pomysłu jak podejść do takiego zagadnienia:
Chcę zmieniać kolor/kolory tpaneli utworzonych w sposób dynamiczny w zależności od stanu trzech zmiennych a,b,c chcę aby wybrane tpanele zmieniały co 300ms swój kolor. Np. jeżeli zmienna a=1 określony tpanel albo kilka tpaneli mruga co 300 ms zmieniając swój kolor na żółty następnie 300ms szary i znowu żółty i tak do czasu aż a=0. Jeżeli zmienna b=1 to robimy to samo tylko teraz posługujemy się kolorem czerwonym zamiast żółtego. Jeś zaś c=1 mrugamy kolorem np. czarnym.
Dodatkowo możliwa jest konfiguracja kiedy a=1, b=1, c=1 wtedy co 300ms następuje po sobie zmiana wszystkich kolorów na określonych tpanelach. Jeżeli np. a=1,b=0,c=1 następuje mruganie w dwóch określonych przez zmienne a i c kolorach. Jeżeli a=0,b=0,c=0 to tpanele świecą np na zielono bez mrugania.
Czyli mamy zmienną która określa który tpanel ma mrugać np. od 0 do 255, i mamy trzy zmienne a, b, c mówiące jakimi kolorami migamy bądź zaprzestajemy mruganie.
Taki niby prosty a zawiły temat :-).

2

Użyj zwykłego TTimer do wykonywania kodu cyklicznie. Działa w ramach głównego wątku, ale nie blokuje programu i nie trzeba synchronizować kodu modyfikującego zawartość kontrolek. To na początek.

Szczerze pisząc, przydałaby się do tego osobna kontrolka, a nie zwykły TPanel. Bo przydałoby się w każdym takim panelu dodać dwa kolory którymi ma migać oraz timer, który by owym miganiem sterował. Napisanie kontrolki w stylu panelu to kilkadziesiąt linii kodu, więc robota na 15 minut.

0

Co to znaczy osobna kontrolka?

1

To znaczy co znaczy – piszesz sobie własny komponent dziedziczący np. z klasy TCustomControl, dodajesz do jego klasy pola z dodatkowymi danymi, dodajesz nowe właściwości, tak aby móc modyfikować dane kontrolki w oknie inspektora obiektów oraz takie, dzięki którym będziesz mógł jedną instrukcją włączyć miganie lub je wyłączyć. No i oczywiście oprogramowujesz metodę OnPaint po swojemu, tak aby móc w pełni panować nad renderowaniem kontrolki, wykorzystując wybrane przez siebie kolory.

Na koniec instalujesz kontrolkę w środowisku, otwierasz swój projekt, wymieniasz wszystkie zwykłe panele na te nowe i programujesz całość jak człowiek – wygodnie, bez babrania się z logiką dotyczącą migania pakowaną gdzie bądź, najczęściej do klasy okna (bo to paskudne rozwiązanie).

Jeśli chcesz to zrobić dobrze, to zainteresuj się tematem tworzenia własnych kontrolek. W dokumentacji i ogólnie sieci znajdziesz masę przydatnych informacji. A jeżeli nie, to cóż… będziesz miał rozwiązanie brzydkie i trudniejsze w utrzymaniu.

0

Ok dzięki pomysł jest super, będę szukał jak się to robi teraz.

0

Podstawowe pytanie – Delphi czy Lazarus?

0

Delphi

2
furious programming napisał(a):

Szczerze pisząc, przydałaby się do tego osobna kontrolka, a nie zwykły TPanel. Bo przydałoby się w każdym takim panelu dodać dwa kolory którymi ma migać oraz timer, który by owym miganiem sterował. Napisanie kontrolki w stylu panelu to kilkadziesiąt linii kodu, więc robota na 15 minut.

Wszystko pięknie, ładnie. Jednak chciałbym jeszcze dodać drugą, moim zdaniem w tym przypadku lepszą opcję. Do takich drobnych zmian zachowania komponentów warto wykorzystać np. taki wzorzec projektowy jak dekorator. Różnice w kodzie będą małe, jednak dekorator nie ma niektórych wad pisania nowego komponentu na podstawie istniejącego. Załóżmy, że chcemy mieć panel który wydaje beep gdy na nim klikniemy (tak wiem funkcjonalność trochę od czapy, ale jednak niech pozostanie dla ustalenia uwagi). Piszemy komponent TPanelBeep. Zatem mamy już dwa komponenty customowe TPanelColor oraz TPanelBeep. Co w przypadku gdy chcemy komponent który zmienia kolor oraz wydaje beep? Piszemy kolejny komponent TPanelColorBeep. Trochę to bez sensu, w dodatku tworzy nie wiadomo ile komponentów które trzeba instalować na każdym IDE podczas pracy zespołowej. Tworząc oddzielnie dekorator TPanelColor oraz TPanelBeep po prostu używamy dwóch dekoratorów na jednym zwykłym TPanel i problem mamy z głowy. Dodatkowo nie trzeba instalować żadnych nowych komponentów, a jedynie pobrać z repozytorium kod.

Zasadniczą różnicą pomiędzy utworzeniem komponentu, a dekoratorem jest moment użycia jednego i drugiego. Komponentu używamy design-time, natomiast dekoracja ma miejsce w run-time. I w przypadku dekoratora nie da się wyklikać wszystkiego w IDE.

0
Mr.YaHooo napisał(a):

Co w przypadku gdy chcemy komponent który zmienia kolor oraz wydaje beep?

Możliwych rozwiązań tego samego problemu jest co najmniej kilka. Wymagania OP są dosyć podstawowe, dlatego zaproponowałem najprostsze rozwiązanie, które nie wymaga dużo pisania i jest proste w obsłudze zarówno w designerze, jak i z poziomu kodu oraz nie spowoduje bałaganu w projekcie. Oczywiście o ile kod kontrolki napisze się dobrze. ;)

0

@furious programming dokładnie. Zawsze istnieje kilka możliwych dróg :)

Ja już sobie przyjąłem taką zasadę, że jak chcę rozszerzyć komponent o małą funkcjonalność to używam dekoracji. Natomiast jeśli to będzie duża "kobyła" mocno zmieniająca, a nawet czasami tworząca zupełnie nowy byt, to tworzę komponent. Ale niech OP sam już sobie wybierze co dla Niego będzie lepsze.

0

To zależy czy funkcjonalności przeplatają się pomiędzy końcowymi klasami (tak jak pokazałeś w przykładzie z panelami) czy nie, no i od tego czy chcemy mieć dostęp do tych wszystkich bajerów w designerze.

Sam wolę najważniejsze dane ustawiać w inspektorze obiektów – takie małe zboczenie. Z reguły nie mam do czynienia z zaplataniem funkcjonalności, więc po prostu konkretna hierarchia dziedziczenia klas bazowych dla kontrolek towarzyszy mi na co dzień.

0
furious programming napisał(a):

To zależy czy funkcjonalności przeplatają się pomiędzy końcowymi klasami (tak jak pokazałeś w przykładzie z panelami) czy nie, no i od tego czy chcemy mieć dostęp do tych wszystkich bajerów w designerze.

Właśnie to jest też kluczowe.

furious programming napisał(a):

Sam wolę najważniejsze dane ustawiać w inspektorze obiektów – takie małe zboczenie. Z reguły nie mam do czynienia z zaplataniem funkcjonalności, więc po prostu konkretna hierarchia dziedziczenia klas bazowych dla kontrolek towarzyszy mi na co dzień.

U mnie z kolei jest odwrotnie. Fajnie się klika w IDE właściwości. Jednak powstaje problem przy nowej wersji komponentu naprawiającej buga. Wtedy muszę ponownie instalować komponent. A jak się ich nazbiera około 50 (jak u mnie) to podczas przenoszenia się na nowy komputer nie jest miło...

1
Mr.YaHooo napisał(a):

U mnie z kolei jest odwrotnie. Fajnie się klika w IDE właściwości.

Tu nie do końca chodzi o to że „fajnie się klika”. Podstawowe ustawienia kontrolek (takie jak rozmiar, położenie, kotwice, kolory, styl i temu podobne) tworzy się jako właściwości, bo do tego właśnie służy OI. Jeśli mogę dwa razy kliknąć i od razu widzieć w designerze podgląd, to z tego korzystam. Dłubanie w kodzie zajmuje więcej czasu, nie ma podglądu ”na żywo” i nie ma gwarancji poprawności bez kompilacji i uruchomienia.

Jednak powstaje problem przy nowej wersji komponentu naprawiającej buga. Wtedy muszę ponownie instalować komponent. A jak się ich nazbiera około 50 (jak u mnie) to podczas przenoszenia się na nowy komputer nie jest miło...

Od tego są pakiety, aby nie instalować każdej kontrolki z osobna. Po wprowadzeniu łatek w źródłach komponentu(ów), zasysa się bieżące źródła, kompiluje pakiet i instaluje – żadnych dodatkowych czynności.

0
furious programming napisał(a):

Tu nie do końca chodzi o to że „fajnie się klika”. Podstawowe ustawienia kontrolek (takie jak rozmiar, położenie, kotwice, kolory, styl i temu podobne) tworzy się jako właściwości, bo do tego właśnie służy OI. Jeśli mogę dwa razy kliknąć i od razu widzieć w designerze podgląd, to z tego korzystam. Dłubanie w kodzie zajmuje więcej czasu, nie ma podglądu ”na żywo” i nie ma gwarancji poprawności bez kompilacji i uruchomienia.

Tak, takie podstawowe właściwości jak wymieniasz o wiele lepiej się ustawia mając od razu podgląd w designerze. Z drugiej strony u mnie większość rozszerzeń jest w stylu np. customowe kolorowanie DBgrida, dodatkowa nawigacja po Gridzie, czy wyszukiwanie w Gridzie. Tu już podczas design-time i tak tego nie widać, więc i tak nie ma różnicy czy to komponent czy nie.

furious programming napisał(a):

Od tego są pakiety, aby nie instalować każdej kontrolki z osobna. Po wprowadzeniu łatek w źródłach komponentu(ów), zasysa się bieżące źródła, kompiluje pakiet i instaluje – żadnych dodatkowych czynności.

W sumie racja, może kiedyś skorzystam. Jednak osobiście jestem zwolennikiem jak najmniejszej liczby dodatkowych komponentów. Ot taka fanaberia można by powiedzieć. No i jak zwykle brak czasu na refactor ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1