Delphi, 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ęć: 12

Pozostało 580 znaków

2019-01-10 00:04
0

W temacie PS2 - ze spokojem, czas mam :D Bardzo chętnie poczytam, co będziesz miał do powiedzenia, bo (jak mawiają policjanci podczas rozmów z dziennikarzami) - sprawa jest rozwojowa ;)

Odnośnie tego, co pisałeś - czyli że sobie coś dopowiadam albo zakładam: to, co napisałem wywnioskowałem z Twoich wcześniejszych postów. Być może coś z tego co pisałeś źle zrozumiałem - w takim razie proszę wyjaśnij/sprostuj.

W zakresie braku odpowiedzi na pytanie - jeśli chodzi o "ilu ludzi w projekcie przy którym pracujesz tworzy to formatki w IDE" to akurat zmartwię Cię, ale zazwyczaj piszę sam, więc pytanie trafiło do nieodpowiedniej osoby ;) Aczkolwiek z człowieczków, których znam i którzy używają Delphi/Lazarusa, prawie wszyscy korzystają z dobrodziejstw RAD (pomijam kwestie komponentów niewidocznych). A jeśli pytasz o coś innego, to doprecyzuj proszę.

"użytkowcy Delphi, uwielbiają klikać i po prostu zapominają, że programista ma przede wszystkim kodować" - no właśnie, mają pisać ISTOTNE rzeczy, dlatego głupoty (które oczywiście muszą być, ale nie są zbytnio twórcze) załatwia za nich IDE/RAD. Odpada walka z przyciskami i suwakami, które się zwyczajnie wyklikuje, przez co masz więcej czasu oraz energii na zajęcie się naprawdę istotnymi/ważnymi rzeczami.

"Potem nie wiadomo co jest w kodzie, a co jest wyklikane i siedzie w DFMie" - ja mam taką zasadę, że jeśli coś się nie zmienia podczas działania programu (np. jakiś przycisk ma 20x200px i jest 5px od lewego górnego narożnika) to robię to na sztywno w inspektorze, natomiast rzeczy, które są dynamicznie dopasowywane tylko "z grubsza" wrzucam na formę, a ich pozycjonowanie daję do stosownych funkcji. Podczas uruchamiania aplikacji, wywołuję ręcznie procedurę układającą elementy, a potem już jest ona wywoływana z automatu podczas zmiany rozmiaru okna (ewentualnie podczas innych czynności, które wymagają wykonania zmian). Zresztą tak naprawdę to o czym piszesz (przynajmniej dla mnie) nie jest jakimś problemem.


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 13:16
1

OK, znalazłem stary wątek :)
Wszystko jest tu, a jeśli mamy dyskutować dalej, to proponuję założyć nowy wątek.

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

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

Odpowiedz
Liczba odpowiedzi na stronę

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