Zacznijmy od absolutnych podstaw, czyli od organizacji katalogu z projektem, plikami i ich nazewnictwem.
W sumie to używasz wyłącznie jednego katalogu dla wszystkich plików, co jest bardzo złym pomysłem. Nie dość, że wymieszane są pliki dwóch projektów (CREDO
i KALIB_PROG
), to jeszcze znajdują się w tym katalogu również pliki binarne, tworzone przy kompilacji. Binarki domyślnie tworzone są w podkatalogu lib\$(TargetCPU)-$(TargetOS)
i nie ma potrzeby tego zmieniać. Przyjdzie czas opublikować źródła, więc do archiwum wrzuca się wszystko oprócz podkatalogu lib
. U Ciebie wszystko jest na kupę, dlatego też binarki trzeba wykluczać ręcznie.
Struktura katalogów powinna być np. taka:
Kopiuj
+ Sources
+ CREDO
- pliki projektu
+ lib
+ i386-win32
- pliki binarne
+ KALIB_PROG
- pliki projektu
+ lib
+ i386-win32
- pliki binarne
Kolejna rzecz – nazewnictwo plików. Nazwy plików nie powinny być samymi dużymi literami, to nie DOS… Główny plik projektu najczęściej przyjmuje nazwę main
lub nazwę projektu (pełną lub skróconą), pisaną małymi literami lub w stylu PascalCase. Pliki z kodem formularzy powinny swoją nazwą jasno o tym informować, np. MainWindow.pas
, SettingsWindow.pas
. Stosuje się też notację frmMain.pas
, frmSettings.pas
lub Main_frm.pas
, Settings_frm.pas
. A u Ciebie jest to core.pas
… serio? Formularz jest jądrem aplikacji? Masz też kalibunit.pas
, który też zawiera kod formularza. Tu stosujesz inne nazewnictwo – sufiks unit
. Wiadome, że ten plik to moduł – nie musisz tego dodatkowo zaznaczać.
Inna sprawa to brak plików .lpr
, czyli domyślnie tworzonych głównych plików projektu. Nie wiem czemu u Ciebie pliki te mają rozszerzenie .pas
– zmieniałeś je ręcznie? Jeśli tak, to po co?
Przechodzimy dalej, otwieram plik CREDO.pas
i jeb, IDE wyrzuca błąd o braku modułu:

To samo jeśli otworzę KALIB_PROG.lpi
. W plikach .lpi
masz sporo odwołań do plików, które nie istnieją w tym archiwum. Niektóre są wymagane (jak ten, którego nazwa widnieje w oknie z błędem), a niektóre nie są wymagane, przynajmniej do otwarcia projektu w IDE (np. związane z pakietem Indy). Tak więc zbędne wpisy należy usunąć z pliku .lpi
, bo IDE wysypuje się.
Następna rzecz – główna ikona projektu, czyli plik CREDO.ico
. Eksplorer nie potrafi wyświetlić jego zawartości, tak jak ma to miejsce w przypadku standardowych ikon. Otworzyłem ten plik w programie do tworzenia i edycji ikon i widzę, że posiada on tylko jedną grafikę, w dodatku o rozmiarach zupełnie niezgodnych z formatem ikon (300x223
to nie jest prawidłowy rozmiar ikony dla eksplorera). Ikona jest prostokątna, a powinna być kwadratowa, poza tym o wielu rozmiarach – co najmniej 16x16
, 24x24
, 32x32
, 48x48
, 64x64
, 128x128
i 256x256
.
Czas na projekt. Podstawa to jego konfiguracja, czyli wszystko co znajduje się w oknie ustawień projektu. Wchodzę w to okno, a tam cuda i dziwy. Ikona przypisana (ale jej zawartość jest zła), lista formularzy zawiera dwie pozycje, z czego jedna nie istnieje (Form1
), Version Info
nieuzupełnione. Jeśli o opcje kompilacji chodzi, to uzupełnione są pola ze ścieżkami, choć ścieżki te dotyczą katalogów nieistniejących w archiwum (np. ..\..\..\indy9\lazarus
), opcje debugowania są włączone, ale pola w grupie checks and assertion
są odznaczone, custom options
wypełnione symbolami dla Borlanda (domyślam się czemu ma to służyć). Ogólnie trochę bałaganu, a próba kompilacji rzuca kupką notek i ostrzeżeń o duplikacji plików. Niedobrze.
Skupmy się na razie na formularzu, a konkretniej na jego wyglądzie (w dalszej części uczepię się kodu). Okno nie wygląda zachęcająco – emotka w tytule na belce okna (sic!), do tego informacja o wersji i o autorze (to umieszcza się w oknie about
). Używasz systemowego schematu interfejsu, ale pomimo tego zmieniłeś kolor tła okna i fonty na przyciskach. Na innych systemach może to bardzo źle wyglądać. Tekst w kontrolkach jest w dwóch językach (np. Kamera On
) – takich rzeczy się nie robi. Albo tworzy się domyślny interfejs po angielsku i dodaje opcje językowe, albo robi się jedną wersję językową (np. polską). Do tego niektóre napisy są dużymi literami (tego należy unikać, chyba że dokładnie wie się co się robi).
Układ komponentów na formularzu nie jest dobry – niektóre kontrolki przykryte są całkowicie przez inne. Takie rzeczy robi się wtedy, gdy część kontrolek ma być niewidoczna i pokazywana dynamicznie. Jednak w takim przypadku grupuje się je np. na panelu, tak aby móc manipulować widocznością całej grupy, a nie każdej kontrolki z osobna. U Ciebie część jest zgrupowana, a część nie.
Teraz czas na nazewnictwo. Nie stosujesz żadnego uniwersalnego sposobu nazywania kontrolek. Niektóre mają nazwy domyślne, inne polskie, a jeszcze inne angielskie lub mieszane. Przyjęło się, aby kontrolki nazywać w stylu CameraOnButton
, LoopTimer
, SaveImageDialog
, gdzie początkowa część nazwy określa pełnioną funkcję (CameraOn
czy SaveImage
), a sufiks zawiera typ kontrolki (Button
, Timer
itd.). Kontrolki nie są też właściwie skonfigurowane. Pierwsze co się robi po umieszczeniu kontrolki na formularzu to otwiera się okno inspektora obiektów i ustawia się wszystkie właściwości, zanim zacznie się z nimi pracę (czytaj: oprogramowywanie). Twoje kontrolki nawet nie posiadają ustawionych kotwic (Anchors
), więc zmiana rozmiaru okna całkowicie rozwala układ interfejsu (żadna nie reaguje). Czas przysiąść nad tym oknem i poustawiać wszystko jak należy. Do tego nazwa formularza – czyli Formularz
– jest bardzo zła…
Przejdźmy do najważniejszego, czyli do kodu – póki co do kodu projektu CREDO
.
Tutaj jest tak dużo problemów, że trudno opisać je wszystkie… Absolutnie nie stosujesz żadnej przyjętej konwencji, ani co do formatowania kodu, ani co do jego nazewnictwa. Kod pisany jest bardzo niedbale – stusujesz nazwy polskie i angielskie naprzemiennie, również naprzemiennie używasz różnych notacji. Wcięcia są zupełnie randomowe, tak samo jak odstępy (tworzone pustymi liniami). Wplatasz importy funkcji z zewnętrznych bibliotek pomiędzy definicje metod formularza. W komentarzach tłumaczysz działanie kodu i trzymasz niektóre zbędne instrukcje. Do tego masz wycieki pamięci – tworzysz dynamicznie obiekty TBitmap
i nigdzie ich nie zwalniasz. Niektóre metody są bardzo długie – pasuje podzielić je na mniejsze fragmenty.
Kod usiany jest różnymi dyrektywami, a niektóre używane są niezgodnie z ich przeznaczeniem. Np. przełącznik {$MODE}
może być użyty tylko raz w danym module, a w core.pas
masz ich pięć, z czego kilka zaremowanych. Kompilator w takim przypadku weźmie pod uwagę tylko jeden (pierwszy, czyli {$MODE DELPHI}
), a reszta zostanie zignorowana, nawet jeśli nie jest zakomentowana.
Naprawdę mógłbym jeszcze bardzo długo wymieniać problemy istniejące w tych projektach, ale to nie ma sensu.
Zacznij od początku – zorganizuj jak należy strukturę katalogów, stwórz projekty od nowa, w pierwszej kolejności przejdź do ustawień projektu i skonfiguruj wszystko (łącznie z informacjami o wersji i ikonie programu), następnie zajmij się formularzem, poukładaj na nim wszystkie komponenty i skonfiguruj je, a na koniec zajmij się kodem.
Zanim jednak zabierzesz się za pisanie kodu, zapoznaj się z terminami KISS i DRY, a także z artykułem traktującym o przyjętej i uniwersalnej konwencji nazewnictwa oraz formatowania kodu. Dobry artykuł znajduje się tutaj: Object Pascal Style Guide - Embarcadero Developer Network.
Powodzenia! ;)