Delphi 10.3 i GUI

Odpowiedz Nowy wątek
2019-11-28 23:20

Rejestracja: 9 miesięcy temu

Ostatnio: 9 miesięcy temu

Lokalizacja: Warszawa

0

Szukam Informacji czy są jakieś biblioteki do tworzenia nowoczesnych GUI takich naprawdę fajnych.

Pozostało 580 znaków

2019-12-05 11:56
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: Poznań

0

Z drugiej strony to jakbyś to pchnął grupowo, bo są szanse, iż przy zebraniu odpowiedniej grupy, czas potrzebny na stworzenie całego "twojego" ekosystemu - komponentów, skórek itp, by się skrócił. To trochę jak z inwestowaniem w wyposażenie firmy - najpierw trzeba kasę wyłożyć, ale po pewnym czasie zacznie to procentować.


Naczelny forumowy hejter Apple

That game of life is hard to play, I'm gonna lose it anyway
The losing card I'll someday lay, So this is all I have to say

Pozostało 580 znaków

Opi
2019-12-08 15:58
Opi

Rejestracja: 15 lat temu

Ostatnio: 8 miesięcy temu

2020-01-15 19:36

Rejestracja: 16 lat temu

Ostatnio: 3 dni temu

0

No szkoda, że ja tego komentarza wcześniej nie widziałem, kolego @somedev
DevExpress używam, oj będzie z 15 lat i napisałem na tym bardzo, ale to bardzo dużo kodu.
Czy są wolne (jak rozumiem chodzi o dbGrida)? To zależy jak się tego używa, bo jeśli standardowo (czyli View.DataController.DataModeController.GridMode = False) i załadujemy dziesiątki tysięcy, to tak - ładowanie trwa (i pamięć jest siorbana, no ale trzeba rozumieć że dane w tym trybie są zarówno w DataSet jak i DataController dla danego widoku grida).
Potem działa OK.
Podobnie będzie z lookapami, ale to można rozwiązać różnorako.
Ale ja sobie to napisałem zupełnie inaczej (i nie mam na myśli ichniego ServerMode) i jestem odporny na problemy wydajnościowe podczas przeglądani/filtrowania/wyszukiwania danych na liście ze 100 czy 200 tyś rekordów (tak, user ma w nosie argument, że to mu niepotrzebne).

Czy są zabugowane?
Pewnie, ale nie bardziej niż inne biblioteki dobrej jakości. Czyli błędy się zdarzają, ale bez przesady.
Chcesz zabugowane, to spójrz w stronę kontrolek VCL TMS.

Czy są trudne?
Oj, tak - są.
Osobiście miałem nie tylko przyjemność debugowania tego, ale i napisałem z kilkanaście komponentów w oparciu o DevExpress.
Głównym problemem jest to, że architektura nie jest za bardzo podobna do tej znanej z VCL. I w sumie dobrze, bo i wymagania stawiane DevExpresom są znacznie, znacznie większe.

I trzeba tę architekturę zrozumieć i się jej nauczyć, a to bywa trudne, ponieważ nie istnieje dokumentacja do kodu.
Tylko, ta znajomość architektury 90% użytkowników nie będzie do niczego potrzebna.
Generalnie polecam, ale tylko tym którzy mają naprawdę wysokie wymagania i jeśli nie mieli styczności wcześniej z DevExpress, to trzeba się liczyć ze sporą krzywą uczenia się.
Albo szukać zaufanego mentora...

Poza tym, DevExpress jest ogromny i sens w jego wchodzenie będzie tylko wtedy (moim zdaniem), jeśli przejdziemy na to rozwiązanie w całości w obszarze kontrolek wizualnych.
Ale jeśli już to mamy za sobą, to w sumie same pozytywy poza ceną ;-)

Pozostało 580 znaków

2020-01-15 20:55

Rejestracja: 2 lata temu

Ostatnio: 4 miesiące temu

1

Od początku roku ograniczyłem jakąkolwiek aktywność w sieci bo to strata czasu, ale tutaj zrobię wyjątek.

wloochacz napisał(a):

No szkoda, że ja tego komentarza wcześniej nie widziałem, kolego @somedev
DevExpress używam, oj będzie z 15 lat i napisałem na tym bardzo, ale to bardzo dużo kodu.

No ja już koło 10lat i co z tego?

Czy są wolne (jak rozumiem chodzi o dbGrida)? To zależy jak się tego używa, bo jeśli standardowo (czyli View.DataController.DataModeController.GridMode = False) i załadujemy dziesiątki tysięcy, to tak - ładowanie trwa (i pamięć jest siorbana, no ale trzeba rozumieć że dane w tym trybie są zarówno w DataSet jak i DataController dla danego widoku grida).
Potem działa OK.
Podobnie będzie z lookapami, ale to można rozwiązać różnorako.
Ale ja sobie to napisałem zupełnie inaczej (i nie mam na myśli ichniego ServerMode) i jestem odporny na problemy wydajnościowe podczas przeglądani/filtrowania/wyszukiwania danych na liście ze 100 czy 200 tyś rekordów (tak, user ma w nosie argument, że to mu niepotrzebne).

Nie, nie chodzi o dbGrid. Akurat ta kontrolka działa całkiem fajnie, a DataSet też jest zaimplementowany customowy. Akurat działania na BD i chodzenie po rekordach działa dobrze, wyszukiwanie jest szybkie, a przewijanie to doczytywanie w miarę potrzeb kolejnych rekordów to jest ogarnięte. Problem z innymi kontrolkami i ich budowaniem. Mam dość specyficzny problem, ponieważ formy są tworzone programowo, oraz zmieniają się w trakcie życia programu. Dużo paneli. Fakt, że są to skomplikowane okna, ale czas budowania i aktywacji jest po prostu wolny, przez co odpalanie okien i przełączanie zakładek trwa... a user jest szybszy. Nie jest to wina tych złożonych okien - robiłem testy w innych frameworkach czy nawet w innych technologiach i tak samo budowane dynamicznie okna są o wiele szybsze.

Czy są zabugowane?
Pewnie, ale nie bardziej niż inne biblioteki dobrej jakości. Czyli błędy się zdarzają, ale bez przesady.
Chcesz zabugowane, to spójrz w stronę kontrolek VCL TMS.

Są i to bardziej zabuggowane niż co innego. VCL równie zabuggowany. Moim zdaniem cały ekosystem jest gówniany i odchodzę jak najdalej mogę od tego. DevExpressy dla C# są o wiele sprawniejsze i mają mniej błędów, a też troszkę w tym pisałem.

Czy są trudne?
Oj, tak - są.
Osobiście miałem nie tylko przyjemność debugowania tego, ale i napisałem z kilkanaście komponentów w oparciu o DevExpress.
Głównym problemem jest to, że architektura nie jest za bardzo podobna do tej znanej z VCL. I w sumie dobrze, bo i wymagania stawiane DevExpresom są znacznie, znacznie większe.

Też napisałem parę komponentów na tym. Już nie jeden błąd w kodzie DX dla VCL naprawiłem. Błędy które tam są to śmiech na sali. Pewne operacje sa przepychane przez pierdyliard warstw tylko po to, żeby pchać. Do tego pełno wstrzykiwanego kontekstu, który jest modyfikowany przez inne klasy w innych momentach.To jest g**no nie kod.

I trzeba tę architekturę zrozumieć i się jej nauczyć, a to bywa trudne, ponieważ nie istnieje dokumentacja do kodu.
Tylko, ta znajomość architektury 90% użytkowników nie będzie do niczego potrzebna.

Dziwne, bo ja mam dokumentacje kodu w plikach helpu Windowsowego. Jest struktura kontrolek, hierarchia klas, opisane wszystkie property, metody, przykłady kodu.

Generalnie polecam, ale tylko tym którzy mają naprawdę wysokie wymagania i jeśli nie mieli styczności wcześniej z DevExpress, to trzeba się liczyć ze sporą krzywą uczenia się.
Albo szukać zaufanego mentora...

Jeśli ktoś ma wysokie wymagania to ja nie polecam nawet Delphi ruszać, więc nawet nie dochodzę do rozważań o DevExpress...

Poza tym, DevExpress jest ogromny i sens w jego wchodzenie będzie tylko wtedy (moim zdaniem), jeśli przejdziemy na to rozwiązanie w całości w obszarze kontrolek wizualnych.
Ale jeśli już to mamy za sobą, to w sumie same pozytywy poza ceną ;-)

Owszem, cały zestaw kontrolek w moim przypadku został zbudowany na DX, ale to tylko dlatego, że codebase był za duży na porzucenie Embarci a trzeba było rozwoju systemu o nowe funkcje i wygląd. Jeśli nie jest się przykutym, nawet jeśli to przykucie tymczasowe na czas przejście np. te 5 lat, to nie szedł bym w DX czy nawet w Delphi bo obecnie są o wiele lepsze i tańsze technologie.

Masz nieprzyjemny sposób pisania, agresywny, przedstawiasz swoje dziwne przypadki jako prawdę objawioną oraz przede wszystkim zaprzeczasz sam sobie. Sam piszesz o wygórowanych wymaganiach oraz trudności używania tej technologii, ale polecasz ją gościowi, który szuka biblioteki do "tworzenia nowoczesnych GUI takich naprawdę fajnych".

Ja serio już troszkę nacierpiałem przez Delphi oraz DX i mówię jak jest. Mam nadzieję, że nikt nie dał się zwieść, że DX taki wspaniały, tyle, że dla hardcorów ... Więcej nikomu nie bedę radził, ani opinii wydawał to i nie będę już prostował. Daruj sobie też odpisywanie na ten post, bo dalszej dyskusji nie będzie.

edytowany 1x, ostatnio: somedev, 2020-01-15 20:56

Pozostało 580 znaków

2020-01-16 19:48

Rejestracja: 16 lat temu

Ostatnio: 3 dni temu

0
somedev napisał(a):

Od początku roku ograniczyłem jakąkolwiek aktywność w sieci bo to strata czasu, ale tutaj zrobię wyjątek.

wloochacz napisał(a):

No szkoda, że ja tego komentarza wcześniej nie widziałem, kolego @somedev
DevExpress używam, oj będzie z 15 lat i napisałem na tym bardzo, ale to bardzo dużo kodu.

No ja już koło 10lat i co z tego?

Ano to z tego, że zauważam różnicę w używaniu i programowaniu w oparciu o coś.
W tym przypadku w oparciu o DevEx.
To tak jak można używać obiektów lub programować obiektowo i wg mnie nie jest to tożsame.
Można przez dekady rzucać kontrolki na formatkę i uważać się za eksperta...
Tylko ja to widzę inaczej.
A skoro takiś delikatny (a ja agresywny), to od razu napiszę że w/w nie kieruję ad personam, tylko ogólnie.

Czy są wolne (jak rozumiem chodzi o dbGrida)? To zależy jak się tego używa, bo jeśli standardowo (czyli View.DataController.DataModeController.GridMode = False) i załadujemy dziesiątki tysięcy, to tak - ładowanie trwa (i pamięć jest siorbana, no ale trzeba rozumieć że dane w tym trybie są zarówno w DataSet jak i DataController dla danego widoku grida).
Potem działa OK.
Podobnie będzie z lookapami, ale to można rozwiązać różnorako.
Ale ja sobie to napisałem zupełnie inaczej (i nie mam na myśli ichniego ServerMode) i jestem odporny na problemy wydajnościowe podczas przeglądani/filtrowania/wyszukiwania danych na liście ze 100 czy 200 tyś rekordów (tak, user ma w nosie argument, że to mu niepotrzebne).

Nie, nie chodzi o dbGrid. Akurat ta kontrolka działa całkiem fajnie, a DataSet też jest zaimplementowany customowy. Akurat działania na BD i chodzenie po rekordach działa dobrze, wyszukiwanie jest szybkie, a przewijanie to doczytywanie w miarę potrzeb kolejnych rekordów to jest ogarnięte.

Jeżeli piszesz o "doczytywanie w miarę potrzeb kolejnych rekordów" w kontekście grida, to OK jest to dostępne, ale tylko i wyłącznie jeśli pracujemy w trybie ServerMode DevEx'owego TCxGrid'a.
Tylko ten tryb ma zupełnie inne podejście niż wszechobecne TDataSet (którego tam po postu nie ma) i ma swoje ograniczenia.
Jeżeli używasz takiego trybu i pasuje Ci on to OK.

Jeśli piszesz o tym w kontekście używania TCxGrid'a pracującego z TDataSet (nieważne jakim) to zdecydowanie jesteś w błędzie.
Doczytywanie rekordów z bazy danych itd. działa na poziomie TDataSet i sam TCxGrid nie ma tu nic do rzeczy, poza żądaniem pobrania kolejnych rekordów.
Ale to tylko jeśli pracujemy w trybie GridMode, jeśli włączymy ten tryb (a standardowo jest) to cxGrid pobiera wszystkie dane ze źródłowego TDataSet przecież.
Także, coś nie do końca rozumiem jak to ma działać (chociaż ów "customy DataSet" daje tu pewien trop), ale OK - przecież nie ma dyskusji.

Problem z innymi kontrolkami i ich budowaniem. Mam dość specyficzny problem, ponieważ formy są tworzone programowo, oraz zmieniają się w trakcie życia programu. Dużo paneli. Fakt, że są to skomplikowane okna, ale czas budowania i aktywacji jest po prostu wolny, przez co odpalanie okien i przełączanie zakładek trwa... a user jest szybszy. Nie jest to wina tych złożonych okien - robiłem testy w innych frameworkach czy nawet w innych technologiach i tak samo budowane dynamicznie okna są o wiele szybsze.

To ciekawe co piszesz, ponieważ używam analogicznego rozwiązania. To znaczy całe okno (okno, źródła danych, kontenery na kontrolki oraz same kontrolki, itd.) jest budowane dynamicznie.
Swój mechanizm oparłem w całości o DevExowy LayoutControl (który jest kontenerem na kontrolki i zarządzą całym bałaganem związanym z utrzymaniem układu kontrolek), a więc nie używam paneli, PageControl czy innych kontenerów i nie wiem czy ma to jakiekolwiek znacznie (a wydaje się, że nie powinno). Od początku taki był zamysł i nie testowałem innych rozwiązań, ale z tego co piszesz wynika, że powinienem zwrócić na to uwagę.

Tak czy inaczej sam proces budowania okien trwa, że tak powiem, akceptowalnie.
Całe te okna dokuję potem na zakładkach i przełączanie między nimi jest bezzwłoczne.
Tylko ja nie buduję okien z każdym razem; robię to raz, a potem korzystam z już zbudowanych w efekcie czego kolejne wywołanie okna zawsze jest błyskawiczne (oczywiście poza odczytaniem danych - na przykład).
I jeden drobny fakt - prawdą jest, że obsługa skórek w DevEx nie jest "bardzo" wydajna.
Jest ładnie i miło, ale wydajnością ustępują np. Alpha Skins.

Czy są zabugowane?
Pewnie, ale nie bardziej niż inne biblioteki dobrej jakości. Czyli błędy się zdarzają, ale bez przesady.
Chcesz zabugowane, to spójrz w stronę kontrolek VCL TMS.

Są i to bardziej zabuggowane niż co innego. VCL równie zabuggowany. Moim zdaniem cały ekosystem jest gówniany i odchodzę jak najdalej mogę od tego. DevExpressy dla C# są o wiele sprawniejsze i mają mniej błędów, a też troszkę w tym pisałem.

Bez konkretów to tylko słowa.
Co nie znaczy, że nie wierzę w to co piszesz, a być może używamy tego rozwiązania inaczej i zwyczajnie nie trafiłem na jakiś problem.
Mógłbyś napisać jakie to był problemy w DevEx VCL?

Czy są trudne?
Oj, tak - są.
Osobiście miałem nie tylko przyjemność debugowania tego, ale i napisałem z kilkanaście komponentów w oparciu o DevExpress.
Głównym problemem jest to, że architektura nie jest za bardzo podobna do tej znanej z VCL. I w sumie dobrze, bo i wymagania stawiane DevExpresom są znacznie, znacznie większe.

Też napisałem parę komponentów na tym. Już nie jeden błąd w kodzie DX dla VCL naprawiłem.

Ciekawym jakie to był problemy?
I nie pytam z agresji czy jakiegoś "pewnie się nie zna, ja wiem lepiej" tylko z czystej ciekawości.
A może i ja skorzystam na tym, ponieważ jeśli idzie o DevExa to na pewno nie wiem wszystkiego.
A wiedza nic nie waży i nie muszę jej targać na plecach i chętnie się dowiem.

Błędy które tam są to śmiech na sali.

I znowu - bez konkretów to tylko słowa...

Pewne operacje sa przepychane przez pierdyliard warstw tylko po to, żeby pchać. Do tego pełno wstrzykiwanego kontekstu, który jest modyfikowany przez inne klasy w innych momentach.To jest g**no nie kod.

Hmm... nie jestem pewien, czy dobrze zrozumiałeś koncept architektury DevEx.
Możemy dyskutować nad tym, że ona mogłaby by być inna lub lepsza (pewnie, że mogłaby) jednakże takie zdanie jak twoje, wybacz, jest g**no warte.

I jeśli dobrze zgaduję (a muszę, ponieważ nie napisałeś żadnych konkretów) to zauważ że istnieje głęboki sens w DevEx owego wstrzykiwanego kontekstu.
Co do "przepychania operacji", to naprawdę nie zgadnę co masz na myśli.

O ile napisałbyś o "przepychaniu danych" to OK, tak jest w istocie (ale to też zależy co dokładnie chce się osiągnąć i jakimi środkami) i trzeba na to uważać.
Mam tu na myśli dane w kontrolkach "listowych" (grid, lookup, TreeViewList) gdzie trzeba wybrać - albo pełna funkcjonalność z bajerami, ale dane będą zdublowane w kontrolce.
Lub też szybkie działanie, mniejsze zużycie pamięci, ale żegnajcie ficzery typu auto-filtrowanie i filtrowanie, grupowanie, agregacja...
Albo... jedno i drugie, ale czeka nas sporo programowania po stronie obsługi ficzerów.

I trzeba tę architekturę zrozumieć i się jej nauczyć, a to bywa trudne, ponieważ nie istnieje dokumentacja do kodu.
Tylko, ta znajomość architektury 90% użytkowników nie będzie do niczego potrzebna.

Dziwne, bo ja mam dokumentacje kodu w plikach helpu Windowsowego. Jest struktura kontrolek, hierarchia klas, opisane wszystkie property, metody, przykłady kodu.

To jest dokumentacja o tym jak używać danych elementów DevEx (czyli tzw. reference manual), a nie dokumentacja wszystkich wewnętrznych mechanizmów dla developera, który chciałby rozwijać swoje elementy w oparciu o istniejącą architekturę i możliwości DevEx.
Tego nie ma.
Tak, jasne, jest hierarchia klas i opisane właściwości i metody.
Tylko są to elementy obiektów które są publiczne, a niewiele jest opisanych chronionych a prywatnych chyba wcale.
A o pewnych mechanizmach jak np. CustomClass, to w ogóle można zapomnieć.

Generalnie polecam, ale tylko tym którzy mają naprawdę wysokie wymagania i jeśli nie mieli styczności wcześniej z DevExpress, to trzeba się liczyć ze sporą krzywą uczenia się.
Albo szukać zaufanego mentora...

Jeśli ktoś ma wysokie wymagania to ja nie polecam nawet Delphi ruszać, więc nawet nie dochodzę do rozważań o DevExpress...

Można i tak, co nie znaczy że to prawda w ujęciu uniwersalnym.
Innymi słowy - to twoje subiektywne ujęcie problemu, zwłaszcza że pytanie padło o Delphi.

Poza tym, DevExpress jest ogromny i sens w jego wchodzenie będzie tylko wtedy (moim zdaniem), jeśli przejdziemy na to rozwiązanie w całości w obszarze kontrolek wizualnych.
Ale jeśli już to mamy za sobą, to w sumie same pozytywy poza ceną ;-)

Owszem, cały zestaw kontrolek w moim przypadku został zbudowany na DX, ale to tylko dlatego, że codebase był za duży na porzucenie Embarci a trzeba było rozwoju systemu o nowe funkcje i wygląd. Jeśli nie jest się przykutym, nawet jeśli to przykucie tymczasowe na czas przejście np. te 5 lat, to nie szedł bym w DX czy nawet w Delphi bo obecnie są o wiele lepsze i tańsze technologie.

Piszesz z punku widzenia developera, właściciela czy sponsora projektu?
Generalnie zgadzam się, ale to niestety w szczegółach nie jest takie proste i oczywiste.

Masz nieprzyjemny sposób pisania, agresywny, przedstawiasz swoje dziwne przypadki jako prawdę objawioną oraz przede wszystkim zaprzeczasz sam sobie.

Szczerze, to nie wiem o czym piszesz.
Agresywne?
W sumie... mało mnie to obchodzi, ale naprawdę nie wiem gdzie ja w tym wątku byłem agresywny.

Sam piszesz o wygórowanych wymaganiach oraz trudności używania tej technologii, ale polecasz ją gościowi, który szuka biblioteki do "tworzenia nowoczesnych GUI takich naprawdę fajnych".

Po pierwsze nie polecam autorytarnie, a bezpośrednio odnoszę się do Twojego komentarza. I tylko i wyłącznie przez wpis "gdybym mógł to dałbym dwa minusy".
Ja tu próbuję się dowiedzieć w szczegółach co stoi za tym wpisem, a Ty obrażasz się niczym pensjonarka.
I chyba zupełnie bez powodu...

Po drugie, tak - jeśli ktoś ma takie wymagania (ma być ładnie i z fajną funkcjonalnością), to jak najbardziej polecam DevEx dla VCL.
Dlatego, ponieważ na dziś do wyboru mamy: DevEx, Woll2Woll, TMS, Rosinsky VCL no i jeszcze pewnie BergSoft. Mamy jeszcze rodzime X-Files (XDBGrid i inne), ale oferują trochę za mało funkcjonalności aby w ogóle rozważać porównanie do DevEx.
Tylko żaden z tych pakietów nie jest tak bogaty i spójny jak DevEx właśnie.
Z zastrzeżeniem, że DevEx to kloc ogromny i używanie i oprogramowanie tych kontrolek nie jest podobne do tego co znamy z VCL, zwłaszcza jeśli zejdziemy trochę głębiej niż rzucanie kontrolek na formatkę.

A po trzecie, nie sądzę abym sam sobie zaprzeczał.
Natomiast mam niejasne wrażenie, że zwyczajnie i po prostu się czepiasz.

Ja serio już troszkę nacierpiałem przez Delphi oraz DX i mówię jak jest. Mam nadzieję, że nikt nie dał się zwieść, że DX taki wspaniały, tyle, że dla hardcorów ... Więcej nikomu nie bedę radził, ani opinii wydawał to i nie będę już prostował. Daruj sobie też odpisywanie na ten post, bo dalszej dyskusji nie będzie.

Daruj sobie mówienie co mam robić i pisać, bo jeszcze stanę się agresywny wg swojej miary i po co? OK, żarty na bok ;-)
Gdzieżbym śmiał oczekiwać odpowiedzi, ja tam prosty wyrobnik jestem i gdzie mi tam do fachowców...
Tak sobie popiszę, bo net dziś tani.

Pozostało 580 znaków

Odpowiedz

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