System Information Tool (SysInfo)

Chciałbym przedstawić mój program - System Information Tool (SysInfo).
Program jest częścią pakietu Ultimate File Manager (https://pawelporwisz.pl/ufm/ufm.php).

Program SysInfo ma za zadanie wyświetlenie podstawowych informacji o sprzęcie i systemie użytkownika. Program przeznaczony jest przede wszystkim dla mniej zaawansowanych użytkowników (to bardzo ważne - program nie wyświetla magicznych cyferek i trudnych do zrozumienia pojęć). Ma na celu szybkie zorientowanie się jaki sprzęt używamy, jak system jest obciążony (procesor/pamięc/dyski) i czy trzeba ewentualnie zabulić za nowy, pachnący i błyszczący :P

Aplikacja SysInfo została napisana w Delphi CE, przez amatora, samouka. Program korzysta z mechanizmu VCL Styles (dzięki czemu wygląda ładnie w trybie ciemnym) oraz wątków. Kreśli proste wykresy kołowe i liniowe. Wiele nauczyłem się dzięki pomocy forumowiczów @furious programming oraz @grzegorz_so, którym dziękuję za pomoc.

W bieżącej wersji program potrafi wyświetlić podstawowe informacje o:

• Systemie komputerowym
• Systemie operacyjnym
• Bieżącym użytkowniku
• Płycie głównej (BIOS)
• Procesorze
• Pamięci (fizycznej, wirtualnej oraz pliku stronicowania)
• Pamięci fizycznej (zainstalowanej)
• Dyskach
• Karcie sieciowej, graficznej (z monitorem) oraz dźwiękowej
• Baterii
• urządzeniach peryferyjnych (klawiatura, urządzenie wskazujące oraz drukarka)

Program potrafi też wygenerować raport (w formacie tekstowym oraz HTML). Format HTML jest moim ulubionym, bo jest ładnie sformatowany i czytelny.

Co sądzicie o takim programie?
Co byście ewentualnie dodali/zmienili/ulepszyli?
Czy widzicie jakieś błędy? Czy program pobiera dane czy się wysypuje :P

SysInfo.zip

Ps: Program jest "czysty". Jeśli twój program antywirusowy zgłasza jakieś nieistniejące zagrożenie, wywal go.

cześć, stworzyłeś naprawdę fajny produkt (program) :) to jest tylko i wyłącznie Twoje dzieło... Sam interfejs ... aż miło popatrzeć :) Jeśli pomogłem w jakimś małym stopniu to cieszę się. Ale faktem jest że to Twoje dzieło

Fajny i ładnie wyglądający program, a sama nazwa nawiązuje chyba do starego SysInfo z Norton Utilities;-)
Wykrył nawet dokładnie model MacBooka, pomimo uruchomienia na nim Windows!

Pepe napisał(a):

Co sądzicie o takim programie?

No cóż — program działa i pokazuje wszystkie informacje, jakie zobligował się pokazać, więc tutaj nie ma się co rozpisywać. ;)

Co byście ewentualnie dodali/zmienili/ulepszyli?

A tu już mogę się rozpisać, bo trochę rzeczy bym zmienił — głównie w interfejsie.

Wyrzuciłbym separator ten który jest nad TPageControl, a etykietkę z wersją bym w ogóle usunął, skoro wersja programu jest podana w oknie About. Dolny separator też bym usunął, bo jest zbędny. Chyba na górze i dole masz kontrolki TPanel, bo np. używasz w połączeniu z Align, to usunąłbym im obramowanie.

Przycisk Close bym usunął, bo po to każde okno ma przycisk do zamykania, aby swoich nie trzeba było dodawać. Własny przycisk przydaje się tylko, gdy formularz ma ustawiony styl bsNone — żeby nie trzeba było używać Alt+F4. Natomiast przycisk Report bym zmodyfikował, dając mu tytuł Create report, Save to file… lub coś pokroju Export data to file… ()w każdym razie z czasownikiem w nazwie), tak aby dokładnie było wiadomo do czego służy. Plus brak opcji eksportu danych do zwykłego pliku tekstowego, co też jest dużym minusem. Przy czym dobrze by było, aby dało się wyeksportować do pliku tekstowego wybrane strony TPageControl.

Samo tworzenie raportu też mi się trochę nie podoba. Raz, że używać okna dialogowego do wyboru katalogu docelowego, a dwa, że raport automatycznie otwiera się w przeglądarce (użytkownik nie ma możliwości wyboru czy chce go otworzyć czy tylko wyeksportować).

Te przyciski w ogóle bym zmienił, bo nie da się do nich dostać z poziomu klawiatury, więc UX troszkę cierpi. Zmieniłbym je na zwykłe TButton, a jeśli bardzo chcesz z ikonkami, to na TBitButton. W każdym razie na pewno bym wybrał którąś z klas przycisków dziedziczących po TWinControl.

Nie ma też żadnej możliwości szybkiego skopiowania danych z tych pól. Jeśli będę chciał skopiować np. nazwę procesora, to pozostanie mi albo przepisać sobie ją ręcznie, albo wygenerować pełny raport. To można rozwiązać na wiele sposobów — można zamiast etykiet użyć TEdit bez obramowania (tak jak to jest w oknach systemowych narzędzi), można też obsłużyć menu kontekstowe, a można np. po najechaniu kursorem wyświetlić małą ikonkę do kopiowania treści.

Nie wiem też czy rozmiar etykiet z informacjami w TPageControl jest hardkodowany, ale jeśli nie, to zabezpiecz się przed skalowaniem interfejsu. Bo program wygląda tak, jakby jego minimalny rozmiar (Constraints) był dopasowany do rozmiaru etykiet i odstępów między nimi. No i nie wiem też, czy nie trafi się taka sytuacja, że zawartość etykiety będzie na tyle długa, że najdzie na obrazek w dolnym rogu TPageControl. Jeśli jest taka możliwość, to bym po prostu sprawdzał czy etykieta nachodzi na obrazek i jeśli tak, to bym te obrazki ukrył we wszystkich zakładkach. Poza tym zastanowiłbym się nad TScrollBox, w razie gdyby etykiety mogły być naprawdę długie oraz miały większą wysokość niż założyłeś.

Piszę o tym dlatego, że niektóre etykiety nie mieszczą się w oknie, gdy to jest małe (TEdit by rozwiązał ten problem):

Czy widzicie jakieś błędy? Czy program pobiera dane czy się wysypuje :P

Wszystko działa dobrze, a informacje pobiera sprawnie, mniej więcej w 3-4 sekundy. Natomiast jest jeden poważny błąd — jeśli spróbuję zapisać raport w lokalizacji, do której program nie ma praw zapisu (np. bezpośrednio na C:\), to pojawi się okienko błędu, ale przycisk do tworzenia raportu zostaje zablokowany i aby jeszcze raz spróbować wygenerować raport, trzeba wyłączyć i włączyć ponownie program.

No i dziwne jest to, że program tworzy plik .ini dopiero podczas eksportu raportu, zamiast przy rozruchu, kiedy wykryje, że go nie ma. IMO to trochę dziwne zachowanie, a sam byłem zdziwiony, bo myślałem, że raport składa się z dwóch plików, a nie z jednego (tylko .html).

Jest też jedna nieścisłość w interfejsie — w głównym oknie strony komponentu TPageControl mają kolor biały:

natomiast w oknie ustawień przyjmują kolor formularza, co wygląda brzydko:

Interfejs nie jest spójny. No i w innych oknach też są te nadmiarowe separatory pod nagłówkami. Poza tym, we wszystkich oknach zwiększyłbym odstęp TPageControl od krawędzi, tak do 8px. No i naprawił odwieczny problem z renderowaniem tytułów TGroupBox, dodając po jednej spacji przed i po tytule. A tak w ogóle to bym te TGroupBox wypierdzielił z głównego okna, bo ich tytuły jedynie duplikują nazwy zakładek. :D

Ps: Program jest "czysty". Jeśli twój program antywirusowy zgłasza jakieś nieistniejące zagrożenie, wywal go.

U mnie nie było żadnych problemów. Przy czym mam tylko systemowego Defendera, ale ten w zupełności wystarczy.

Dzięki za uwagi.
Widzę, że użyłeś do testów programu z interfejsem klasycznym (UI z Windows). Główny nacisk kładłem na tryb ciemny (ten korzysta z VCL Styles), ponieważ nie bardzo lubię jasny interfejs, szkoda oczu :P
Nie oznacza to oczywiście, żeby zaniedbać styl klasyczny. Niestety, ograniczony jestem dostępnymi rozwiązaniami. O ile wiem, aplikacje Delphi oparte na VCL mogą korzystać ze stylu klasycznego Windows (ze stylem zdefiniowanym domyślnie w xml, w oparciu o ComCtl32.dll) lub bez nich (wygląd rodem z WinXP, jeśli zmodyfikujemy manifest). Można też korzystać z mechanizmu VCL Styles (ma wiele problemów, ale daje fajne efekty) lub ewentualnie rozwiązań trzecich (zazwyczaj płatne komponenty).

Program przy pierwszym uruchomieniu sprawdza, czy w systemie operacyjnym ustawiona jest opcja trybu ciemnego (dla aplikacji) i ustawia tryb ciemny (VCL Styles) lub "jasny" (klasyczny Windows).
Plik konfiguracyjny INI powinien utworzyć się przy pierwszym odpaleniu! (wtedy też program sprawdza dostępne klasy WMI oraz tworzy wpisy do pseudo-cache, dzięki czemu kolejne odpalenie programu nie wymaga sprawdzania dostępnych klas WMI, co znaczeni skraca czas dostępu do danych).

Spróbuję odnieść się do Twoich uwag:

Wyrzuciłbym separator ten który jest nad TPageControl, a etykietkę z wersją bym w ogóle usunął, skoro wersja programu jest podana w oknie About. Dolny separator też bym usunął, bo jest zbędny. Chyba na górze i dole masz kontrolki TPanel, bo np. używasz w połączeniu z Align, to usunąłbym im obramowanie.

Rozważę usunięcie separatorów (ale tylko w trybie jasnym). Etykieta wersji zniknie, jak program wyjdzie z fazy Beta (Zrobione)

Przycisk Close bym usunął, bo po to każde okno ma przycisk do zamykania, aby swoich nie trzeba było dodawać. Własny przycisk przydaje się tylko, gdy formularz ma ustawiony styl bsNone — żeby nie trzeba było używać Alt+F4. Natomiast przycisk Report bym zmodyfikował, dając mu tytuł Create report, Save to file… lub coś pokroju Export data to file… ()w każdym razie z czasownikiem w nazwie), tak aby dokładnie było wiadomo do czego służy.

Hmm, chyba tak zrobię, w sumie po co dublować tę samą funkcjonalność. Nazwę dałem taką krótką, bo nie chciałem tak długiego przycisku :P No, ale może można go zwiększyć nieco, skoro wywalę przycisk "Close". (Zrobione)

Plus brak opcji eksportu danych do zwykłego pliku tekstowego, co też jest dużym minusem. Przy czym dobrze by było, aby dało się wyeksportować do pliku tekstowego wybrane strony TPageControl.

To jest ciekawe... zastanawiam się, czy zajrzałeś do Ustawień programu. Tam jest opcja, do zmiany formatu raportu. Do wyboru jest HTML oraz TXT. Można też wybrać, które dane chcemy wyeksportować (tak, mogłem to zrobić tak, że te opcje pokażą się po kliknięciu w przycisk 'Report', ale zdecydowałem się na to, że to wszystko będzie w ustawieniach programu).

Samo tworzenie raportu też mi się trochę nie podoba. Raz, że używać okna dialogowego do wyboru katalogu docelowego, a dwa, że raport automatycznie otwiera się w przeglądarce (użytkownik nie ma możliwości wyboru czy chce go otworzyć czy tylko wyeksportować).

Tutaj jak wyżej... są na to odpowiednie opcje. Możesz zostawić domyślnie (czyli program zapyta gdzie utworzyć raport), możesz ustawić domyślny katalog wyjściowy dla raportu. Zrealizowałem to też tak, że raport możesz otworzyć (bez zapisywania go) lub otworzyć i zapisać (i kilka powiązanych z tym opcji).

Te przyciski w ogóle bym zmienił, bo nie da się do nich dostać z poziomu klawiatury, więc UX troszkę cierpi. Zmieniłbym je na zwykłe TButton, a jeśli bardzo chcesz z ikonkami, to na TBitButton. W każdym razie na pewno bym wybrał którąś z klas przycisków dziedziczących po TWinControl.

To są chyba TSpeedButton (choć już nie pamiętam). Nie ma jakiejś specjalnej przyczyny dlaczego akurat ten. Dawno temu takiego użyłem i zostało (ten program jest reanimacją mojego starego projektu).

Nie ma też żadnej możliwości szybkiego skopiowania danych z tych pól. Jeśli będę chciał skopiować np. nazwę procesora, to pozostanie mi albo przepisać sobie ją ręcznie, albo wygenerować pełny raport. To można rozwiązać na wiele sposobów — można zamiast etykiet użyć TEdit bez obramowania (tak jak to jest w oknach systemowych narzędzi), można też obsłużyć menu kontekstowe, a można np. po najechaniu kursorem wyświetlić małą ikonkę do kopiowania treści.

Tak, pełna zgoda. W przyszłości spróbuję zmienić TLabel na TEdit z odpowiednimi flagami, aby ukryć krawędzie (nie zrobiłem tego, bo to dużo zmian i uznałem, że bez tego da się żyć). Ale z pewnością to jedna z rzeczy do ulepszenia (tutaj to nie wiem jak to najłatwiej zrobić... może jednak jakaś opcja kopiowania przy każdej kontrolce, bo w trybie Ciemnym z VCL Styles z kontrolką TEdit jest za dużo zabawy (trzeba by zmieniać kolor tła i fontu, aby dopasować... zobaczę w przyszłości)

Nie wiem też czy rozmiar etykiet z informacjami w TPageControl jest hardkodowany, ale jeśli nie, to zabezpiecz się przed skalowaniem interfejsu. Bo program wygląda tak, jakby jego minimalny rozmiar (Constraints) był dopasowany do rozmiaru etykiet i odstępów między nimi. No i nie wiem też, czy nie trafi się taka sytuacja, że zawartość etykiety będzie na tyle długa, że najdzie na obrazek w dolnym rogu TPageControl. Jeśli jest taka możliwość, to bym po prostu sprawdzał czy etykieta nachodzi na obrazek i jeśli tak, to bym te obrazki ukrył we wszystkich zakładkach. Poza tym zastanowiłbym się nad TScrollBox, w razie gdyby etykiety mogły być naprawdę długie oraz miały większą wysokość niż założyłeś.

Piszę o tym dlatego, że niektóre etykiety nie mieszczą się w oknie, gdy to jest małe (TEdit by rozwiązał ten problem):

Program powinien się skalować (interfejs wraz z kontrolkami). Obrazki nie będą skalowane (oprócz tych z nagłówka i about oraz okien pobierania danych) - w ogóle ich nie pokazuję przy DPI<>96. Zdecydowałem się na takie rozwiązanie, bo nie chciałem zwiększać rozmiaru exe (bo musiałbym dodawać obrazki dla DPI>100%). ALE, to się zmieni jak zaimplementuję rozwiązanie, w którym wszystkie obrazki zostaną przeniesione do osobnego pliku dll (rozważam taką opcję).

Tak - niektóre kontrolki Tlabel przyjmują ciągi znaków, które są za długie (zostawiłem to tak jak jest - użytkownik może powiększyć okno)

Wszystko działa dobrze, a informacje pobiera sprawnie, mniej więcej w 3-4 sekundy. Natomiast jest jeden poważny błąd — jeśli spróbuję zapisać raport w lokalizacji, do której program nie ma praw zapisu (np. bezpośrednio na C:\), to pojawi się okienko błędu, ale przycisk do tworzenia raportu zostaje zablokowany i aby jeszcze raz spróbować wygenerować raport, trzeba wyłączyć i włączyć ponownie program.

Tak, do poprawy (blokuje przycisk, żeby go nie naklikać klika razy - ale zapomniałem o obsłudze błędów :P) (Poprawione)

No i dziwne jest to, że program tworzy plik .ini dopiero podczas eksportu raportu, zamiast przy rozruchu, kiedy wykryje, że go nie ma. IMO to trochę dziwne zachowanie, a sam byłem zdziwiony, bo myślałem, że raport składa się z dwóch plików, a nie z jednego (tylko .html).

To jest niemożliwe. Program tworzy plik INI (konfiguracyjny) przy 1 uruchomieniu programu. Jeśli plik istnieje, dane zapisywane są przy zamykaniu lub zmianie ustawień.
Plik raportu jest 1 plikiem (obrazki kodowane są w Base64, a style CSS są w sekcji Head).

Jest też jedna nieścisłość w interfejsie — w głównym oknie strony komponentu TPageControl mają kolor biały:
natomiast w oknie ustawień przyjmują kolor formularza, co wygląda brzydko:

Tak, to prawda. Chyba będę musiał to zmienić (Poprawione)

Interfejs nie jest spójny. No i w innych oknach też są te nadmiarowe separatory pod nagłówkami. Poza tym, we wszystkich oknach zwiększyłbym odstęp TPageControl od krawędzi, tak do 8px. No i naprawił odwieczny problem z renderowaniem tytułów TGroupBox, dodając po jednej spacji przed i po tytule. A tak w ogóle to bym te TGroupBox wypierdzielił z głównego okna, bo ich tytuły jedynie duplikują nazwy zakładek. :D

Pomyślimy...

Program na pewno poddany zostanie jeszcze pewnym zmianom... też w kodzie... chcę użyć tablic dwuwymiarowych dla danych, które mogą mieć więcej instancji (np. monitor). Teraz używam TStringList i jest to tylko kłopot. Ogólnie, program ma być użyteczny ale też prosty i czytelny.

-Pawel

Pepe napisał(a):

Widzę, że użyłeś do testów programu z interfejsem klasycznym (UI z Windows).

Sprawdziłem oba, ale tryb jasny mam ustawiony w systemie, więc klasyczny w aplikacji był domyślnym. Wolałbym tryb ciemny (wszystko ciemne, belki i zawartość okien), ale jeśli go włączę w systemie, to tylko niektóre okna są ciemne (tylko systemowe), a reszta jest jasna (np. okba Lazarusa). Dlatego ten temat póki co olewam.

Niestety, ograniczony jestem dostępnymi rozwiązaniami.

Jeśli chodzi o tło TPageControl, to jedyny powód jaki widzę, dla którego strony tego komponentu mają szare tło w oknie ustawień, ale jasne (prawidłowe) tło w głównym oknie, to ustawiony ParentBackground na True w oknie ustawień. Gdyby to było ograniczenie VCL, to wszystkie instancje miałyby strony w kolorze formularza, a tak nie jest.

Plik konfiguracyjny INI powinien utworzyć się przy pierwszym odpaleniu!

Ostatnio odpalałem program bezpośrednio z pulpitu i mogłem odnieść mylne wrażenie, że plik pojawiał się dopiero po wygenerowaniu raportu. Sprawdziłem to jeszcze raz, tym razem odpalając program z innej, nie systemowej partycji (np. F:\) i plik pojawił się od razu. Tak więc mój błąd, zwracam honor — wszystko działa prawidłowo. ;)

Rozważę usunięcie separatorów (ale tylko w trybie jasnym).

W trybie ciemnym nie widać górnego separatora, ale dolny widać. Sugerowałem ich usunięcie, dlatego że sam TPageControl bardzo wyraźne oddziela te trzy sekcje (w obu skórkach), dlatego ich istnienia określam jako nadmiarowe.

To jest ciekawe... zastanawiam się, czy zajrzałeś do Ustawień programu.

No tak, jest opcja, ale dlaczego użytkownik ma nie mieć wyboru ustawień eksportu podczas samego eksportowania? Klinie przycisk raportu i jedyne co może wybrać to lokalizację docelową. Nie ma opcji wyboru formatu, nie ma nawet opcji wyboru nazwy pliku. To określam jako spory minus.

Lepszym rozwiązaniem byłoby skorzystanie z TOpenDialog — on zapewni wszystko co potrzeba. Będzie można wygodnie wybrać lokalizację (i widzieć jakie pliki znajdują się w wybranym katalogu), będzie można wybrać nazwę pliku docelowego oraz jego format (.html, .txt itp.). Nie będzie trzeba wędrować po oknach, jeśli się zmieni zdanie co do docelowego formatu.

Sam wolałbym stworzyć własne okno dialogowe i wrzucić takie kontrolki, aby można było wybrać wszystko co potrzeba. Systemową kontrolkę do wyboru lokalizacji docelowej (nie pamiętam jak się ona nazywa), TComboBox do wyboru formatu, TEdit do wyboru nazwy docelowej, a także TCheckListBox do wyboru sekcji, których dane mają być eksportowane. Jest to bardzo proste do zrobienia.

Tam jest opcja, do zmiany formatu raportu. Do wyboru jest HTML oraz TXT. Można też wybrać, które dane chcemy wyeksportować (tak, mogłem to zrobić tak, że te opcje pokażą się po kliknięciu w przycisk 'Report', ale zdecydowałem się na to, że to wszystko będzie w ustawieniach programu).

Jeśli będę chciał wygenerować pełny raport .html oraz krótszy raport .txt, to będę musiał wędrować po oknach i zmieniać ustawienia programu, choć jedyne co potrzebuję to wybrać opcje dotyczące eksportu. Dlatego właśnie uznaję to za wadę.

To są chyba TSpeedButton (choć już nie pamiętam). Nie ma jakiejś specjalnej przyczyny dlaczego akurat ten. Dawno temu takiego użyłem i zostało (ten program jest reanimacją mojego starego projektu).

Najpewniej TSpeedButton, jednak to nie zmienia faktu, że focusa nie posiadają. A powinny.

W przyszłości spróbuję zmienić TLabel na TEdit z odpowiednimi flagami, aby ukryć krawędzie (nie zrobiłem tego, bo to dużo zmian i uznałem, że bez tego da się żyć).

Jeśli te wszystkie etykiety są stworzone w designerze, to zawsze możesz otworzyć plik .dfm np. w Notepad++ i zmienić typ tych komponentów na TEdit oraz właściwość Caption na Text. Potem otworzyć projekt w Delphi, zignorować ewentualne błędy dotyczące nieistniejących właściwości. Potem zostanie tylko poukładać kontrolki na formie, tak aby miały odpowiednie pozycje i gotowe.

Zawsze możesz dodać TPopupMenu do każdej etykiety i dynamicznie kopiować zawartość, używając Sendera zrzutowanego na TLabel. Albo jeszcze inne rzeczy — tutaj jest spore pole do popisu.

Program powinien się skalować (interfejs wraz z kontrolkami). Obrazki nie będą skalowane (oprócz tych z nagłówka i about oraz okien pobierania danych) - w ogóle ich nie pokazuję przy DPI<>96. Zdecydowałem się na takie rozwiązanie, bo nie chciałem zwiększać rozmiaru exe (bo musiałbym dodawać obrazki dla DPI>100%). ALE, to się zmieni jak zaimplementuję rozwiązanie, w którym wszystkie obrazki zostaną przeniesione do osobnego pliku dll (rozważam taką opcję).

Olej rozmiar .exe, bo dziś nikogo to nie obchodzi. Program ma działać szybko i poprawnie, a nie ważyć mało.

Zawsze możesz dodać TPopupMenu do każdej etykiety i dynamicznie kopiować zawartość, używając Sendera zrzutowanego na TLabel. Albo jeszcze inne rzeczy — tutaj jest spore pole do popisu.

à propos tego... Mógłbyś to rozwinąć?

Dzisiaj próbowałem zrobić taki myk, że do każdej kontrolki TLabel dodaje TPopupMenu (o nazwie "CopyMenu") z jednym poleceniem menu - ""Kopiuj dane"

Przypisuje TPopupMenu do interesującej mnie kontrolki:
Lbl_WMI_ComputerName.PopupMenu := CopyMenu;

User klikający prawym klawiszem myszy na kontrolce wywołuje ten popup - ale jak pobrać tekst kontrolki?
procedure TMainFrm.CopyData1Click(Sender: TObject);
begin
// jak pobrać tekst kontrolki TLabel?
end;

Ps: Testowałem z funkcją FindDragTarget(Mouse.CursorPos, True) uzyskując nazwę kontrolki, a potem iterowałem po komponentach typu TLabel, żeby pobrać Caption... ale to nie zawsze działa. I jest chyba zbyt skomplikowane... musi być prostszy sposób.

Postanowiłem nieco zmienić tworzenie raportu, zgodnie z sugestią @furious programming
Przeniosłem ustawienia raportu z ustawień programu do specjalnego kreatora tworzenia raportu, gdzie użytkownik może sobie ustawić opcje raportu tuż przed jego utworzeniem.

Przyciski są wciąż bez obrazków, ale już zmieniłem część z nich na przycisk TButton.
Problemem jest skalowanie obrazków na przyciskach. Chętnie dowiem się, jak obsłużyć przyciski TButton z ikonką/obrazkiem PNG/BMP - który skaluje się wraz z innym DPI.
Nowe Delphi ponoć obsługuje TImageList dla różnych DPI, ale nie wiedziałem nigdzie jak to naprawdę działa i jak to obsłużyć...

SysInfo.zip

Jak na sprawdzianie. :D

Usuń wielokropek z pierwszego zdania — jego w interfejsie używa się praktycznie wyłącznie w przyciskach, które otwierają okna dialogowe. Po drugie, zamień miejscami radio-przyciski z formatem — jeśli .html jest domyślny, to powinien być pierwszy.

Nie wiem po co jest checkbox Save Report on Disk — przecież po to się raport generuje, aby był zapisany w pliku niezależnym od programu. Poniżej jego są dwa radio-przyciski, których istnienie jest bez sensu. Użytkownik zawsze powinien mieć możliwość wybrania lokalizacji docelowej, więc pole edycyjne ze ścieżką pliku oraz przycisk do wyboru katalogu powinny być zawsze aktywne.

Niżej jest pole edycyjne dla nazwy pliku — daj możliwość podania nazwy z rozszerzeniem. Niech użytkownik robi co chce i jak chce to niech sobie wpisze rozszerzenie, a program powinien sprawdzić czy jest odpowiednie (porównując literki bez rozróżniania ich wielkości) i jeśli jest nieprawidłowe, to je dodać. obok tego pola jest combobox z formatem daty i czasu — fajnie by było, gdyby zawierał bieżącą datę i czas, a nie jakąś randomową. Po prostu timerem (np. )co sekundę) bym modyfikował pozycje tej kontrolki, aby ich dane były zgodne z zegarem systemowym.

Pole Ask user to override existing file if it already exists jest zbędne — zawsze pytaj w takim przypadku.

Pozycję Terminate the application after creating the report file bym zmodyfikował i zamiast słowa Terminate użył Close, które ma neutralny wydźwięk. Terminate brzmi złowieszczo, tak jakby aplikacja miała być ubita, a nie spokojnie zamknięta.

Na samym dole są przyciski z wyborem kolorów — trochę słabo, że kolory można wybrać, ale da się w żaden sposób podglądnąć efektu końcowego. Zresztą, te dane nie są zbyt istotne, bo wartością raportu nie jest jego wygląd, a informacje o sprzęcie.

Na dole okna masz przyciski Back, Next i Cancel, z czego Back jest zablokowany. AFAIR lepiej by było go ukrywać i pokazywać, niż blokować i odblokowywać. No ale to tylko moje subiektywne zdanie, pierdółka nie mająca większego znaczenia.

Zobacz jak tytuły tych checkboxów są duplikowane — to jest bez sensu. Po drugie, zamiast Show, powinno być Include, bo tu nie chodzi o ich widoczność, a o ich uwzględnienie w raporcie. Jeśli wyrzucisz z tytułów tych przycisków powtórzenia, to zostaną króciutkie informacje, które będzie się wygodnie przeglądało.

​
Jest jeden poważny błąd — po wciśnięciu przycisku zapisu raportu (w kreatorze), program wyświetla popup z postęp zbierania informacji, a następnie wyświetla okno dialogowe do wyboru lokalizacji, a dopiero potem zapisuje plik. Czyli działa to tak, że lokalizacja wybrana w kreatorze nie jest używana, a plik zapisuje się tam, gdzie wybierzemy w tym dodatkowym oknie dialogowym. To jest ewidentny błąd, więc do poprawy.

Jeśli chodzi o mniejsze problemy, to jednym z nich jest absolutny brak hintów w oknie kreatora — tylko przyciski do nawigacji je mają. Zasada dobrego interfejsu jest taka, że każdy znaczący komponent (szczególnie przyciski każdego rodzaju i pola edycyjne) powinny mieć ustawiony hint i jasno informować o przeznaczeniu danej opcji, w formie skróconej.

furious programming napisał(a):

Jak na sprawdzianie. :D

Siadaj, dwója! :)

Usuń wielokropek z pierwszego zdania — jego w interfejsie używa się praktycznie wyłącznie w przyciskach, które otwierają okna dialogowe.

Zrobione!

Po drugie, zamień miejscami radio-przyciski z formatem — jeśli .html jest domyślny, to powinien być pierwszy.

Zrobione!

Nie wiem po co jest checkbox Save Report on Disk — przecież po to się raport generuje, aby był zapisany w pliku niezależnym od programu. Poniżej jego są dwa radio-przyciski, których istnienie jest bez sensu. Użytkownik zawsze powinien mieć możliwość wybrania lokalizacji docelowej, więc pole edycyjne ze ścieżką pliku oraz przycisk do wyboru katalogu powinny być zawsze aktywne.

Zamysł jest taki. Użytkownik chce utworzyć raport (po to kliknął przycisk "Create Report" w głównym oknie) więc program go generuje.
Jeśli opcja "Save Report on Disk" jest zaznaczona - raport zostanie zapisany w wybranej lokalizacji (o tym zaraz) i ewentualnie wyświetlony w domyślnym programie, w przeciwnym razie raport zostanie tylko wyświetlony w domyślnym programie (a zapisany zostanie w %TEMP%).

Teraz à propos przycisków radio - program umożliwia 2 sposoby zapisu pliku (wyboru lokalizacji). Albo plik raportu będzie zapisywał się w stałej, wybranej lokalizacji (jeśli opcja "Use user defined directory for created report" jest zaznaczona) albo program każdorazowo zapyta o docelowy katalog. Moim zdaniem jest to elastyczne i daje większe pole wyboru.

Niżej jest pole edycyjne dla nazwy pliku — daj możliwość podania nazwy z rozszerzeniem. Niech użytkownik robi co chce i jak chce to niech sobie wpisze rozszerzenie, a program powinien sprawdzić czy jest odpowiednie (porównując literki bez rozróżniania ich wielkości) i jeśli jest nieprawidłowe, to je dodać. obok tego pola jest combobox z formatem daty i czasu — fajnie by było, gdyby zawierał bieżącą datę i czas, a nie jakąś randomową. Po prostu timerem (np. )co sekundę) bym modyfikował pozycje tej kontrolki, aby ich dane były zgodne z zegarem systemowym.

Powyżej wybraliśmy lokalizację zapisu pliku - tutaj określamy jego nazwę (format jest określany automatycznie). Nazwa raportu generowana jest na podstawie nazwy wpisanej przez użytkownika oraz ewentualnie znacznika czasu. Format daty i czasu prezentuje czas wygenerowany przy otwarciu okna kreatora (nie zmieniam go, to jest tylko po to, żeby pokazać jak to będzie wyglądać - prawidłowy czas zapisze się przy faktycznym zapisie pliku na dysku). Owszem, mógłbym go odświeżać co np. sekundę, ale myślę, że to niepotrzebne.

Pole Ask user to override existing file if it already exists jest zbędne — zawsze pytaj w takim przypadku.

No tak, dlatego opcja ta jest domyślna. Ale są sytuacje gdy świadomie ustawiam sobie katalog docelowy zapisu raportu oraz nazwę, która zawsze jest taka sama. Wtedy opcja ta jest bardzo przydatna, bo nie muszę klikać potwierdzenia...

Pozycję Terminate the application after creating the report file bym zmodyfikował i zamiast słowa Terminate użył Close, które ma neutralny wydźwięk. Terminate brzmi złowieszczo, tak jakby aplikacja miała być ubita, a nie spokojnie zamknięta.

Poprawione!

Na samym dole są przyciski z wyborem kolorów — trochę słabo, że kolory można wybrać, ale da się w żaden sposób podglądnąć efektu końcowego. Zresztą, te dane nie są zbyt istotne, bo wartością raportu nie jest jego wygląd, a informacje o sprzęcie.

Tak... ten wybór kolorów ma na celu możliwość zmiany koloru wykresu i koloru linków... no mógłbym tutaj pokazać co się zmienia, ale uznałem że nie trzeba. I tak chyba zostanie (ustawiana jest wartość domyślna, którą nie trzeba zmieniać).

Na dole okna masz przyciski Back, Next i Cancel, z czego Back jest zablokowany. AFAIR lepiej by było go ukrywać i pokazywać, niż blokować i odblokowywać. No ale to tylko moje subiektywne zdanie, pierdółka nie mająca większego znaczenia.

Poprawione!

Zobacz jak tytuły tych checkboxów są duplikowane — to jest bez sensu. Po drugie, zamiast Show, powinno być Include, bo tu nie chodzi o ich widoczność, a o ich uwzględnienie w raporcie. Jeśli wyrzucisz z tytułów tych przycisków powtórzenia, to zostaną króciutkie informacje, które będzie się wygodnie przeglądało.

Zmieniłem słowo "Show" na "Include", masz rację. Ale resztę tekstu zostawiłem taki sam. Owszem, mógłby być bez powtórzenia, ale mnie to nie przeszkadza.

Jest jeden poważny błąd — po wciśnięciu przycisku zapisu raportu (w kreatorze), program wyświetla popup z postęp zbierania informacji, a następnie wyświetla okno dialogowe do wyboru lokalizacji, a dopiero potem zapisuje plik. Czyli działa to tak, że lokalizacja wybrana w kreatorze nie jest używana, a plik zapisuje się tam, gdzie wybierzemy w tym dodatkowym oknie dialogowym. To jest ewidentny błąd, więc do poprawy.

Nie ma błędu. To zależy jaki sposób wyboru lokalizacji docelowej wybierzemy. Okno dialogowe wyboru lokalizacji pojawi się tylko w przypadku, gdy opcja "Choose Output Directory on each report creation" jest zaznaczona (w przeciwnym przypadku użyty zostanie stale zdefiniowany katalog i program nie będzie pytał o niego).

Jeśli chodzi o mniejsze problemy, to jednym z nich jest absolutny brak hintów w oknie kreatora — tylko przyciski do nawigacji je mają. Zasada dobrego interfejsu jest taka, że każdy znaczący komponent (szczególnie przyciski każdego rodzaju i pola edycyjne) powinny mieć ustawiony hint i jasno informować o przeznaczeniu danej opcji, w formie skróconej.

Nie sposób się nie zgodzić... podpowiedzi zaimplementuje w n'tej wersji. Na dzień dzisiejszy ich nie ma.

Najnowszy build:
SysInfo.zip

Dziękuję za uwagi i podpowiedzi!
Wiem, że niektóre opcje mogą się wydawać "przekombinowane", ale dzięki temu mam (użytkownik) większy wybór (a te najbardziej oczywiste ustawiłem jako domyślne).

Pepe napisał(a):

Zamysł jest taki. Użytkownik chce utworzyć raport (po to kliknął przycisk "Create Report" w głównym oknie) więc program go generuje.
Jeśli opcja "Save Report on Disk" jest zaznaczona - raport zostanie zapisany w wybranej lokalizacji (o tym zaraz) i ewentualnie wyświetlony w domyślnym programie, w przeciwnym razie raport zostanie tylko wyświetlony w domyślnym programie (a zapisany zostanie w %TEMP%).

Tylko po co dawać użytkownikowi możliwość samego wyświetlania raportu w przeglądarce, skoro wszystkie te informacje ma wyświetlone w głównym oknie programu? IMO to bez sensu, a przez to interfejs komplikuje uzytkowanie programu. Zmieniłbym to i usunął możliwość samego wyświetlania, a zostawiłbym tylko opcję zapisu na dysku plus dodatkowe wyświetlenie w przeglądarce.

Teraz à propos przycisków radio - program umożliwia 2 sposoby zapisu pliku (wyboru lokalizacji). Albo plik raportu będzie zapisywał się w stałej, wybranej lokalizacji (jeśli opcja "Use user defined directory for created report" jest zaznaczona) albo program każdorazowo zapyta o docelowy katalog. Moim zdaniem jest to elastyczne i daje większe pole wyboru.

I miesza użytkownikowi w głowie, bo jest mocno nieintuicyjne.

Jeśli program ma korzystać z domyślnej, z góry ustalonej lokalizacji, to nic nie stoi na przeszkodzie, aby tę z góry określoną ścieżkę zawsze ustawiać w polu edycyjnym podczas tworzenia okna. Rozbudowałeś system, który rozbudowy absolutnie nie wymaga i który nie powinien być rozbudowany. Program powinien mieć tylko jedno pole z lokalizacją i używać go zawsze, bez względu na inne ustawienia dotyczące generowania.

Pole Ask user to override existing file if it already exists jest zbędne — zawsze pytaj w takim przypadku.

No tak, dlatego opcja ta jest domyślna. Ale są sytuacje gdy świadomie ustawiam sobie katalog docelowy zapisu raportu oraz nazwę, która zawsze jest taka sama. Wtedy opcja ta jest bardzo przydatna, bo nie muszę klikać potwierdzenia...

Im więcej rzeczy zataisz przed użytkownikiem, tym mocniejsze będzie u niego wrażenie, że nie panuje nad tym co robi. Może być tak, że użytkownik nieświadomie będzie działał na swoją niekorzyść, a koniec końców, za wszelką irytację obwini program, nie swoje działania.

Jeśli program ma przeprowadzić operacje, które doprowadzą do utraty jakichś danych (czym nadpisanie pliku jest), to jego obowiązkiem jest poinformować o tym użytkownika i dać mu możliwość wyboru, a tym samym anulowania tej operacji. Program zawsze ma pytać czy nadpisać plik jeśli ten istnieje, wyświetlając czytelny komunikat i posiadający domyślnie zfokusowany przycisk Nie, tak aby uzywając klawiatury, nie dało się przypadkiem potwierdzić wykonania operacji, dłużej przytrzymując klawisz Enter.

Zmieniłem słowo "Show" na "Include", masz rację. Ale resztę tekstu zostawiłem taki sam. Owszem, mógłby być bez powtórzenia, ale mnie to nie przeszkadza.

Wszystko fajnie, ale program nie jest dla Ciebie, a dla użytkowników, którym to będzie przeszkadzało. ;)

Dajesz im listę opcji do zaznaczenia, która wygląda jakby zawierała dużo informacji do przeczytania, a tak naprawdę to w każdej pozycji są dwa unilalne słowa — reszta to powtórzenia. Myślę, że jest to zrobione dlatego, że krótkie pozycje dawałyby sporo wolnej przestrzeni w oknie i wyglądałoby ono na puste. Lepiej wywalić zbędny tekst i checkboksy ułożyć w dwóch kolumnach, niż sztucznie wydłużać ich tytuły.

Nie ma błędu. To zależy jaki sposób wyboru lokalizacji docelowej wybierzemy. Okno dialogowe wyboru lokalizacji pojawi się tylko w przypadku, gdy opcja "Choose Output Directory on each report creation" jest zaznaczona (w przeciwnym przypadku użyty zostanie stale zdefiniowany katalog i program nie będzie pytał o niego).

Wg mnie to jest błąd — projektowy i poważny problem z UX. Nieważne którą opcję zapisu użytkownik wybierze, lokalizacja docelowa zawsze musi się znajdować w jednym polu edycyjnym. Nieistotne czy lokalizacja jest z góry narzucona czy ma być własna, nieistotne co użytkownik ustawi w oknie ustawień programu — jedno pole w jednym miejscu.

Jeśli chodzi o pole z nazwą pliku docelowego, to sprawa wygląda tak samo — jedno pole do ustawienia nazwy, bez żadnych ograniczeń. Domyślnie ma być wypełnione domyślnym ciągiem, ma być opcja podania własnej nazwy razem z rozszerzeniem, a modyfikacja formatu ma nie zmieniać ani nazwy pliku, ani jego rozszerzenia. Jeśli użytkownik chce zapisać raport HTML do pliku report.htm, to powinien mieć taką możliwość (bo jest to poprawne rozszerzenie). Tak samo jesli chce zapisać raport do pliku o nazwie REPORT.HTML, to taki plik powinien zostać utworzony.

No pomyślę o tym...
Ale jedno nie zostanie zmienione. Program obsługuje 2 rozszerzenia plików dla raportu: TXT oraz HTML. I żadnego innego.
Nie dam użytkownikowi możliwości jej zmiany, bo właśnie takie ma być. Nie pdf, nie htm czy inne.

EDIT
Wstępnie dodałem zmiany zapisu raportu do pliku na dysku. Fundamentalne zmiany! Usunąłem wszystko co może być zawiłe bądź zbędne. Prawie zgodnie z sugestiami @furious programming. Teraz w prosty sposób wskazujemy format pliku (html lub txt), ścieżkę zapisu oraz inne opcje (możliwość otwarcia raportu po utworzeniu, zamknięcia aplikacji, etc).

SysInfo.zip

Obecnie pracuję nad dodaniem menu kontekstowego, które pozwoli skopiować linię danych lub wszystkie z danej kategorii. Dzięki temu, aby skopiować dowolną wartość nie trzeba tworzyć raportu (a kontrolki zostały typu TLabel, a nie TEdit (co umożliwiło by proste kopiowanie tekstu) bo tak mi wygodniej.

Coś takiego:

Jak zwykle, dziękuję za głos [sumienia] :)