Szukam Informacji czy są jakieś biblioteki do tworzenia nowoczesnych GUI takich naprawdę fajnych.
0
1
Nie napisałeś, czy chodzi Ci o wersje darmowe, czy rozważasz zakup.
Jeśli płatne też mogą być, to rzuć okiem na https://www.devexpress.com/products/vcl/
1
Jeżeli mowa o aplikacjach okienkowych i nie tylko zmianę skórki, ale też o jakieś dodatkowe kontrolki, to z płatnych warta uwagi jest biblioteka AlphaControls (choć mają też mały, darmowy pakiet). A jeśli chodzi o darmowe rozwiązania to IDE ma w sobie edytor skinów, za pomocą którego możesz zrobić własną skórkę.
1
furious programming napisał(a):
Jeżeli mowa o aplikacjach okienkowych i nie tylko zmianę skórki, ale też o jakieś dodatkowe kontrolki, to z płatnych warta uwagi jest biblioteka AlphaControls (choć mają też mały, darmowy pakiet). A jeśli chodzi o darmowe rozwiązania to IDE ma w sobie edytor skinów, za pomocą którego możesz zrobić własną skórkę.
Ja mam podobne zdanie jak kolega !
Obejrzyj sobie przykłady AlphaControls
Tutaj taki mega przykład aplikacji
http://www.alphaskins.com/sfiles/stable/askineditor.zip
Jak Ci pasuje to kup od razu "Lifetime License with sources" , warte jest to każdych pieniędzy :)
Regularnie są aktualizacje, jak pojawi sie problem to na forum zawsze znajdzie sie ktos kto pomoże (chyba autor)
AlphaControls ma jedna wade bo jest tylko do aplikacji VCL
Przyznaje się ze próbowałem walczyć z tym co jest w standardzie , ale nie szlo to tak płynnie
0
Marek Jakubowski napisał(a):
Szukam Informacji czy są jakieś biblioteki do tworzenia nowoczesnych GUI takich naprawdę fajnych.
A jakie to jest "naprawdę fajne" GUI?
0
AlphaControls robi wrażenie. Az szkoda, że nie ma do LCL. Wydałbym te 99usd. Ostatnio instalowałem fpGUI na Lazarusie, ale po początkowym entuzjazmie niestety lekkie przyhamowanie, wszystkie zdarzenie trzeba sobie ręcznie wpisywać no i bardzo ograniczona interakcja z samym Lazarusem. Projekt fajny ale..
0
machinebyte4 napisał(a):
AlphaControls robi wrażenie. Az szkoda, że nie ma do LCL. Wydałbym te 99usd.
Mam podobne zdanie i też bym się szarpnął, ale nie będzie portu dla LCL – już o to wielokrotnie wnioskowano.
Ostatnio instalowałem fpGUI na Lazarusie […] Projekt fajny ale..
…ale ubogi i niewygodny. :/
Jest jeszcze jedna opcja, ale wymagająca dużej wiedzy i samozaparcia. Chodzi o nadpisanie metod widgetsetu, tak aby to nie system zajmował się renderowaniem okna i komponentów, a własny kod. Aby nie pisać wszystkiego od nowa, wystarczy napisać same metody renderujące, a w pozostałch linkować do bieżącego widgetsetu, którego referencję należy oprzednio zapamiętać, zanim podmieni się tę z globalnej zmiennej WidgetSet.
To póki co tylko koncepcja – jeszcze nie wiem czy to zda egzamin. Ale że przydał by mi się customowy interfejs w bieżącym projekcie, to coraz częściej rozmyślam nad implementacją czegoś takiego.
0
coraz częściej rozmyślam nad implementacją czegoś takiego
A nie myślałeś, żeby zrobić z tego jakiś projekt OS i np. podziałać razem z kilkoma ludzikami z forum Lazarusa?
0
@cerrato: raczej nie – czasu brakuje. :/
0
ostatnio siedzę nad openCV (rozpoznaję, uczę się tego w celach czysto przemysłowych) i tak sie składa, że projekt korzysta z SDL. Akurat sdl jakiś czas temu miałem przyjemność zastosować i przeszła mi przez głowę myśl, żeby ładne gui opracować w oparciu o niego. Nie wiem, czy czasami coś w oparciu o sdl juz nie powstało/powstawało, niemniej kupa pracy aby to zrobić i w dodatku raczej nieopłacalnej.
0
machinebyte4 napisał(a):
Nie wiem, czy czasami coś w oparciu o sdl juz nie powstało/powstawało, niemniej kupa pracy aby to zrobić i w dodatku raczej nieopłacalnej.
Stąd właśnie pomysł, aby nie pisać całego ekosystemu od podstaw, a tylko nadpisać to co odpowiada za wygląd komponentów. Plusem też jest to, że bebechy LCL nie zostaną zmienione, samo środowisko też nie, więc taki sztukowany widgetset będzie można podłączyć w źródłach tylko tego projektu, nad którym się pracuje.
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ć.
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ą ;-)
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.
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.