Odpowiednik onChange dla zmiennych

0

Cześć,

jako że nie ma już działu Newbie to muszę zapytać tutaj.

Jak zrealizować monitorowanie zmiennej na zasadzie onChange dla TEdit?

0

zastosować właściwość zamiast zmiennej. Rozwiń temat bo pewnie jest to problem XY

1
robertz68 napisał(a):

Jak zrealizować monitorowanie zmiennej na zasadzie onChange dla TEdit?

Nie ma takiej możliwości. Potrzebny jest setter, który oprócz aktualizacji wartości zmiennej wywoła zdarzenie (o ile zmienna zdarzenia nie zawiera pustej referencji). Co knujesz? ;)

0

Można też monitorować wartość danej komórki pamięci w osobnym wątku, ale będzie to nadal troszkę asynchroniczne. Niemniej tak się robi jak chce się ingerować w program co jest już zbudowany i coś tam się chce haczyć. Powiedz lepiej jaki masz realny problem do rozwiązania.

0

no dobra,

buduję program do prowadzenia sprzedaży w restauracji. Będzie to zastępcze narzędzie dla Gastro POS-a (tego klasycznego). Dlaczego - bo oryginał niestety nie dał rady z nowymi matrycami VAT ale to już inna sprawa. Aplikacja jest już mocno zaawansowana i doszedłem do momentu wyboru formy płatności. Żeby długo nie tłumaczyć tak to wygląda:
screenshot-20190811152929.png
Jak widać, mamy wartość rachunku (w pln i euro), mamy miejsce do wpisania różnych form płatności no i mamy dynamicznie obliczane ile jeszcze zostało do dopłacenia lub ile należy wydać reszty.

Jest trochę tych możliwości. Dodatkowo w kontrolkach karty i talonu nie można przekroczyć kwoty jaka pozostała do dopłacenia. Oczywiście mogę się opierać na zdarzeniach onChange kontrolek edit (tutaj jest to validateedit z pakietu jedi) ale pomyślałem sobie że i tak wszytko "leci" do zmiennych więc fajnie by było aby to one wywoływały jakieś zdarzenie po tym jak zmieni się ich wartość.

Hej, a może macie jakąś sugestię co do tego? Na zdarzeniach kontrolek edit już kiedyś takie coś zrobiłem (lata temu) i działa to do dzisiaj ale wydaje mi się to mało eleganckie.

3

powinieneś mieć jakąś klasę, która odpowiada za "trzymanie" i przeliczanie wprowadzanych/wyświetlanych danych a nie "gołe" zmienne. Tam (w sensie w tej klasie) zamiast zmiennych publicznych wstawił byś właściwości i robiły by one dokładnie to co chcesz aby robiły

0
abrakadaber napisał(a):

powinieneś mieć jakąś klasę, która odpowiada za "trzymanie" i przeliczanie wprowadzanych/wyświetlanych danych a nie "gołe" zmienne. Tam (w sensie w tej klasie) zamiast zmiennych publicznych wstawił byś właściwości i robiły by one dokładnie to co chcesz aby robiły

chyba właśnie tak do tego podejdę, już teraz trzymałem zmienne w zależności od zastosowania w rekordach ale klasa jednak ma większe możliwości. Dzięki za sugestie.

0

@robertz68: eee, no nie mów, że logikę biznesową masz rozsianą po globalnych zmiennych… :/

już teraz trzymałem zmienne w zależności od zastosowania w rekordach ale klasa jednak ma większe możliwości.

Nie rozumiem dlaczego ciągle deweloperzy upierają się przy rekordach, tym bardziej tych klasycznych, jak z TP. Masz przecież możliwość dodania zarówno metod jak i właściwości do zwykłych rekordów. Nie chcesz rekordów, ale i równocześnie chcesz uniknąć dynamicznego tworzenia/zwalniania pamięci? Użyj starych obiektów – funkcjonalność podobna do klas, ale są to typy zarządzane, alokowane na stosie, więc możesz ich używać jak zwykłych rekordów (bonusem jest wsparcie dziedziczenia).

Najlepiej to opakowuj wszystko w małe, czytelne klasy – unikniesz bólu głowy.

0
furious programming napisał(a):

@robertz68: eee, no nie mów, że logikę biznesową masz rozsianą po globalnych zmiennych… :/

aż tak źle to nie jest :). W zasadzie staram się unikać zmiennych globalnych w moich programach (no chyba że to naprawdę potrzebne / pomocne).
Ale rzeczywiście muszę się chyba troszkę przyłożyć do tego programu bo będzie mi ciężko z rozwijaniem tego projektu.

Największy problem na jaki trafiłem to niesamowita wręcz presja czasu. 5 sierpnia okazało się że klient nie da rady sprzedawać na nowej matrycy vat i tego dnia ruszyłem z projektem. Dzisiaj po 6 dniach mam 60 procent wykonanych prac. Za 5-7 dni myślę że będę wdrażał testowo projekt. Prywatnie uważam to za mój osobisty rekord. Oczywiście taka presja spowodowała zapewne wygenerowanie dużej ilości błędów. Wiem także że trochę parametrów które powinny być konfigurowalne na chwilę obecną wpisałem do kodu jako stałe czy też zmienne. To raczej poprawię w nowszej wersji.
Postaram się także na rozdzielenie warstwy wizualnej od logicznej ale to troszkę później.
W każdym razie na pewno do tych prostych obliczeń związanych z formami płatności zbuduję jakąś klasę. Trudno, trochę teraz straconego czasu na pewno zwróci mi się w przyszłości.

0
robertz68 napisał(a):

Największy problem na jaki trafiłem to niesamowita wręcz presja czasu.

Ehh… coś o tym wiem… :/

[…] 5 sierpnia okazało się że klient nie da rady sprzedawać na nowej matrycy vat i tego dnia ruszyłem z projektem. Dzisiaj po 6 dniach mam 60 procent wykonanych prac. Za 5-7 dni myślę że będę wdrażał testowo projekt.

Czyli przygotuj się na 14-20 dni, jak to zwykle bywa.

Oczywiście taka presja spowodowała zapewne wygenerowanie dużej ilości błędów. Wiem także że trochę parametrów które powinny być konfigurowalne na chwilę obecną wpisałem do kodu jako stałe czy też zmienne.

Tym się nie przejmuj. Jeśli nie masz czasu podłączać na tworzenie pewnych elementów konfigurowalnymi to po prostu ich dla pierwszej wersji takimi nie rób. Jak nie masz czasu na wydzielanie powtarzających się wartości do stałych to wpisuj literały. Klienta nie obchodzi co jest w kodzie – ma on działać prawidłowo.

Jeśli poradzisz sobie z ogarnięciem takiego kodu i nie będziesz przez niego tracił czasu podczas prac nad pierwszą wersją to można trochę ponaginać zasady. Ale pamiętaj, aby pozbyć się szitu z kodu jak najszybciej, jak tylko będzie okazja, czas i chęci.

Postaram się także na rozdzielenie warstwy wizualnej od logicznej ale to troszkę później.

Sugeruję jak najszybciej się tym zająć, bo im większy program, tym jest to trudniejsze do wykonania. A im będzie to trudniejsze, tym większa szansa na nowe błędy i na tracenie większej ilości czasu. Szkoda że od razu o tym nie pomyślałeś – w końcu każdy program okienkowy ma UI i logikę, więc to powinno być pierwszą myślą jeszcze przed napisaniem początkowych linijek kodu.. :]

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