Mechanizm kotwic/anchors

Odpowiedz Nowy wątek
2019-11-06 09:52
1

Parę dni temu podczas rozmowy z @furious programming poruszyliśmy temat kotwic/anchors. Dla osób niewtajemniczonych - jest to mechanizm, który pozwala na dynamiczne (i oczywiście - całkowicie automatyczne) skalowanie i przesuwanie elementów okna. Możemy wskazać, względem czego mają się skalować (względem okna, ale równie dobrze innych elementów), jakie mają posiadać marginesy, w jaki sposób się wyrównywać, można robić "łańcuszki" zależności itp.

Kiedyś, kiedy jeszcze siedziałem na Delphi, miałem z tym styczność, ale jakoś ten mechanizm nie przemawiał do mnie, przez co mi zostało przekonanie, żeby z tego nie korzystać, w związku z czym w Lazarusie nie ruszałem tej opcji. Ostatnio (dzięki FP) rzuciłem na to okiem i się mocno zdziwiłem.

Na poniższych obrazkach widać, jak anchors wygląda w Delphi (pierwszy screen) oraz w Lazarusie (drugi obrazek). Różnica jest ogromna. Właściwie to w Delphi (praktycznie najnowszej wersji - 10.2) można jedynie ustawić TRUE/FALSE dla poszczególnych kotwic (lewo, prawo itp.), natomiast Lazarus oferuje o wieeeele więcej. I pytanie - czy ja nie wiem, jak się dostać do analogicznej funkcjonalności w Delphi, czy może pod względem mechanizmu kotwiczenia komponentów, Lazarus masakruje swojego większego, starszego i bardziej dojrzałego kuzyna? ;)

Delphi:
title
.
Lazarus:
screenshot-20191106094743.png


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 2x, ostatnio: cerrato, 2019-11-06 15:57

Pozostało 580 znaków

2019-11-06 15:18
0
cerrato napisał(a):

nie odpowiada za to Anchor bezpośrednio a pośrednio

Szczerze mówiąc, to mam bardzo głęboko gdzieś, czy robi to bezpośrednio, przez LCL albo wysyłając SMS do samego Jezusa.

Pisząc takie coś, wnoszę że nie rozumiesz jaka jest różnica pomiędzy skalowaniem a zmianą rozmiaru w kontekście kontrolki wizualnej.
A dalej jest tylko gorzej...

Dla mnie istotne jest, że ten mechanizm działa. Określam (przy użyciu anchor) jakiego efektu oczekuję, a następnie go dostaję. I całkowicie mnie wali, czy to się dzieje w oparciu o jakieś mechanizmy LCL/VCL, wywołania API systemu, czy może formatka uruchamia sobie model sztucznej inteligencji i sama się domyśla, jak powinna się wyświetlać ;) Ważne, że działa tak, jak oczekuję.

OK, ale to nie jest podejście programisty tylko script-kiddie.
Oni sobie zrobią kopiuj-klej i całkowicie ich wali po co - ważne, że działa. ;-)

A poza tym, ja w ogóle nie wiem o czym piszesz i dlaczego.
Zadałeś pytanie nie dostałeś odpowiedzi.
Odpowiem Ci, jak mi wyjaśnisz jak to działa w Lazarusie.
A więc?

edytowany 1x, ostatnio: cerrato, 2019-11-06 15:32

Pozostało 580 znaków

2019-11-06 15:31
0

nie rozumiesz jaka jest różnica pomiędzy skalowaniem a zmianą rozmiaru

Wybacz, ale nie chcę się bawić w czepianie się słówek. Dobrze wiesz, o co chodziło, gdy pisałem o skalowaniu. Ale jakbyś naprawdę nie zrozumiał (aczkolwiek podejrzewam, że wiesz i tylko chcesz się doczepić) to wyjaśnię - chodziło mi o efekt, w którym podczas zmiany rozmiaru okna, kontrolki będą się zachowywać w określony sposób - stosownie przesuną, albo rozciągną razem z oknem, ale zachowując jakieś relacje między sobą. A czy nazwiemy to skalowaniem, zmienianiem rozmiaru czy jeszcze inaczej - z mojego punktu widzenia nie ma to znaczenia. Ważne, że uzyskuję efekt, na którym mi zależy, a ponadto jestem pewien, że pozostałe osoby czytające mój post zrozumiały, o czym piszę. Jak chcesz uprawiać tego typu kazuistykę, to sorry, ale beze mnie.

OK, ale to nie jest podejście programisty tylko script-kiddie

Wycieczki osobiste są dość słabym argumentem i zazwyczaj świadczą o braku innych, bardziej merytorycznych

zrobią kopiuj-klej i całkowicie ich wali po co - ważne, że działa.

No to trochę (a właściwie bardzo) inna sytuacja. To, o czym piszesz to jest znalezienie w necie jakiejś funkcji czy biblioteki, bezmyślne wsadzenie jej do projektu i cieszenie się, że wykonuje jakieś działanie, mimo że nie taki ktoś ani nie wie, jak to działa, ani jakie są skutki uboczne. W przypadku anchors jest inaczej. Po pierwsze - jest to element standardowej biblioteki tworzącej trzon Lazarusa, czyli LCL, więc zarzucanie komuś, że korzysta z tego jest śmieszne. A po drugie, idąc tym tokiem rozumowania, to każdy kto zrobi coś w stylu Form1.Caption:= 'apka Wloochacza'; i nie będzie miał pełnej świadomości, co się dzieje w tle, z jakich wywołań systemowych to korzysta, także (zgodnie z Twoją logiką) będzie dzieciakiem :P

Odpowiem Ci, jak mi wyjaśnisz jak to działa w Lazarusie.

Czyli rozumiem, że nie masz pojęcia jak to tam działa, a mimo wszystko się wypowiadasz. Brawo :P Typowe podejście w stylu "nie znam się, więc się wypowiem".


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-11-06 16:09
0
cerrato napisał(a):

nie rozumiesz jaka jest różnica pomiędzy skalowaniem a zmianą rozmiaru

Wybacz, ale nie chcę się bawić w czepianie się słówek.

To się nie czepiaj.

Dobrze wiesz, o co chodziło, gdy pisałem o skalowaniu.

Dlatego napisałem, że tylko dla porządku.
Rozumiem, że nie wolno ci zwrócić uwagi w przypadki, kiedy ciut nie halo jakiś tam twój opis czegoś wygląda?
Powiem ci twoimi słowy - mnie to wali, czy się tam obrazisz czy nie.

Ale jakbyś naprawdę nie zrozumiał (aczkolwiek podejrzewam, że wiesz i tylko chcesz się doczepić) to wyjaśnię - chodziło mi o efekt, w którym podczas zmiany rozmiaru okna, kontrolki będą się zachowywać w określony sposób - stosownie przesuną, albo rozciągną razem z oknem, ale zachowując jakieś relacje między sobą.

Tak, wiem.
A dalej nie wiem czego się nie da zrobić w Delphi, a da się zrobić w Lazarusie, bo niczego nie wyjaśniłeś.

A czy nazwiemy to skalowaniem, zmienianiem rozmiaru czy jeszcze inaczej - z mojego punktu widzenia nie ma to znaczenia. Ważne, że uzyskuję efekt, na którym mi zależy, a ponadto jestem pewien, że pozostałe osoby czytające mój post zrozumiały, o czym piszę. Jak chcesz uprawiać tego typu kazuistykę, to sorry, ale beze mnie.

Ale z mojego punktu widzenia ma to znaczenia.
I napisałem delikatnie, że to nie to samo.

Poza tym, kontekst użycia terminu "kazuistyka" w tym wątku jest ciekawy :)
Ale to dopiero flame będzie, a więc może innym razem :)

OK, ale to nie jest podejście programisty tylko script-kiddie

Wycieczki osobiste są dość słabym argumentem i zazwyczaj świadczą o braku innych, bardziej merytorycznych

Po pierwsze, nie ma tu żadnej wycieczki osobistej.
Pisałem tylko o podejściu do problemu a nie bezpośrednio do ciebie, co przecież widać.
Zwracam jeszcze nieśmiało uwagę, że to forum posiada nazwę 4programmers a nie 4-wali-mnie-jak-to-działa.
Bo jednak dobrze wiedzieć jak to działa; taki truizm.

zrobią kopiuj-klej i całkowicie ich wali po co - ważne, że działa.

No to trochę (a właściwie bardzo) inna sytuacja. To, o czym piszesz to jest znalezienie w necie jakiejś funkcji czy biblioteki, bezmyślne wsadzenie jej do projektu i cieszenie się, że wykonuje jakieś działanie, mimo że nie taki ktoś ani nie wie, jak to działa, ani jakie są skutki uboczne.

Byłbym i się zgodził, gdybyś nie napisał kolejnych dwóch zdań o jezusach i waleniu cię jak to działa.
A więc nie dziw się, że zwracam na to uwagę.

W przypadku anchors jest inaczej. Po pierwsze - jest to element standardowej biblioteki tworzącej trzon Lazarusa, czyli LCL, więc zarzucanie komuś, że korzysta z tego jest śmieszne.

Nie rozumiem, coś komuś zarzucałem?

A po drugie, idąc tym tokiem rozumowania, to każdy kto zrobi coś w stylu Form1.Caption:= 'apka Wloochacza'; i nie będzie miał pełnej świadomości, co się dzieje w tle, z jakich wywołań systemowych to korzysta, także (zgodnie z Twoją logiką) będzie dzieciakiem :P

To okrutnie naciągnę jest i doskonale o tym wiesz.
Ale spoko. nie obrusza mnie to.

Odpowiem Ci, jak mi wyjaśnisz jak to działa w Lazarusie.

Czyli rozumiem, że nie masz pojęcia jak to tam działa, a mimo wszystko się wypowiadasz.

Oczywiście, że nie wiem co oznaczają te ikony na dialogu, który pokazałeś, tak więc nie wiem jak dokładnie to działa w Lazarusie.
I tak, pisałem o tym wyraźnie na początku.
A więc zależy ci na odpowiedzi na swoje pytania, to wyjaśnij proszę jak to jest w Lazarusie.

Brawo :P Typowe podejście w stylu "nie znam się, więc się wypowiem".

Hola, hola!

Nie wypowiadałem się w temacie, na którym się nie znam.
Nie napisałem ani słowa o tym, że w Lazarusie jest lepiej/gorzej lub w Delphi jest lepiej/gorzej ze (niech będzie) "skalowaniem".
Pisałem o tym, jak to jest w Delphi i tyle.

Widzisz, gdybym wszedł w twój tok argumentów to napisałbym, że to TY NIE WIESZ, a się wypowiadasz pisząc, że "Lazarus masakruje Delphi".
Ale nie napiszę tak, bo to bzdura. Zadałeś pytanie, a nie postawiłeś stwierdzenia.

Ja ciągle zadaję pytania o Lazarusa, a nie "się wypowiadam" jak mi tu próbujesz udowodnić.

Pozostało 580 znaków

2019-11-06 16:48
0

nie wiem co oznaczają te ikony na dialogu, który pokazałeś, tak więc nie wiem jak dokładnie to działa w Lazarusie. I tak, pisałem o tym wyraźnie na początku

No ale tak naprawdę to chyba wszystko wyjaśnia i temat zamyka. Zadałem pytanie osobom, które znają te mechanizmy i mogą się wypowiedzieć, je porównac itp.. Ty przyznajesz się, że nie znasz (przynajmniej po stronie Lazarusa), więc obawiam się, że nie jesteś odpowiednią osobą. I nie piszę tego w formie ataku, tylko stwierdzenia faktu.

się wypowiadasz pisząc, że "Lazarus masakruje Delphi".

Zauważ, że nie stwierdziłem, a jedynie się zdziwiłem tym, co zauważyłem i zadałem związane z tym pytanie. Na wszelki wypadek je tutaj zacytuję - "czy może pod względem mechanizmu kotwiczenia komponentów, Lazarus masakruje". Jest to pytanie i zarazem prośba o informację, czy da się równie prosto, co w przypadku Lazarusa, uzyskać taki efekt w Delphi. Tym bardziej jest to dla mnie zaskakujące, że na ogół ludzie uznają, że Lazarus jestmniejszym/mniej dopieszczonym/słabszym klonem Delphi, a tutaj mam wrażenie, że w tym aspekcie bije Delphi na głowię. I chciałem to wyjaśnić, czy tak rzeczywiście jest, czy po prostu o czymś nie wiem/nie umiem znaleźć analogicznego mechanizmu w Delphi.

Uprzedzając to, co pewnie zaraz napiszesz - nie, nie będę wyjaśniać, co "taki efekt" oznacza. Osoby, które miały styczność z Lazarusem, powinny wiedzieć i to do nich skierowane było to pytanie.


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-11-06 17:43
2

No to teraz moja kolej – na zaawansowanym kotwiczeniu ”zjadłem zęby”, więc się z chęcią wypowiem. :)

Po pierwsze, Anchor Editor jest jednym z najlepszych narzędzi dostępnych w IDE. Powiem tak – dobrze wyklikany formularz powinien mieć ustawione zaawansowane kotwiczenie. A nawet powiem inaczej – ustawienie zaawansowanego kotwiczenia to obowiązek i nie wyobrażam sobie pracy formularzem, który ich nie wykorzystuje.

Dynamiczne generowanie formularzy to inna bajka, o której tutaj nie będę pisał, bo takiej techniki z braku powodów nie wykorzystuję. Mimo wszystko AnchorSide można ustawiać z poziomu kodu, więc i w takim przypadku znajdzie zastosowanie.


_13th_Dragon napisał(a):

Jak tylko do formatki zrobionej przez takie zaawansowane anchory trzeba coś dołożyć to zaczyna się masakra.

Masakra to się zaczyna, jak się ktoś zabiera za robotę, o której nie ma się pojęcia.

_13th_Dragon napisał(a):

[…] bla bla

  • Nie trzeba włożyć kontrolki "w środek" łańcucha

Włożenie kontrolki w środek łańcucha ogranicza się do trzech kliknięć, a raczej do wybrania trzech wartości – wyłączenie górnej kotwicy dla kontrolki zastępowanej, wybranie ”rodzica” dla kontrolki wstawianej, wybranie nowego rodzica dla kontrolki zastępowanej. No cholera, 15 sekund mi to zajmuje – jestem bogiem kotwic, czy to narzędzie naprawdę jest tak banalnie przewidywalne?


skrzat napisał(a):

[…] Np. pojawia się błąd, że niby jest cykliczne odwołanie, którego na 100% w rzeczywistości nie ma.

Z początku, gdy stawiałem pierwsze kroki z tym narzędziem to miewałem problemy z zapętleniami i nie za bardzo ogarniałem dlaczego tak się dzieje. Ale ostatecznie znajdowałem problem i IDE miało rację – źle ustawiłem relacje. I do dziś tego typu błędy mnie nękają, ale też z mojej winy – głównie przez kopiowanie i wklejanie kontrolek w obrębie zakładek jednego TPageControl. No bo szybciej jest skopiować, wkleić i zmienić dwie wartości we wklejonej kontrolce (która jest już skonfigurowana), niż wyklikiwać ją zupełnie od nowa.

skrzat napisał(a):

To zaawansowane kotwiczenie nie jest oczywiście doskonałe, bo np. nie działa poprawnie dla TLabeledEdit, gdy Label ustawimy z lewej strony Edit. Ustawienie Left Anchor jest wtedy dla pola Edit, a nie Label.

Z punktu widzenia LCL jest to zachowanie prawidłowe, dlatego że wyrównanie ustawiasz polu edycyjnemu, a nie etykiecie. A ta etykieta co prawda jest zarządzana przez pole edycyjne, ale jest jedynie odrębną kontrolką którą pole edycyjne zarządza i którą odpowiednio dosuwa do siebie podczas zmiany rozmiaru/położenia edita.

Niestety ten problem nie ma oczywistego rozwiązania, bo takie subkomponenty nie mogą być konfigurowane z osobna. Ten przypadek akurat da się rozwiązać – zamiast TLabeledEdit można skorzystać z TLabel + TEdit i wtedy ustawić kotwiczenie – wyjdzie na to samo. W innych podobnych przypadkach może być gorzej. ;)


wloochacz napisał(a):

Ale ja mam inne pytanie; czego nie da się zrobić w Delphi, a da się za pomocą masakrującego mechanizmu w Lazarusie?

Bardzo proszę – nie da się dostosowywać układu, rozmiarów komponentów i przyjętych odstępów między komponentami bez modyfikowania kodu źródłowego. Czyli nie da się zrobić poprawnie zachowującego się formularza bez pisania kodu OnResize układającego jego zawartość. :)

W designerze Lazarusa mogę ustawić kotwice bazowe (czyli zwykły Anchors) aby kontrolki były przyciągane do krawędzi komponentu rodzica lub okna (takie jest ich zadanie). Oczywiście jeśli potrzeba to i ustawieniem Constraints nie pogardzę. Następnie mogę sobie ustawić zaawansowane kotwiczenie (czyli AnchorSide), aby zdefiniować powiązania pomiędzy komponentami nie będącymi rodzicami. Na koniec ”masakruję” publikę ustawiając marginesy wybranym komponentom, aby formularz końcowo dopasował swój rozmiar do zawartości.

W ten sposób zrobiłem formularz, który nie dość że posiada samoorganizującą się zawartość, to jeszcze samo okno dopasowuje swój rozmiar do tej samoorganizującej się zawartości przy włączonym AutoSize. Benefity? W dupie mam to jaki system ma użytkownik, jakie ma ustawienia DPI/skalowania, jakiego fontu system używa w interfejsie i masę innych rzeczy, bo formularz zawsze będzie posiadał taki układ zawartości, jaki ja widzę w designerze.

I to wszystko bez napisania choćby jednej linijki kodu i oczywiście bez konieczności kompilowania i uruchomiania projektu.

I właśnie do tego to służy, jest bardzo proste, robi robotę i nawet wygodne.

Najwyraźniej mamy inne pojęcie wygody. Bo dla mnie wygodne jest kliknięcie dwa razy i możliwość natychmiastowego widzenia na ekranie rezultatów, niż dłubanie w kodzie, kompilowanie i uruchamianie projektu aby mieć możliwość przetestowania wprowadzonych zmian. Zresztą przecież pro-koderom w poważnych firmach nie wolno kompilować i uruchamiać opracowywanych projektów, więc dla takich majstrów powinno być przydatne. :D

Jeśli np. zmienię treść etykiety i zamiast dwóch linijek tekstu ustawię dziesięć to kontrolki zakotwiczone natychmiast się dostosują, zachowując pierwotne odstępy. Jeśli zmienię rozmiary/położenie któregoś komponentu głównego to reszta też się dopasuje – od razu widzę czy zmiana jest dobra czy jednak był to zły pomysł, a więc oszczędzam czas, a tym samym pieniądze.

OnResize to relikt przeszłości – wachlarz jego zastosowań stał się wąziutki z powodu AnchorSide. To zdarzenie nadaje się do… w sumie do niewielu rzeczy. Sam używam póki co wyłącznie do aktualizowania danych dotyczących rozmieszczenia i rozmiarów okien (gdy layout użytkownika jest zapamiętywany).

Choć nawet w takim przypadku OnResize posysa po całości, bo do tego celu powinienem obsłużyć komunikaty WM_ENTERSIZEMOVE i WM_EXITSIZEMOVE. Ale do tych komunikatów nie ma zdarzeń, a nawet pętla komunikatów okna w ogóle ich nie obsługuje, więc trzeba by dla każdego okna rejestrować własną procedurę obsługi komunikatów (czyli w ten sposób), co jest uciążliwe.

wloochacz napisał(a):

Ale to i tak jest furda w stosunku do np. TdxLayoutControl z DevExpress.

Zapewne tak (nie wiem, nie używałem), ale alternatywa w postaci płatnej biblioteki to jednak słaby argument.

wloochacz napisał(a):

A poza tym, zachęcam, włącz skalowanie okna, a najprawdopodobniej bardzo szybko je wyłączysz.

Kiedyś się skuszę i dam znać jak szybko szlag mnie trafił. :]


Podsumowując, zaawansowane kotwiczenie to wspaniała rzecz, ułatwiająca, przyspieszająca i umilająca pracę z klikaniem interfejsu. Każdy kto jakimś cudem tworzy apki w Lazarusie powinien koniecznie zapoznać się z tym narzędziem, opanować go i używać na co dzień – z głową, tak samo jak wszystkiego innego. Oczywiście to narzędzie nie jestem lekiem na wszystko – ma swoje minusy i ograniczenia – ale i tak plusów posiada znacznie więcej niż minusów, więc warto się nim zainteresować.

Zresztą co się będę produkował – czerpię z tego narzędzia same korzyści i olewam kto co na ten temat myśli. ;)


edytowany 6x, ostatnio: furious programming, 2019-11-07 16:49

Pozostało 580 znaków

2019-11-06 17:45
0
cerrato napisał(a):

nie wiem co oznaczają te ikony na dialogu, który pokazałeś, tak więc nie wiem jak dokładnie to działa w Lazarusie. I tak, pisałem o tym wyraźnie na początku

No ale tak naprawdę to chyba wszystko wyjaśnia i temat zamyka.

No, nie.

Zadałem pytanie osobom, które znają te mechanizmy i mogą się wypowiedzieć, je porównac itp.. Ty przyznajesz się, że nie znasz (przynajmniej po stronie Lazarusa), więc obawiam się, że nie jesteś odpowiednią osobą. I nie piszę tego w formie ataku, tylko stwierdzenia faktu.

Być może nie jestem.
A być może jestem, bo po tych wykrętach z twojej strony wygląda to jak połączenie Align z Anchor w Delphi.

się wypowiadasz pisząc, że "Lazarus masakruje Delphi".

Zauważ, że nie stwierdziłem, a jedynie się zdziwiłem tym, co zauważyłem i zadałem związane z tym pytanie.

Własnie!
Gdybyś przeczytał, co napisałem, nie napisałbyś tego co napisałeś dalej...

Na wszelki wypadek je tutaj zacytuję - "czy może pod względem mechanizmu kotwiczenia komponentów, Lazarus masakruje".

Właśnie tego powyżej byś nie napisał.

Jest to pytanie i zarazem prośba o informację, czy da się równie prosto, co w przypadku Lazarusa, uzyskać taki efekt w Delphi.

Taki, czyli jaki efekt?
Masakra jakaś, po raz trzeci o to pytam...

Tym bardziej jest to dla mnie zaskakujące, że na ogół ludzie uznają, że Lazarus jestmniejszym/mniej dopieszczonym/słabszym klonem Delphi, a tutaj mam wrażenie, że w tym aspekcie bije Delphi na głowię.

Słowa, słowa, słowa...
I dalej nie wiadomo o co chodzi.
A chodzi dokładnie (po sprawdzeniu) o to:
https://wiki.freepascal.org/Anchor_Sides

I chciałem to wyjaśnić, czy tak rzeczywiście jest, czy po prostu o czymś nie wiem/nie umiem znaleźć analogicznego mechanizmu w Delphi.
Uprzedzając to, co pewnie zaraz napiszesz - nie, nie będę wyjaśniać, co "taki efekt" oznacza. Osoby, które miały styczność z Lazarusem, powinny wiedzieć i to do nich skierowane było to pytanie.

OK, nie wyjaśniaj.
Sam sobie sprawdzę, albo lepiej poczekamy na kogoś kto się zna, bo co ja tam mogę wiedzieć.

... minutę mi zajęło to całe sprawdzenie ;-)
I tak, Delphi nie obsługuje by-design takich zależności pomiędzy kontrolkami, które da się wyklikać w IDE lub ustawić w kodzie w przypadku Lazarusa.

Ale tak, da się osiągnąć podobny efekt, tylko na około.
Ale co ja tam wiem, nie znam się, zarobiony jestem.

Pozostało 580 znaków

2019-11-06 17:55
0
wloochacz napisał(a):

A być może jestem, bo po tych wykrętach z twojej strony wygląda to jak połączenie Align z Anchor w Delphi.

Nie do Align – to po prostu zwykły Anchor wyposażony w możliwość przyciągania kontrolki do komponentów nie będących jego rodzicami. Sam Anchor załatwia sprawę połowicznie, a AnchorSide jest dopełnieniem całości.


Przy czym Align nie używam, bo nie daje mi niczego, czego nie mógłbym ustawić kotwicami.


edytowany 1x, ostatnio: furious programming, 2019-11-06 17:58

Pozostało 580 znaków

2019-11-06 18:15
0
furious programming napisał(a):

No to teraz moja kolej – na zaawansowanym kotwiczeniu ”zjadłem zęby”, więc się z chęcią wypowiem. :)

Po pierwsze, Anchor Editor jest jednym z najlepszych narzędzi dostępnych w IDE. Powiem tak – dobrze wyklikany formularz powinien mieć ustawione zaawansowane kotwiczenie. A nawet powiem inaczej – ustawienie zaawansowanego kotwiczenia to obowiązek i nie wyobrażam sobie pracy formularzem, który ich nie wykorzystuje.

Dynamiczne generowanie formularzy to inna bajka,

W przypadku Lazarus, to taka sama bajka.
A przynajmniej w dokumentacji tak piszą i w przykładach kodu podają...

o której tutaj nie będę pisał, bo takiej techniki z braku powodów nie wykorzystuję. Mimo wszystko AnchorSide można ustawiać z poziomu kodu, więc i w takim przypadku znajdzie zastosowanie.

Właśnie.


_13th_Dragon napisał(a):

Jak tylko do formatki zrobionej przez takie zaawansowane anchory trzeba coś dołożyć to zaczyna się masakra.

Masakra to się zaczyna, jak się zabiera ra robotę, o której nie ma się pojęcia.

Ale uwaga, bo jeśli trzeba rozumieć, to nie można podchodzić do tego w sposób "wali mnie jak to działa" ;-)

_13th_Dragon napisał(a):

[…] bla bla

  • Nie trzeba włożyć kontrolki "w środek" łańcucha

Włożenie kontrolki w środek łańcucha ogranicza się do trzech kliknięć, a raczej do wybrania trzech wartości – wyłączenie górnej kotwicy dla kontrolki zastępowanej, wybranie ”rodzica” dla kontrolki wstawianej, wybranie nowego rodzica dla kontrolki zastępowanej. No cholera, 15 sekund mi to zajmuje – jestem bogiem kotwic, czy to narzędzie naprawdę jest tak banalnie przewidywalne?

Może Ci podpowiem; rozumiesz koncept i stosujesz go zgodnie z konwencją.
Dlatego nie masz z tym absolutnie żadnych problemów.
I przyznam, że mechanizm jest naprawdę ciekawy, a w Delphi nie istnieje.


skrzat napisał(a):

[…] Np. pojawia się błąd, że niby jest cykliczne odwołanie, którego na 100% w rzeczywistości nie ma.

Z początku, gdy stawiałem pierwsze kroki z tym narzędziem to miewałem problemy z zapętleniami i nie za bardzo ogarniałem dlaczego tak się dzieje. Ale ostatecznie znajdowałem problem i IDE miało rację – źle ustawiłem relacje. I do dziś tego typu błędy mnie nękają, ale też z mojej winy – głównie przez kopiowanie i wklejanie kontrolek w obrębie zakładek jednego TPageControl. No bo szybciej jest skopiować, wkleić i zmienić dwie wartości we wklejonej kontrolce (która jest już skonfigurowana), niż wyklikiwać ją zupełnie od nowa.

skrzat napisał(a):

To zaawansowane kotwiczenie nie jest oczywiście doskonałe, bo np. nie działa poprawnie dla TLabeledEdit, gdy Label ustawimy z lewej strony Edit. Ustawienie Left Anchor jest wtedy dla pola Edit, a nie Label.

Z punktu widzenia LCL jest to zachowanie prawidłowe, dlatego że wyrównanie ustawiasz polu edycyjnemu, a nie etykiecie. A ta etykieta co prawda jest zarządzana przez pole edycyjne, ale jest jedynie odrębną kontrolką którą pole edycyjne zarządza i którą odpowiednio dosuwa do siebie podczas zmiany rozmiaru/położenia edita.

Dodałbym, że to właśnie TLabeledEdit jest na odwal się napisany i stąd takie problemy.
Bo faktycznie kotwice w Lazarus wyglądają na proste, ale potężne.
Fajnie.

Niestety ten problem nie ma oczywistego rozwiązania, bo takie subkomponenty nie mogą być konfigurowane z osobna. Ten przypadek akurat da się rozwiązać – zamiast TLabeledEdit można skorzystać z TLabel + TEdit i wtedy ustawić kotwiczenie – wyjdzie na to samo. W innych podobnych przypadkach może być gorzej. ;)

Można napisać nowy komponent wychodząc z np. TPanel
W nim osadzić Label i Edit oraz powiązać je odpowiednio tymi niezłymi kotwicami.
Dodać kilka property jak Caption, LabelPosition z deelgowaniem do osadzonych kontrolek.
I będzie to wtedy działało dokładnie tak, jak chcemy z pełnym wsparciem automatycznej zmiany układu w oparciu o kotwice.
Do napisanie w godzinę z testami, ale ja się na Lazarusie nie znam...


wloochacz napisał(a):

Ale ja mam inne pytanie; czego nie da się zrobić w Delphi, a da się za pomocą masakrującego mechanizmu w Lazarusie?

Bardzo proszę – nie da się dostosowywać układu, rozmiarów komponentów i przyjętych odstępów między komponentami bez modyfikowania kodu źródłowego. Czyli nie da się zrobić poprawnie zachowującego się formularza bez pisania kodu OnResize układającego jego zawartość. :)

W designerze Lazarusa mogę ustawić kotwice bazowe (czyli zwykły Anchors) aby kontrolki były przyciągane do krawędzi komponentu rodzica lub okna (takie jest ich zadanie). Oczywiście jeśli potrzeba to i ustawieniem Constraints nie pogardzę. Następnie mogę sobie ustawić zaawansowane kotwiczenie (czyli AnchorSide), aby zdefiniować powiązania pomiędzy komponentami nie będącymi rodzicami. Na koniec ”masakruję” publikę ustawiając marginesy wybranym komponentom, aby formularz końcowo dopasował swój rozmiar do zawartości.

W ten sposób zrobiłem formularz, który nie dość że posiada samoorganizującą się zawartość, to jeszcze samo okno dopasowuje swój rozmiar do tej samoorganizującej się zawartości przy włączonym AutoSize. Benefity? W dupie mam to jaki system ma użytkownik, jakie ma ustawienia DPI/skalowania, jakiego fontu system używa w interfejsie i masę innych rzeczy, bo formularz zawsze będzie posiadał taki układ zawartości, jak ja go widzę w designerze.

No, nie zawsze, ale nie bawmy się w drobiazgi.
Natomiast sam mechanizm jest faktycznie pomocny.
Trzeba mu jeszcze dodać reguły a'la bootstrap, co by wiedział kiedy ma się co zawijać i będzie super-fajnie :)

I to wszystko bez napisania choćby jednej linijki kodu i oczywiście bez konieczności kompilowania i uruchomiania projektu.

Tego nie rozumiem; jak chcesz zmienić kotwicę zapisaną w formularzu bez rekomplikacji w runtime?

I właśnie do tego to służy, jest bardzo proste, robi robotę i nawet wygodne.

Najwyraźniej mamy inne pojęcie wygody. Bo dla mnie wygodne jest kliknięcie dwa razy i możliwość natychmiastowego widzenia na ekranie rezultatów, niż dłubanie w kodzie, kompilowanie i uruchamianie projektu aby mieć możliwość przetestowania wprowadzonych zmian. Zresztą przecież pro-koderom w poważnych firmach nie wolno kompilować i uruchamiać opracowywanych projektów, więc dla takich majstrów powinno być przydatne. :D

Nie wiem o czym piszesz za bardzo.
Ale jeśli mowa o tym, że podejście RAD jest najlepsze (a tak napisałeś), no to...
Nie, nie i jeszcze raz nie.
A ilość i moc tych "nie" jest wprost proporcjonalna do wielkości programu.

RAD nadaje się do trzech rzeczy:

  1. Do prototypowania
  2. Do tworzenia niewielkich programów.
  3. Do tworzenia wysoce niestandardowych układów kontrolek w aplikacji.
    To znaczy, kiedy praktycznie każde okno jest zupełnie inne niż poprzednie i trzeba je zaprojektować indywidualnie.

Jeśli np. zmienię treść etykiety i zamiast dwóch linijek tekstu ustawię dziesięć to kontrolki zakotwiczone natychmiast się dostosują, zachowując pierwotne odstępy. Jeśli zmienię rozmiary/położenie któregoś komponentu głównego to reszta też się dopasuje – od razu widzę czy zmiana jest dobra czy jednak był to zły pomysł, a więc oszczędzam czas, a tym samym pieniądze.

Trochę to na wyrost, ale niech będzie.

OnResize to relikt przeszłości – wachlarz jego zastosowań stał się wąziutki z powodu AnchorSide. To zdarzenie nadaje się do… w sumie do niewielu rzeczy. Sam używam póki co wyłącznie do aktualizowania danych dotyczących rozmieszczenia i rozmiarów okien (gdy layout użytkownika jest zapamiętywany).

Choć nawet w takim przypadku OnResize posysa po całości, bo do tego celu powinienem obsłużyć komunikaty WM_ENTERSIZEMOVE i WM_EXITSIZEMOVE. Ale do tych komunikatów nie ma zdarzeń, a nawet pętla komunikatów okna w ogóle ich nie obsługuje, więc trzeba by dla każdego okna rejestrować własną procedurę obsługi komunikatów (w ten sposób], co jest uciążliwe.

wloochacz napisał(a):

Ale to i tak jest furda w stosunku do np. TdxLayoutControl z DevExpress.

Zapewne tak (nie wiem, nie używałem), ale alternatywa w postaci płatnej biblioteki to jednak słaby argument.

To żaden argument, a przykład tylko.
A tam jest znacznie, znacznie więcej smaczków.

wloochacz napisał(a):

A poza tym, zachęcam, włącz skalowanie okna, a najprawdopodobniej bardzo szybko je wyłączysz.

Kiedyś się skuszę i dam znać jak szybko szlag mnie trafił. :]

Skuś się, ale może i tu Lazarus jest po prostu lepszy.
Poza tym, to Delphiowe HighDPIAwerness może coś tam pomóc..., ale dalej jest z tym generalnie kupa z VCL.
Porównać to można do skalowania grafiki rastrowej vs wektorowej.


Podsumowując, zaawansowane kotwiczenie to wspaniała rzecz, ułatwiająca, przyspieszająca i umilająca pracę z klikaniem interfejsu. Każdy kto jakimś cudem tworzy apki w Lazarusie powinien koniecznie zapoznać się z tym narzędziem, opanować go i używać na co dzień z głową (tak samo jak wszystkiego innego). Oczywiście to narzędzie nie jestem lekiem na wszystko – ma swoje minusy i ograniczenia – ale i tak plusów posiada znacznie więcej niż minusów, więc warto się nim zainteresować.

Zresztą co się będę produkował – czerpię z tego narzędzia same korzyści i olewam kto co na ten temat myśli. ;)

Pozostało 580 znaków

2019-11-06 18:17
0
furious programming napisał(a):
wloochacz napisał(a):

A być może jestem, bo po tych wykrętach z twojej strony wygląda to jak połączenie Align z Anchor w Delphi.

Nie do Align – to po prostu zwykły Anchor wyposażony w możliwość przyciągania kontrolki do komponentów nie będących jego rodzicami. Sam Anchor załatwia sprawę połowicznie, a AnchorSide jest dopełnieniem całości.


Przy czym Align nie używam, bo nie daje mi niczego, czego nie mógłbym ustawić kotwicami.

Bo nie musisz.
W Delphi musiałbyś rzeźbić z Align, kontenerem pomocniczym (np. TPanel) i Anchor.
Dlatego napisałem, że wygląda to jak połączenie Align z Anchor.
Ale po sprawdzeniu; no nie do końca, ponieważ to zdecydowanie mocniejsze narzędzie.

Pozostało 580 znaków

2019-11-06 19:19
0
wloochacz napisał(a):

Ale uwaga, bo jeśli trzeba rozumieć, to nie można podchodzić do tego w sposób "wali mnie jak to działa" ;-)

No niestety – jeśli się nie rozumie jak coś działa, to nie można w pełni wykorzystać funkcjonalności i skończy się jedynie na zażenowaniu. Trzeba wiedzieć co można zrobić z kontrolką ”luźną” a co z tą zakotwiczoną do innej, trzeba wiedzieć co się stanie po podłączeniu danej kotwicy i po jej odłączeniu, no i trzeba też wiedzieć dlaczego i po co ustawienie kotwicy nie od razu modyfikuje fizycznego położenia kontrolki (nawet jeśli ta w designerze zmieniła miejsce).

Natomiast oprócz zagadnień związanych z samym działaniem tego mechanizmu, trzeba też logicznie myśleć podczas tworzenia łańcuszków relacji. Np. mamy słupek przycisków, które mają być przyciągane do pionowego listboksa – wiązać horyzontalnie wszystkie przyciski do listboksa, czy do pierwszego przycisku u góry, a tylko ten jeden do listboksa?

Oczywiście to drugie, bo odłączenie górnego od listboksa umożliwi przesuwanie całego słupka, a pierwszy przypadek zmusi do rekonfigurowania kotwic wszystkich przycisków z osobna i wyjdzie kaszana w designerze. Tego typu przypadków jest mnóstwo i trzeba wyrobić odpowiednią technikę, aby nie utrudnić sobie roboty. Po prostu najpierw pomyśleć, a później ustawiać.

Może Ci podpowiem; rozumiesz koncept i stosujesz go zgodnie z konwencją.
Dlatego nie masz z tym absolutnie żadnych problemów.

Zrozumienie działania tego mechanizmu jest tak samo proste jak zrozumienie działania podstawowego Anchors – włączony przyciąga do ”czegoś”, wyłączony nie przyciąga. Tutaj nie ma cudów, a jedyne co stoi na przeszkodzie to niechęć do poświęcenia godzinki na testy oraz nielogiczne decyzje dotyczące konfiguracji. ;)

Dodałbym, że to właśnie TLabeledEdit jest na odwal się napisany i stąd takie problemy.

Z subkomponentami jest dość skomplikowana sprawa, więc nieprędko doczekamy się sensownych zmian.

Można napisać nowy komponent wychodząc z np. TPanel
W nim osadzić Label i Edit oraz powiązać je odpowiednio tymi niezłymi kotwicami.
Dodać kilka property jak Caption, LabelPosition z deelgowaniem do osadzonych kontrolek.

I to jest logiczne podejście. Tyle że twórcy LCL od lat małpują wszystko z VCL więc zrobili to samo. Szkoda że nie małpują przydatnych rzeczy, takich jak np. metod anonimowych czy dynamicznej deklaracji zmiennych wewnątrz ciała podprogramu – zabiłbym za ten ficzer…

No, nie zawsze, ale nie bawmy się w drobiazgi.

Musiałbym się solidnie zastanowić i wylistować przypadki, w których faktycznie może się pojawić problem. Póki co niestety nie mam żadnego pod ręką.

Trzeba mu jeszcze dodać reguły a'la bootstrap, co by wiedział kiedy ma się co zawijać i będzie super-fajnie :)

Póki co ten mechanizm wbrew pozorom jest ubogi i obsługuje absolutnie podstawowe aspekty, a sam edytor kotwic nie posiada naprawdę przydatnych funkcji – np. czegoś w rodzaju pipety do wybrania komponentu z designera, coby nie tracić czasu na wertowanie comboboksów. No ale to dopiero jego początki i zapowiada się jego rozbudowa.

Tego nie rozumiem; jak chcesz zmienić kotwicę zapisaną w formularzu bez rekomplikacji w runtime?

Tutaj miałem na myśli standardowe klikanie w designerze – modyfikacja AnchorSide jest dostępna w dodatkowym okienku, a dokonane zmiany są od razu widoczne w designerze. Dzięki temu można sobie wszystko poustawiać i rozciągając okno designera sprawdzić jak się zachowa zawartość, bez konieczności kompilowania i uruchamiania programu.

Jeśli nie używa się designera i generuje formularze z poziomu kodu, no to już takiej możliwości naturalnie nie ma.

Nie wiem o czym piszesz za bardzo.

Trochę się nabijam z tych, którym w pracy nie wolno kompilować i uruchamiać opracowywanych projektów. Była o tym jakiś czas temu dyskusja na tym forum – rozbawiła mnie, bo przez takie ”zbrodnie” niektórych kariera wisiała na włosku. :D

Ale jeśli mowa o tym, że podejście RAD jest najlepsze (a tak napisałeś), no to...

Nie twierdzę że jest najlepsze, bo nie używałem wszystkich wystarczająco długo aby mieć porównanie. Po prostu dla zwykłego ”klikacza” robiącego standardowe programy, RAD jest bardzo pomocny.

Z wylistowanymi argumentami się zgadzam, choć rozmiar progamu – punkt 2. – nie jest tutaj istotny, bo to zależy od zawartości tych okien i ich przeznaczenia, o czym napisałeś pod tą listą.

To żaden argument, a przykład tylko.
A tam jest znacznie, znacznie więcej smaczków.

Nie wątpię, w końcu za coś pieniążki biorą. :)


edytowany 1x, ostatnio: furious programming, 2019-11-06 19:21

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