TEdit utworzony dynamicznie – jak odczytać wprowadzony tekst?

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.

0

Był taki temat więc nie będę się rozpisywał.
FindComponent?

0

Wrzuciłeś kawałek kodu, ale nie napisałeś, co się u Ciebie dzieje. Czy całość się kompiluje, ale nie działa tak, jak oczekujesz, czy może jakieś błędy wyskakują podczas kompilacji?

U mnie pojawia się podczas kompilacji błąd w linii 41 - Tedit.FindComponent('e2').;. Po jej zakomentowaniu całość się kompiluje i uruchamia, ale pojawia się jedynie puste okienko. Napisz proszę, jak sprawa wygląda u Ciebie.

0

Dzień dobry.

  1. Clarc Dziękuję za podpowiedź, zajrzałem i raczej sobie poradzę.
  2. Cerrato dziękuję za zainteresowanie. Całość kodu kompiluje mi się bez problemu. Niestety mój brak doświadczenia w programowaniu dynamicznym wyhamował mnie.

Przetestowałem rozwiązanie problemu w środowisku Lazarus w oparciu o FindComponnent (podpowiedź Clarc) i zadziałało. Myślę, że wrzucę rozwiązanie do wątku jak tylko zakończę pracę nad tematem. Jesze raz dziękuję.

0

No fajnie będzie, jak wrzucisz tutaj działający kod. Być może za pewien czas przyda się komuś, kto będzie walczył z podobnym tematem.

1

Dobry wieczór.
Wrzuciłem plik z rozwiązaniem, które zrobiłem w Lazarusie. Dziękuję za zainteresowanie i pomoc.
Rozwiązanie, które wrzuciłem obejmuje tylko wyszukanie komponentów TEdit i odczytanie ich zawartości.
Bez problemu wyszukiwane są komponenty tak statyczne jak i dynamiczne.
Jeszcze raz dziękuję i pozdrawiam

1

Ale po co jakieś FindComponent i działania na około? Skoro sam tworzysz dokładnie 2 komponenty TEdit to zachowaj sobie wskaźniki na nie i ich potem użyj.

Wprowadzasz w taki sposób jakieś magiczne stałe (nazwy komponentów 'e1' oraz 'e2'), gdzie przy ich zmianie kompilator Ci tego automatycznie nie wykryje, tylko program po prostu przestanie działać. Moim zdaniem o wiele lepiej by było zrobić z tych e1 oraz e2 składowe prywatne TForm i zapisywać w nich wskaźniki do utworzonych komponentów TEdit, po to aby później w łatwy sposób się do nich odwołać.

0

Dzień dobry wszystkim.
Mr.YaHooo. Jeżeli możesz wrzucić jakiś przykład to bardzo proszę. Będę miał okazję zapoznać się z Twoim pomysłem. Oczywiście najlepiej by było
gdyby przykład obejmował działającą aplikację, tak abym mógł obejrzeć w działaniu i zapoznać się z kodem. Jeżeli nie sprawi Ci to kłopotu to w Lazarusie.
Pozdrawiam

1

@Beginer_01 co prawda nie mam u siebie na dysku Lazarusa, ale w Delphi jak najbardziej mogę Ci pokazać jak to może wyglądać.

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private declarations }
    editA: TEdit;
    editB: TEdit;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  editA := TEdit.Create(self);
  editA.Left := 100;
  editA.Top := 10;
  editA.Width := 140;
  editA.Height := 40;
  editA.Parent := self;
  editA.Text := 'textA';
  editA.Visible := True;

  editB := TEdit.Create(self);
  editB.Left := 250;
  editB.Top := 10;
  editB.Width := 140;
  editB.Height := 40;
  editB.Parent := self;
  editB.Text := 'textB';
  editB.Visible := True;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  ShowMessage(editA.Text + ' ' + editB.Text);
end;

end.

Czyli kładziesz na formie 2 przyciski. Pierwszy tworzy dwa dynamiczne edity i wypełnia je napisem textA oraz textB. Zostają one zapamiętane jako składowe private o nazwach editA oraz editB.

Drugi przycisk pobiera ich tekst, łączy i wyświetla za pomocą ShowMessage

0

Mr.YaHooo, Dziękuję. zabieram się do tego kodu. Mam jeszcze jedno pytanie. Potrzebuję to zrobić na formularzu tworzonym dynamicznie. Da się równie prosto?.
Jeszcze raz dziękuję i pozdrawiam. :-)

Mr.Yahooo. Zrobiłem w Lazarusie. OK. Dziękuję.

0

A tak w ogóle to zadam pytanie, które powinno było paść na samym początku.
Dlaczego tak Ci zależy na tym, żeby wszystko było tworzone dynamicznie? Czy ma to jakieś sensowne uzasadnienie, czy to taka zabawa dla sportu, albo w ramach ćwiczeń?

0

Dobry wieczór Cerrato. Odpowiedź jest taka, że musiałbym wykonać około 50 różnych formularzy. Na samą myśl, że w aplikacji musiałbym na to wszystko uważać to robi mi się
problem. Dodatkowo zawsze wywoływany jest tylko jeden z tych około 50 formularzy. Różny wygląd formularzy ale ogólna zasada jest taka, że formularz pobiera dane i zwraca wynik.
Nie mam specjalnego doświadczenia programuję tylko przetwarzanie dużych zbiorów danych tekstowych. Stąd problem w utworzeniu formularzy dynamicznych. Niemniej jednak
powoli dochodzę do rozwiązania.
Dziękuję za wiadomość i pozdrawiam

1

Te formularze różnią się całkowicie? Bo może wszystkie 50 da się zastąpić jakimś jednym, dwoma albo trzeba sparametryzowanymi?

0

Chciałem napisać to samo, co @Mr.YaHooo - bo może da się to rozwiązać w inny sposób.
Jest takie pojęcie (mam wrażenie, że na 4P lekko nadużywane) - chodzi o "problem X Y" - https://sluzynski.pl/problem-xy-czyli-kiedy-nie-wiemy-o-pytamy/

Być może wymyśliłeś sobie, że trzeba to zrobić w ten sposób, ale jest znacznie lepsze rozwiązanie. Jak wyjaśnisz dokładnie co robisz i opiszesz nam swój program z większą ilością szczegółów, to może uda się wykminić coś bardziej pasującego, niż tworzenie 50 formularzy, z czego w danej chwili tylko jeden może być widoczny.

0
cerrato napisał(a):

A tak w ogóle to zadam pytanie, które powinno było paść na samym początku.
Dlaczego tak Ci zależy na tym, żeby wszystko było tworzone dynamicznie? Czy ma to jakieś sensowne uzasadnienie, czy to taka zabawa dla sportu, albo w ramach ćwiczeń?

Mam kilkaset okien w systemie. Nie więcej jak kilka (może kilkanaście) z nich **nie jest ** tworzonych całkowicie dynamicznie.
Oznacza to, że nie ma tam formy w IDE, ramek, dziedziczenia i całego syfu związanego z budowanie UI w IDE.

Osobiście uważam, ze jeśli ktoś pisze apkę (głównie, ale nie tylko - bo to zależy) bazodanową, to nie ma dobrego uzasadnienia w tym, aby klepać te formatki w IDE.
I właśnie chyba dla sportu (chociaż, naprawdę są ciekawsze rzeczy aby zawsze robić to samo, tylko za każdym razem ciut inaczej) można je układać w IDE.
Tworzenie formatek w IDE to dobre zastosowanie, ale do szybkiego prototypowania.
Całą reszta to mordęga, włącznie z rozwijaniem i utrzymaniem.

0

No ale wychodząc z takiego założenia to zasadniczo podważasz jedną z głównych wartości Delphi/Lazarusa/Buildera - czyli ideę RAD. A skoro piszesz w Delphi bez wykorzystania VCL i bez wizualnego podejścia do tworzenia formatek, to tak naprawdę mógłbyś pisać w czymkolwiek innym - chociażby w słynnym C++.
Wyjaśnij mi proszę w takim razie, jakie motywy stoją za tym, że wybierasz Delphi, jednocześnie odrzucając jeden z jego (w mojej ocenie) największych atutów?

0
cerrato napisał(a):

No ale wychodząc z takiego założenia to zasadniczo podważasz jedną z głównych wartości Delphi/Lazarusa/Buildera - czyli ideę RAD. A skoro piszesz w Delphi bez wykorzystania VCL i bez wizualnego podejścia do tworzenia formatek, to tak naprawdę mógłbyś pisać w czymkolwiek innym - chociażby w słynnym C++.

Ależ ja korzystam z VCLa i to intensywnie, po prostu nie korzystam z budowania formatek w IDE.
Główne założenie to elastyczność - ta sama aplikacja (kod) może wyglądać (i zachowywać) się inaczej w każdej instalacji.
I nie może różnie wyglądać/działać, bo fajnie by było, tylko musi bo takie postawiłem sobie wymagania, po analizie potrzeb niszy w którą chciałem wejść z własnym produktem.

Wyjaśnij mi proszę w takim razie, jakie motywy stoją za tym, że wybierasz Delphi, jednocześnie odrzucając jeden z jego (w mojej ocenie) największych atutów?

Atutów?
Jakbym słyszał marketoida z Embercadero ;-)

A pokaż mi proszę te atuty, bo ja tam całą masę wad widzę.
Zresztą, jak tak się zastanowisz na zimo nad wadami podejścia RAD, to łatwiej zrozumiesz dlaczego wybrałem taką drogę.
Te ciągłe bindowanie kontrolek dbAware (czy tam LiveBindings - w sumie bez różnicy) w IDE do obrzygania... Ja za leniwy na to jestem.
Również nie bez przyczyny jest kuriozalne słabe wsparcie IDE do projektowania formatek...
Do tego dołóż sobie moją nerwicę natręctw, jeśli mi się coś do piksela nie zgadza w ustaleniu układu kontrolek - OK, przesadzam - ale wk...a mnie to pod niebiosa, jak coś takiego widzę. A zauważam zawsze i wręcz podświadomie...

Pytanie - ilu ludzi w projekcie przy którym pracujesz tworzy to formatki w IDE?
I czy na pewno wszystko wygląda tak, jak powinno?

Wyjaśnię Ci, ale nie teraz. Teraz to mi się przypomniało, że muszę zrobić coś ASAP.
Poza tym konstruktywniej rozmawiać o tym jak, a nie dlaczego.
Ale może być i dlaczego :)

0

Co do idealnego rozmieszczania - kto Ci broni zaznaczyć dany komponent, a potem (jeśli nie jesteś w stanie go stosownie myszką ustawić) w inspektorze sobie zmienić top, left czy height na takie, żeby się idealnie ustawił tam, gdzie chcesz?

Co do atutów - nie jestem żadnym marketingowcem ;)
Wyjaśnij mi proszę jedną rzecz - przecież są środowiska i języki które dają tyle samo (a nieraz więcej), więc gdzie Twoim zdaniem jest mocna strona Delphi (i ogólnie środowisk RAD) i czemu z tego Delphi korzystasz?

Dla mnie ważne jest to, że nie musię się babrać z tworzeniem interface, po prostu wrzucam dany element na formatkę, wyklikuję jego parametry w inspektorze i mogę się skupić na ważniejszych rzeczach (tzw. logice biznesowej), niż walka z położeniem przycisków czy jakichś paneli. Czy programowałeś kiedyś może w czystym WinAPI? Tam program, który nie robi nic, poza wyświetleniem pustego okna, zajmuje koło 100 linii (nie pamiętam teraz dokładnie, ale z 2 ekrany były). Dodanie prostego przycisku to było kolejne kilkanaście/kilkadziesiąt linii. Programiści zauważyli, że to jest jakaś masakra, więc zaczęły powstawać różne patenty - chociażby MFC czy Win32++. Ale nadal wymagały one dużo pisania rzeczy, które zasadniczo nic nie wnoszą do sprawy, a jedynie odpowiadają za zapewnienie podstawowej funkcjonalności, praktycznie takiej samej w każdej aplikacji.

Dlatego kolejnym krokiem było powstanie środowisk RAD - zdejmują one z programisty w bardzo dużym zakresie problem z UI. Po prostu - wrzucasz na formę potrzebne klocki i więcej praktycznie NIC Cię nie interesuje, cała magia dzieje się w tle, niewidocznie, samodzielnie (można to określić magią, ale także można powiedzieć, że RAD chowa ten cały syf przed programistą ;) ).

A teraz Ty twierdzisz (a przynajmniej tak zrozumiałem ostatni post), że cofnięcie się o 2 generacje w metodyce tworzenia aplikacji jest dobrą opcją, a także że lepiej jest wszystko pisać ręcznie. Oczywiście - masz do tego prawo, ale moim zdaniem w ten sposób rezygnujesz z wielu zalet podejścia do tworzenia zgodnego z duchem RAD.

Jeszcze co do fragmentu "Główne założenie to elastyczność" - czy możesz wyjaśnić, co się za tym konkretnie kryje? Bo nie wiem, jaką elastyczność masz na myśli, więc ciężko mi się do tego jakoś odnieść.

W zakresie kontrolek db-aware to mogę się zgodzić, bywa to upierdliwe. Ale cała reszta (z grubsza - to, co widać w oknie aplikacji) jak najbardziej nadaje się do tworzenia RAD. Totalnie nie rozumiem fragmentu "kuriozalne słabe wsparcie IDE do projektowania formatek" - ja w tym niczego kuriozalnego nie widzę, wręcz przeciwnie - klikasz, zaznaczasz, przeciągasz - wszytko się łatwo i wygodnie układa, dopasowuje i uwalnia mnie od konieczności ręcznego wpisywania dziesiątek parametrów. Wyjaśnij proszę, na czym ta kuriozalność polega.

I ważna sprawa - nie czepiam się Ciebie ani nie krytykuję, po prostu jestem mega zdziwiony i zainteresowany Twoim spojrzeniem na sprawę. Dla mnie to, co piszesz to lekki kosmos - jakby ktoś kupił samochód z automatyczną skrzynią biegów, żeby potem cały czas ręcznie sobie biegi przełączać. Owszem, czasami (np. podczas wyprzedzania albo jazdy w nietypowych warunkach) można ręcznie zmienić bieg, ale to są wyjątkowe sytuacje, na ogół to auto samo zajmuje się biegami, odciążając w tym zakresie kierowcę. Tak samo z tworzeniem wizualnym - można czasami się wyłamać z tego systemu i poszczególne elementy stworzyć dynamicznie, ale robienie tego w większości przypadków moim zdaniem totalnie zaburza sens korzystania ze środowiska RAD.

0

Nie odpowiedziałeś na moje pytanie, zatem i ja nie czuję się zobowiązany ;-)

A poza tym - założyłeś sobie coś. Masz w głowie jakiś koncept, jak to robię.
Jakieś wstawki o WinAPI i inne pierdoły, jak używanie OI do ustalenie położenia kontrolki...
Ciekawi mnie co takiego sobie założyłeś?

Zwłaszcza komponety non-visual i ustalanie ich parametrów to zło.
Potem nie wiadomo co jest w kodzie, a co jest wyklikane i siedzie w DFMie.

Ciekawe, że użytkowcy Delphi, uwielbiają klikać i po prostu zapominają, że programista ma przede wszystkim kodować.

PS. Pisałem już o tym i pokazywałem co i jak. Nie pamiętam tylko gdzie to było, ale chyba pamiętam, że była o tym rozmowa z @Mr.YaHooo

PS2. Znajdę czas, to odpiszę szczegółowo. Ale uprzedzam z góry, że to potrwa.

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.

1

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

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

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.

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.

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.

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.

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.

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

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

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.

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