No fajnie, fajnie, szacun Krauser.
Fajne efekty wizualne (kliknięcie), układ przestrzenny przycisków no MEGA jak w Casio normalnie.
Powalczyłbym z tym żeby użyć tej biblioteki w swojej magisterce, ale już klawiaturkę ekranową mam własną (może nie jest tak fajna, funkcjonalna i dobrze napisana jak ta tutaj), ale jako-tako działa i szczerze powiedziawszy terminy gonią i trzeba przeć na przód zamiast udoskonalać to co już jest. W sumie poza liczbami x.0y (i typu x.00...0y) każdą liczbę da się wprowadzić a przecież liczba x.0y to w przybliżeniu liczba x albo x.1 (2.02 -> 2, 2.09 -> 2.1), więc to mnie aż tak bardzo nie boli bo można sobie wprowadzić właśnie 2 albo 2.1 i błędu wcale dużego nie będzie. No a z liczbami gdzie po przecinku jest kilka zer to już w ogóle można śmiało tą część po przecinku zaniechać i błędu... praktycznie nie ma! problem wynika z tego, że część ułamkowa u mnie jest intem w strukturze, a wiadomo, że 01 = 1 więc stąd się to bierze. Zależy też do czego chcemy użyć taką klawiaturkę. No jak kalkulator, to jednak precyzja gra dużą rolę. Ale np. w regulatorze PID można sobie pozwolić (można?) przy wprowadzaniu nastaw na niewielkie odchyłki od wzorcowych nastaw.
Kolega widzę bazuje na parsowaniu stringów , ja z nimi przegrałem bitwę i jednak swoją klawiaturkę oparłem o działania na strukturce z intami i boolami. Liczba 5.2 reprezentowana jako int 5 (część całkowita), int 2 (część ułamkowa), kilka booli (znak, flaga całkowita/rzeczywista itp.). Do tych stringów w AVR wiedzie mnie ciężka droga... W C++ na PC jakoś łatwo się ich używało, a w AVR to jak droga przez mękę dla mnie...
Jak będę robił jakiś następny projekt z użyciem GLCD to pozwolę sobie skorzystać z tej Krauserowej klawiaturki, no bo bomba, trzeba przyznać.
Aha, ładnie przygotowana biblioteka, duże reusability, ładny, czytelny kod i dobre nazewnictwo. Aż chce się tego używać.
------------------------ [ Dodano po: 23 minutach ]Żeby nie było za słodko: za długi main (zarówno int main(void) jak i plik main.c)
I raczej nie powinno się tworzyć pliku main.h, tylko np. common.h
------------------------ [ Dodano po: 31 minutach ]A przyczepię się jeszcze, mam nadzieję że wybaczysz Krauser.
Ale niestety (albo stety?) jestem pedantem jeśli chodzi o przejrzystość, składnię i czytelność kodu.
Chodzi o wskaźniki.
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Gwiazdka - no właśnie - gdzie ona powinna być? Powinna być przy TYPIE wskaźnika, a nie w połowie drogi między typem a nazwą (otoczona spacjami). Wtedy od razu widać, co to jest. Jakoś tak optycznie lepiej się to czyta.
Widać, że ta zmienna to wskaźnik na chara albo że funkcja zwraca wskaźnik na chara. Nie ma niejasności.
Czyli prawidłowo:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
------------------------ [ Dodano po: 35 minutach ]Jeszcze jedno.
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
To aż się prosi o zmianę. Chodzi o
magic inty. Czyli o wartości liczbowe bezpośrednio w kodzie,
W WIELU MIEJSCACH. Np. to nieszczęsne 36. Powiedzmy że to coś znaczy, np. rozmiar w osi X przycisku. Nagle chcesz zmienić szerokość przycisku - i co? Musisz zmieniać w 40 miejscach! Nie lepiej zrobić sobie stałą wcześniej i zmieniać potem tylko w tym jednym miejscu? Lepiej, uwierz.
------------------------ [ Dodano po: 45 minutach ]Kiepski jestem w mallocach, możesz wytłumaczyć tą linijkę?
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Rozumiem, że rezerwujemy pamięć dla nowego buttona. Ale dlaczego rzutujemy rezultat na BUTTON* skoro już on jest przekazywany do funkcji właśnie jako wskaźnik do BUTTON? I gdzie jest zwalniana ta pamięć? Szukam w twoim kodzie odpowiednika
delete z C++ ale nie widzę.
------------------------ [ Dodano po: 51 minutach ]Nie wgłębiając się w szczegóły niezbyt pojmuję po co jest tutaj zastosowana lista jednokierunkowa. Mógłbyś przybliżyć ten cel?