TEdit utworzony dynamicznie – jak odczytać wprowadzony tekst?

Odpowiedz Nowy wątek
2019-01-06 12:53
0

Dzień dobry (dobry wieczór) wszystkim.
Przeszukiwałem zasoby forum. Niestety nie udało mi się znaleźć rozwiązania.
Problem jaki próbuję sobie oprogramować to dynamiczne utworzenie dwóch komponentów TEdit, nastepnie
po wprowadzeniu do nich wartości obliczenie ich sumy w odrębnej procedurze podtstawianej do zdarzenia
On Click przycisku utworzonego także dynamicznie.
Jeżeli ktoś wie czy na forum jest coś podobnego, lub może naprowadzić na rozwiązanie to bardzo proszę
o pomoc.

  • u00.pas (0 MB) - ściągnięć: 14
edytowany 1x, ostatnio: furious programming, 2019-01-25 17:00

Pozostało 580 znaków

2019-01-10 18:07
0

Dobry wieczór wszystkim zainteresowanym. Cieszy mnie wasza wymiana poglądów.
Jeśli chodzi zastosowanie ilości formularzy, o której wspomniałem wcześniej w odpowiedzi dla Cerrato, to sprawa wygląda w ten sposób, że w aplikacji muszę zawrzeć około 50 wzorów
wzajemnie przetwarzających dane. Na przykład wzór jeden pobiera dwie wartości, oblicza je według założeń dla tego wzoru i zwraca wartość dla wzoru kolejnego. Wszystkie te wzory
mogę zrealizować według tej samej zasady tj. formularz, okna pobierania danych, przycisk oblicz, akceptuj, prześlij wartość do wskazanej zmiennej, zamknij formatkę. Spodobała mi się
metoda wskazana przez MrYahooo ponieważ stanowi ona fajny szkielet rozwiązania. Oprócz rożnych wzorów pobierane są także różne ilości danych i w związku z tym różne ilości
TEdit do pobierania danych. Jedyne czego tak naprawdę potrzebuję (w moim mniemaniu :-)) to metodę utworzenia formularza dynamicznego zawierającego odpowiednie procedury i zmienne
wewnątrz swojego kodu. A to wszytko chcę tworzyć jako kolejne moduły (unit). Samo wywołanie takiego formularza wyglądałoby mniej więcej tak :

uses
 modul_10;
Okienko.Caption:=wykonaj_wzór_nr_10( rodzic : Tform.Handle) ;

Powoli jakoś sobie zaczynam to wszystko układać. Mam nadzieję, że uda mi się taki szkielet opracować. Chyba, Ze ktoś z Was ma jakąś lepszą radę.
Pozdrawiam

edytowany 1x, ostatnio: furious programming, 2019-01-25 17:01

Pozostało 580 znaków

2019-01-10 18:33
1

No jakoś nie czaje, po co kilkadziesiąt elementów. Może to wynikać z tego, że jestem debilem, albo z tego, że nie do końca się rozumiemy. Znaczy - Ty masz jakąś wizję i opisujesz ją, natomiast to, co się u mnie w głowie pojawia w reakcji na Twój opis nie ma nic wspólnego ze stanem faktycznym ;)

Z tego co napisałeś to rozumiem, że masz jakieś etapy, użytkownik wpisuje dane, które są następnie przetwarzane i posyłane dalej. Tak się zastanawiam, czemu do każdej takiej informacji do wprowadzenia chcesz dawać osobną formatkę, zamiast zrobić jeden formularz, który będzie pobierał dane od użytkownika, a potem je zapisze w stosownym miejscu (chociażby jakiejś tablicy). A później, gdy będziesz wykonywać obliczenia to nie będziesz operował na danych z komponentów formatki, tylko działasz na danych trzymanych gdzieś w pamięci.


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

2019-01-10 20:22
1

@Beginer_01 jeśli dobrze Cię rozumiem, to jest to coś na wzór kreatora? Tzn. okno ma pobrać pewne dane (w jakiejś ściśle określonej ilości), a następnie je przetworzyć i zwrócić gdzieś dalej. Osobiście rozdzieliłbym przetwarzanie danych od ich pobierania (co jest sensowne, vide zasada pojedynczej odpowiedzialności). Można by zrobić tak, że formatka dostaje obiekt przetwarzający dane oraz parametry określające jakie oraz w jakiej ilości te dane należy przetworzyć oraz gdzie zwrócić. Wtedy naprawdę wystarczyła by o wiele mniejsza liczba oddzielnych formatek.

Co do dyskusji @wloochacz i @cerrato to pamiętam moją dyskusję o której wspominał wloochacz. Faktycznie jest to ciekawe rozwiązanie. Jednak osobiście uważam, że do prostszych programów/systemów może być rozwiązaniem zbyt "enterprajsowym". Nie zawsze potrzebujemy mocno skomplikowanych rozwiązań, gdzie wygląd każdego okna definiujemy za pomocą np. configów/bazy danych. Czasami napisanie takiego automatu może zająć więcej czasu niż wyklikanie wszystkiego w IDE oraz sensowne zaprojektowanie aplikacji w "klasyczny" sposób. Jeśli się wszystko ładnie przemyśli to utrzymanie takiej apki nie będzie koszmarem. Sęk w tym, żeby nie pisać kody spaghetti, a ładnie i z rozumem zaprojektować całość.

Nie rozumiem tylko jednej rzeczy którą @wloochacz zarzuca IDE. Brak możliwości precyzyjnego rozmieszczania kontrolek na formatce w design-time. Używam C++ Builder'a ładnych parę lat i nie przypominam sobie sytuacji gdy coś wyglądało inaczej niż to sobie zaprojektowałem w IDE. Jednak nie będę się stanowczo kłócił, gdyż wiadomo, że różne błędy mogą wystąpić.

Co do zarzutu, że nie wiadomo co było wyklikane i siedzi w DFM, a co jest wykonywane z poziomu kodu, to jest łatwy sposób na to. Należy wypracować pewne standardy i ich się trzymać. Taka sama zasada może tyczyć się setki innych rzeczy. Od tego mamy code guide żeby tam zawrzeć takie rzeczy i nie musieć się potem zastanawiać co gdzie siedzi, jak nazywać zmienne, czy jak formatować kod.

Pozostało 580 znaków

2019-01-11 09:46
1
Mr.YaHooo napisał(a):

Co do dyskusji @wloochacz i @cerrato to pamiętam moją dyskusję o której wspominał wloochacz. Faktycznie jest to ciekawe rozwiązanie. Jednak osobiście uważam, że do prostszych programów/systemów może być rozwiązaniem zbyt "enterprajsowym". Nie zawsze potrzebujemy mocno skomplikowanych rozwiązań, gdzie wygląd każdego okna definiujemy za pomocą np. configów/bazy danych.

No to jednak nie pamiętasz jak to jest robione, skoro twierdzisz że wygląd okna definiujemy "za pomocą np. configów/bazy danych" ;-)

Czasami napisanie takiego automatu może zająć więcej czasu niż wyklikanie wszystkiego w IDE oraz sensowne zaprojektowanie aplikacji w "klasyczny" sposób.

Być może, ale nie wydaje mi się.
Po napisaniu ok. 10 klasycznych aplikacji w Delphi miałem dość robienia ciągle tego samego.
I dość borykania się ciągle z tymi samymi problemami.
Stąd zaprojektowałem całe rozwiązanie, rozwijam je i po prostu używam.

Jeśli się wszystko ładnie przemyśli to utrzymanie takiej apki nie będzie koszmarem. Sęk w tym, żeby nie pisać kody spaghetti, a ładnie i z rozumem zaprojektować całość.

Tak twierdzisz?
To powiedz jak zrobić coś takiego w klasycznym podejściu:
Jedziesz do klienta na wdrożenie.
Okazuje się, że klient potrzebuje mieć dodatkowe informacje (np. zestawienie) i na podstawie danych z tego zestawienia chce wprowadzać wartości.
Np. suma zrealizowanych i opłaconych zamówień i na jej podstawie modyfikacja poziomu rabatu dla konkretnych towarów.
Patrzysz na problem i wiesz, że wszystkie dane masz w systemie. Trzeba je tylko wyciągnąć, przetworzyć i pokazać, a potem dodać w sumie całkiem proste DataEntry i już.
Ta funkcjonalność jest nietypowa i dedykowana tylko dla jednego klienta.
Co zrobisz?

Ja zbieram wymagania, wracam do hotelu i rano prezentuje gotowe rozwiązanie (gdzie najbardziej czasochłonnym etapem jest napisanie SQLa do wyciągnięcia danych), które działa w produkcyjnym systemie.
Niczego nie kompiluje.
Niczego nie muszę utrzymywać w postaci jakiegoś zmodyfikowanego okna.

Nie rozumiem tylko jednej rzeczy którą @wloochacz zarzuca IDE. Brak możliwości precyzyjnego rozmieszczania kontrolek na formatce w design-time. Używam C++ Builder'a ładnych parę lat i nie przypominam sobie sytuacji gdy coś wyglądało inaczej niż to sobie zaprojektowałem w IDE. Jednak nie będę się stanowczo kłócił, gdyż wiadomo, że różne błędy mogą wystąpić.

Pozwolę sobie zacytować Ciebie ze starego wątku:

Co więcej, czasem moje ręcznie ustawiane kontrolki nie wychodzą tak fajnie i mam problem z umieszczeniem elementów aby to wyglądało znośnie :]

Nie chodzi o to, że się nie da.
Chodzi o to, że to żmudne i niewdzięczne zadanie.
Mam na myśli rozwiązanie podobne w swojej istocie i prostocie do Dev Express Layout Control.

Co do zarzutu, że nie wiadomo co było wyklikane i siedzi w DFM, a co jest wykonywane z poziomu kodu, to jest łatwy sposób na to. Należy wypracować pewne standardy i ich się trzymać.
Taka sama zasada może tyczyć się setki innych rzeczy. Od tego mamy code guide żeby tam zawrzeć takie rzeczy i nie musieć się potem zastanawiać co gdzie siedzi, jak nazywać zmienne, czy jak formatować kod.

Na papierze wygląda dobrze, a w życiu jak to w życiu...
Uwierz, wiem czym jest Coding Guidelines (pomagałem pisać pierwszą wersję do Spring4Delphi i było to bardzo dawno temu).
Wszystko zależy od tego z kim się pracuje.

Proponuję zapoznać się najpierw z pewnym artykułem:
Why Delphi should have an application dictionary

Patrząc na to co piszecie mam nieodparte wrażenie, że uważacie mnie za kosmitę :D
Ale z drugiej strony, wydaje mi się że, ja po prostu widziałem (od backendu, czyli jak i co dzieje się pod maską, a nie jak to wygląda) trochę więcej różnych systemów klasy enterprise niż klasyczny programista Delphi, stąd mam takie a nie inne podejście.

edytowany 1x, ostatnio: wloochacz, 2019-01-11 09:50

Pozostało 580 znaków

2019-01-11 10:14
0

Patrząc na to co piszecie mam nieodparte wrażenie, że uważacie mnie za kosmitę

Trochę masz rację, ale w dużej mierze wynika to z Twoich nieprecyzyjnych postów kilka pięter wyżej :P

Teraz, gdy opisałeś z czego to wynika, to mamy zupełnie inny obraz tego, co, jak i dlaczego robisz.

Zgadzam się w 300% - tworzenie okien pod wymogi klienta wymaga jakiegoś sposobu/patentu i Twoja wizja jest na pewno lepsza, niż np. trzymanie kilkudziesięciu gałęzi/forków, z czego każda różni się jakimiś detalami (w sensie - osobna kompilacja dla każdego klienta).

Tylko zwróć uwagę - początkowo pisałeś o tym, że robisz dynamicznie bo RAD to kiepski pomysł, nie da się poprawnie rozmieścić elementów, są rozjazdy z interface itp. Dlatego, rozważając takie argumenty, rzeczywiście trochę miałem Cię za kosmitę (ale takiego pozytywnego, a nie psychopatycznego najeźdźcę z Marsa). Obecnie, kiedy wiemy do czego jest Ci to potrzebne, kiedy przysiadłeś do tematu i wyjaśniłeś, z czego takie podejście wynika - raczej wszyscy się zgodzą, że W TWOIM PRZYPADKU takie rozwiązanie jest lepszą opcją. Ale nadal uważam, że w TYPOWYCH rozwiązaniach klasyczne podejście jest wygodniejsze. W RAD sobie układasz okienko z klocków i nie tracisz energii na tworzenie interface, a zamiast pracować nad obsługą przycisków i innych kontrolek, możesz się skupić na "logice biznesowej". Tylko powtarzam - w "typowych" programach w stylu okno główne i kilka dialogów wyskakujących w razie potrzeby. W Twoim przypadku Twoje rozwiązanie jest sensowne, ale raczej mało osób/firm pisze aplikacje z setkami okien, z czego każde może mieć dowolną postać i elementy składowe.


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

2019-01-11 11:25
1
cerrato napisał(a):

Patrząc na to co piszecie mam nieodparte wrażenie, że uważacie mnie za kosmitę

Trochę masz rację, ale w dużej mierze wynika to z Twoich nieprecyzyjnych postów kilka pięter wyżej :P

Fakt i jest to mea maxima culpa
Brak czasu na dokładne wyjaśnienia, tym bardziej że temat jest rooozległy i wymagałby porządnego wprowadzenia.

Teraz, gdy opisałeś z czego to wynika, to mamy zupełnie inny obraz tego, co, jak i dlaczego robisz.

Zgadzam się w 300% - tworzenie okien pod wymogi klienta wymaga jakiegoś sposobu/patentu i Twoja wizja jest na pewno lepsza, niż np. trzymanie kilkudziesięciu gałęzi/forków, z czego każda różni się jakimiś detalami (w sensie - osobna kompilacja dla każdego klienta).

Ciekawe :D
Znam firmę (proszę nie pytać, nie powiem) w PL, która tak własnie rozwija swoje oprogramowanie.
To znaczy, że każde wdrożenie = osobny fork projektu.
Po godzinie rozmowy i krótkiej prezentacji przekonałem człowieka, że to co oni robią przy pomocy 12 programistów ja zrobiłbym 3.

Tylko zwróć uwagę - początkowo pisałeś o tym, że robisz dynamicznie bo RAD to kiepski pomysł, nie da się poprawnie rozmieścić elementów, są rozjazdy z interface itp. Dlatego, rozważając takie argumenty, rzeczywiście trochę miałem Cię za kosmitę (ale takiego pozytywnego, a nie psychopatycznego najeźdźcę z Marsa). Obecnie, kiedy wiemy do czego jest Ci to potrzebne, kiedy przysiadłeś do tematu i wyjaśniłeś, z czego takie podejście wynika - raczej wszyscy się zgodzą, że W TWOIM PRZYPADKU takie rozwiązanie jest lepszą opcją.

Nie tylko dlatego.
Równie istotną kwestią, a może najważniejszą jest standaryzacja.
A to oznacza, ze np. taki podsystem zarządzania lookup'ami działa zawsze dokładnie w ten sam sposób.
Na przykład listy wyboru (lookup). Niezależnie od listy wyboru i jej kontekstu używania, gdzie przez kontekst rozumiem zarówno gdzie danych lookup jest używany (faktura, zlecenie, dokument magazynowy, itd.) i w jakiej kontrolce (grid lub formularz).

Dzięki temu, aby dokonać zmian lub wprowadzić nową funkcjonalność na poziomie lookup'u (np. dodać wyszukiwanie pełnotekstowe w liście wyboru) robię to w jednym miejscu, a działa wszędzie.
Oczywiście to nic nowego, jednakże na tej zasadzie mam zbudowany każdy wspólny element całego systemu.

Ale nadal uważam, że w TYPOWYCH rozwiązaniach klasyczne podejście jest wygodniejsze.

A co to jest typowe rozwiązanie i dlaczego jest wygodniejsze?
Bo naprawdę, szczerze wątpię z tą wygodą...

W RAD sobie układasz okienko z klocków i nie tracisz energii na tworzenie interface, a zamiast pracować nad obsługą przycisków i innych kontrolek, możesz się skupić na "logice biznesowej".

Błagam, doczytaj tamten wątek, bo to co napisałeś powyżej ma się nijak do tego co opisałem.
A poza tym, powiedz proszę gdzie trzymasz tę logikę biznesową?
Na formie?
Jeśli nie na formie to jak sklejasz ją z formą, czyli jak zaimplementowany jest kontroler?

Tylko powtarzam - w "typowych" programach w stylu okno główne i kilka dialogów wyskakujących w razie potrzeby.

Jeśli tego zaczyna być więcej i zaczynasz borykać się z wieloma sprzecznymi wymaganiami od różnych klientów, to takie typowe podejście jest po prostu strzałem w kolano.

W Twoim przypadku Twoje rozwiązanie jest sensowne, ale raczej mało osób/firm pisze aplikacje z setkami okien, z czego każde może mieć dowolną postać i elementy składowe.

Zgoda, że każde okno teoretycznie może (bo mechanizm na to pozwala), ale nie każde będzie miało (bo praktycznie nie dla każdego okna powstają takie wymagania).
Tylko tu nie o to chodzi...
Chodzi o posiadanie pewnych mechanizmów, które pozwalają zmienić dużo w kodzie bazowym, ale bez zmian tego kodu.
Innymi słowy - zamiast dopisywać coś do istniejącego kodu, lepiej napisać klasę która odpowiada za konkretne działanie i wstrzykiwać ją do kodu bazowego.

A ludzie różnie sobie z tym radzą, np. przez dodawanie nowych funkcjonalności w postaci nowych okien, które są dostępne przez jakaś funkcje w menu okna bazowego.
Ale to komplikuje używanie takiego systemu przez użytkowników.
Mam klienta, który policzył mi kliknięcia do wykonania pewnych operacji w systemie. I nie żartuję.
Ino człowiek nie zrozumiał na szkoleniu, że ścieżką którą obrał jest możliwa, ale nieefektywna.
Po prostu zapomniał, że w systemie istnieje mechanizm drill down oraz drill around, który został specjalnie zaprojektowany aby efektywnie poruszać się po całym systemie.

Pozostało 580 znaków

2019-01-11 16:59
0

MrYahooo Dziękuję za odpowiedź. Przeczytałem i zainteresowała mnie twoja propozycja rozwiązania problemu. Ogólnie w tej chwili sytuacja wygląda tak, że w oparciu
o twoją wcześniejszą podpowiedź opracowałem sobie formularz dynamiczny, który jest nazwijmy to "szkieletem" tego co chcę zrobić. Sprawa sprowadza się do tego,
że każdorazowo jest pobierana zmienna ilość danych (kilka zmiennych, od 2 do 5), nastepnie są one przetwarzane według wzoru/wzorów i wynik jest zwracany, jako kolejna zmienna. Generalnie są to różne dane (zmienne - wszystkie typu liczba : Float, Double,Real.. jakkolwiek nazwać) ale każdorazowo muszę je pobrać od użytkownika, przetworzyć i zwrócić jako wartość kolejnej zmiennej. W sumie jestem już blisko rozwiązania przy założeniu, że zrezygnuję z formularza dynamicznego,
ale Twoja podpowiedź bardzo mi się spodobała i właśnie w oparciu o nią chcę podziałać dalej. Jak do tej pory opracowałem sobie szkielet formularza i obecnie staram się opracować go jako odrębny moduł. Wizja moja sprowadza się do tego, że wywołując funkcję zwracającą wynik do danego pola tak naprawdę uruchamiam mechanizm utworzenia formularza, pobrania i weryfikacji danych , następnie po obliczeniu i zwróceniu wyniku formularz zostaje zamknięty. Rozważałem też uwagi od osób obserwujących. Jak napisałem powyżej każdorazowo pobieram nie więcej niż 5 zmiennych. Zatem potrzebowałbym 5 formularzy. Zobaczę. Rozwiązanie o którym
napisałeś powyżej (formatka - obiekt przetwarzający dane) na tym etapie mojej pracy jest jeszcze dla mnie "niewidoczne". Mam małe doświadczenie w Delphi/Lazarus
ponieważ do tej pory zajmowałem się przetwarzaniem danych tekstowych, gdzie nie potrzebowałem żadnych skomplikowanych konstrukcji. Zazwyczaj wystarczyły mi
StringList oraz StringGrid. Ale jest okazja nauczyć się czegoś nowego. Jeszcze raz dziękuję za odpowiedź.
Pozdrawiam Beginer_01

Pozostało 580 znaków

2019-01-11 17:12
1

Ale skoro masz 2-5 pól, to co za problem wrzucić je na formatkę, a potem jedynie zgodnie z potrzebami operować ich visible i pokazywac użytkownikowi tyle, ile na danym etapie jest potrzebne? Moim zdaniem dynamiczne tworzenie jest w tej sytuacji przerostem formy :P


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
edytowany 1x, ostatnio: cerrato, 2019-01-11 17:13

Pozostało 580 znaków

2019-01-12 13:57
1
wloochacz napisał(a):

No to jednak nie pamiętasz jak to jest robione, skoro twierdzisz że wygląd okna definiujemy "za pomocą np. configów/bazy danych" ;-)

Hmm pozwól, że zacytuję Ciebie:

wloochacz napisał(a):

Nie trzymam niczego na formatkach, bo i nie mam formatek w IDE...
Wszystko jest generowane automatycznie w runtime. Layout formatek też, który później można sobie dostosować za pomocą drag'n'drop w aplikacji, a nie w IDE.
Nie trzymam żadnego komponentu typu query na formatce czy DataModule.
Wszystko trzymam w metadanych, system je konsumuje i tworzy co trzeba.

Więc zachowanie apki definiujemy za pomocą metadanych. Gdzieś to musisz trzymać, nie jest to tożsame z tym co napisałem? Tak przynajmniej ja zrozumiałem, że metadane trzymasz albo w jakiejś bazie albo configach :)

wloochacz napisał(a):

Być może, ale nie wydaje mi się.
Po napisaniu ok. 10 klasycznych aplikacji w Delphi miałem dość robienia ciągle tego samego.
I dość borykania się ciągle z tymi samymi problemami.
Stąd zaprojektowałem całe rozwiązanie, rozwijam je i po prostu używam.

Ok zaprojektowałeś i masz. U mnie takiej potrzeby nie ma, więc piszę klasycznie. Jeden i drugi sposób ma swoje wady i zalety.

wloochacz napisał(a):

Tak twierdzisz?
To powiedz jak zrobić coś takiego w klasycznym podejściu:
Jedziesz do klienta na wdrożenie.
Okazuje się, że klient potrzebuje mieć dodatkowe informacje (np. zestawienie) i na podstawie danych z tego zestawienia chce wprowadzać wartości.
Np. suma zrealizowanych i opłaconych zamówień i na jej podstawie modyfikacja poziomu rabatu dla konkretnych towarów.
Patrzysz na problem i wiesz, że wszystkie dane masz w systemie. Trzeba je tylko wyciągnąć, przetworzyć i pokazać, a potem dodać w sumie całkiem proste DataEntry i już.
Ta funkcjonalność jest nietypowa i dedykowana tylko dla jednego klienta.
Co zrobisz?

I tu się wszystko rozbija, chodzi o potrzeby i docelową grupę odbiorców. Kieruję się zasadą YAGNI. Mam na początku jakieś wymagania biznesowe i jeśli czegoś nie mam to nie piszę na zapas, a może się przyda. Mój produkt jest bardziej półkowy, niż dostosowany do konkretnego klienta. Twój wymaga dostosowania pod konkretnego klienta z różnymi wydumkami. Więc jaki sens jest w moim przypadku tworzyć coś z czego jeszcze ani razu nie skorzystałem? Z mojego punktu widzenia - czyste marnotrawstwo czasu.

wloochacz napisał(a):

Ja zbieram wymagania, wracam do hotelu i rano prezentuje gotowe rozwiązanie (gdzie najbardziej czasochłonnym etapem jest napisanie SQLa do wyciągnięcia danych), które działa w produkcyjnym systemie.
Niczego nie kompiluje.
Niczego nie muszę utrzymywać w postaci jakiegoś zmodyfikowanego okna.

No dobrze, a co z testowaniem takiego rozwiązania? Mozolnie przeklikujesz się przez nowego ficzera itp? Testujesz SQL'e? W klasycznym podejściu napiszesz sobie testy i masz pewność, że przy następnej wersji systemu nic się nie rozjedzie, bo wyjdzie Ci na etapie testów. U Ciebie nie mam takiej pewności, bo gdzieś u klienta jest jakiś SQL którego nie masz u siebie i nie możesz go przetestować, ba nawet nie wiesz jak on wygląda. Widziałem już systemy gdzie duża cześć pracy przy takich doróbkach została przerzucona na wdrożeniowców piszących np. procedury składowe w bazie. Wtedy co parę wersji część ficzerów zaczynała działać źle, albo nie działała wcale. Czasami po wgraniu nowej wersji i aktualizacji bazy danych dana funkcja znikała z systemu i wymagała interwencji wdrożeniowca który od nowa pisał ją.

wloochacz napisał(a):

Pozwolę sobie zacytować Ciebie ze starego wątku:

Co więcej, czasem moje ręcznie ustawiane kontrolki nie wychodzą tak fajnie i mam problem z umieszczeniem elementów aby to wyglądało znośnie :]

Ale bardziej mi tu chodziło o same zaprojektowanie wyglądu okna by ładnie wyglądało, a nie że coś mi się rozjeżdża o parę pikseli. To nie CSS, że mamy masę różnych przeglądarek i każda inne błędy ;)

wloochacz napisał(a):

Na papierze wygląda dobrze, a w życiu jak to w życiu...
Uwierz, wiem czym jest Coding Guidelines (pomagałem pisać pierwszą wersję do Spring4Delphi i było to bardzo dawno temu).
Wszystko zależy od tego z kim się pracuje.

Dokładnie, ja w swoim zespole nie toleruję jak ktoś nie stosuje się do ogólnie przyjętych zasad. Poza tym jak po 10 zablokowaniu kodu na code review ktoś nie dostosuje się do przyjętych zasad należy go wywalić z zespołu, bo oznacza to, że ma IQ mniejsze od ziemniaka, albo jest wybitnym indywidualistą. W jednym i drugim przypadku tacy ludzie nie nadają się do pracy w zespole.

wloochacz napisał(a):

Patrząc na to co piszecie mam nieodparte wrażenie, że uważacie mnie za kosmitę :D
Ale z drugiej strony, wydaje mi się że, ja po prostu widziałem (od backendu, czyli jak i co dzieje się pod maską, a nie jak to wygląda) trochę więcej różnych systemów klasy enterprise niż klasyczny programista Delphi, stąd mam takie a nie inne podejście.

Nie, nie uważam Cię za kosmitę. Zgadzam się, że masz ciekawe podejście i rozwiązanie. Jednak w przypadku typowych aplikacji jest to (w mojej opinii) przeinżynierowanie.

Beginer_01 napisał(a):

napisałeś powyżej (formatka - obiekt przetwarzający dane) na tym etapie mojej pracy jest jeszcze dla mnie "niewidoczne". Mam małe doświadczenie w Delphi/Lazarus
ponieważ do tej pory zajmowałem się przetwarzaniem danych tekstowych, gdzie nie potrzebowałem żadnych skomplikowanych konstrukcji.

Takie rozwiązanie jest o tyle fajne, że oddzielasz sobie logikę od formatki. Generalnie można to zrobić w ten sposób, że tworzysz klasę która wykonuje obliczenia. W przypadku kilku klas można tworzyć klasę nadrzędną z której wszystkie inne dziedziczą. Potem do formatki przekazujesz klasę i okno po pobraniu danych wywołuje tylko odpowiednią metodę z klasy przeprowadzającej obliczenia.

Pozostało 580 znaków

2019-01-14 19:47
1

Dobry wieczór wszystkim.
Dziękuję za dyskusję. Kończę temat. W oparciu o rozwiązanie przedstawione przez MrYahooo opracowałem swoje rozwiązanie.. Załączam spakowany katalog.
Jeszcze raz pozdrawiam i dziękuję.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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