Mechanizm kotwic/anchors

Tak masakruje kuzyna, oraz każdego kodera który tego użyje.
Jak tylko do formatki zrobionej przez takie zaawansowane anchory trzeba coś dołożyć to zaczyna się masakra.

Na razie się zapoznaję z tym narzędziem, ale wydaje mi się, że jeśli z głową się rozplanuje wzajemne relacje między elementami, to dołożenie czegoś nie będzie tragedią. Zresztą jakakolwiek zmiana układu elementów zawsze się wiąże z reorganizacją formatki, nawet jeśli masz np. ich rozmieszczenie ogarnięte w obsłudze onResize. A jak sobie dobrze ustawisz kotwice, to powinno się dać radę w miarę bezstresowo wprowadzić zmiany.

Poza tym, jakbyś mógł (jeśli wiesz), to odpowiedz, czy Delphi posiada taką funkcjonalność (tylko gdzieś ukrytą przede mną), czy to jest wynalazek/patent typowo Lazarusowy.

cerrato napisał(a):

... że jeśli z głową się rozplanuje wzajemne relacje między elementami, to dołożenie czegoś nie będzie tragedią ...

O ile:

• To była twoja głowa (czyli na 100% rozumiesz tok myślenia)
• Rzeczywiście dobrze przemyślałeś te RELACJE
• Dobrze pamiętasz te swoje przemyślenia
• Nie trzeba włożyć kontrolki "w środek" łańcucha

@cerrato: W Delphi chyba nie ma zaawansowanego kotwiczenia.
Używam tego zaawansowanego kotwiczenia w Lazarusie na co dzień i bardzo rzadko pojawia się problem, którego nie da się obejść, jak tylko przez wyłączenie zaawansowanego kotwiczenia dla konkretnych elementów. Np. pojawia się błąd, że niby jest cykliczne odwołanie, którego na 100% w rzeczywistości nie ma.

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

No właśnie taka akcja będzie stosunkowo najprostsza ;)
Jeśli masz łańcuszek A -> B -> C -> D i chcesz wsadzić między B a C nowy element, to najpierw zwiększasz odstęp C od B, potem umieszczasz tam nowy element pozycjonowany względem B, a na końcu poprawiasz relację C, które odczepiasz od B i dajesz przyklejone do nowego elementu.

Ale jako powiedziałem - musi to wcześnie być zrobione z głową, rzeczy podopinane do innych elementów w sposób sensowny. Bo jeśli np. wszystkie elementy poniżej B będą pozycjonowane względem B, to wsadzenie czegoś nowego wiąże się z poprawianiem wszystkich kotwiczeń, co będzie niezłą rzeźnią. No ale taki sposób połączeń elementów nie spełnia kryterium "przemyślane i z głową" ;)

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.

cerrato napisał(a):

Na razie się zapoznaję z tym narzędziem, ale wydaje mi się, że jeśli z głową się rozplanuje wzajemne relacje między elementami, to dołożenie czegoś nie będzie tragedią.

I dotyczy to wszystkiego, nawet dłubania w zębach nożem.
Ale ja mam inne pytanie; czego nie da się zrobić w Delphi, a da się za pomocą masakrującego mechanizmu w Lazarusie?
Tak z ciekawości pytam...

A poza tym, w Delphi trzeba wziąć pod uwagę nie tylko Anchors, ale także Align, AlignWithMargins, Margins, Padding i być może Constraints oraz TFlowPanel.
Nie wiem co dokładnie oznaczają te ikony z pokazanego dialogu w Lazarusie...

A poza tym, tak dla porządku, to Anchors niczego i nie skaluje.
Utrzymuje rozmiar kontrolki względem jej krawędzi, przez co ona będzie większa (np. panel czy inny grid) ale nie będzie przeskalowana.

Zresztą jakakolwiek zmiana układu elementów zawsze się wiąże z reorganizacją formatki, nawet jeśli masz np. ich rozmieszczenie ogarnięte w obsłudze onResize. A jak sobie dobrze ustawisz kotwice, to powinno się dać radę w miarę bezstresowo wprowadzić zmiany.

I właśnie do tego to służy, jest bardzo proste, robi robotę i nawet wygodne.
Ale to i tak jest furda w stosunku do np. TdxLayoutControl z DevExpress.

Poza tym, jakbyś mógł (jeśli wiesz), to odpowiedz, czy Delphi posiada taką funkcjonalność (tylko gdzieś ukrytą przede mną), czy to jest wynalazek/patent typowo Lazarusowy.

Odpowiem, jeśli się dowiem co to znaczy "taką funkcjonalność" ;-)

A poza tym, tak dla porządku, to Anchors niczego i nie skaluje.

No jednak bym się kłócił :P Bo jeśli ustawię powiązanie krawędzi elementu z bokami okienka, to skalowanie okna może także spowodować skalowanie elementu.

cerrato napisał(a):

A poza tym, tak dla porządku, to Anchors niczego i nie skaluje.

No jednak bym się kłócił :P

To się kłóć, mi tam za jedno.
Skalowanie to robi np. taki WPF, a VCL co najwyżej udaje skalowanie.

Bo jeśli ustawię powiązanie krawędzi elementu z bokami okienka, to skalowanie okna może także spowodować skalowanie elementu.

Tak, ale nie odpowiada za to Anchor bezpośrednio a pośrednio, ponieważ utrzymuje rozmiar kontrolki względem innych.
A poza tym, zachęcam, włącz skalowanie okna, a najprawdopodobniej bardzo szybko je wyłączysz.

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. 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ę.

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?

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".

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ć.

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.

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. ;)

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.

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.

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. ;)

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.

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ą. :)

W Lazarusie poradzono sobie z kotwiczeniem podobnych do TLabeledEdit kontrolek TEditButton oraz TDateEdit, ponieważ przerobiono je na oparte na TCustomControl. Wcześniej był ten sam problem, co w TLabeledEdit .
TLabeledEdit jest oparte na TCustomEdit, gdzie Label jest zakotwiczony do TEdit.
Może za jakiś czas przerobią w podobny sposób kontrolkę TLabeledEdit

@furious programming co do jednego ma rację - pisanie kodu w zdarzeniu typu onResize to relikt przeszłości. Layout ma być responsywny i sam układać się odpowiednio Jeśli ktoś widział, jak projektuje się layouty w nowszych technologiach, jak wpf albo w aplikacjach mobilnych, ten wie o czym mówię. Niekiedy wręcz odchodzi się nawet od jawnego podawania rozmiarów kontrolek, mają ustawić się w oknie i same przeskalować, a wszystko bez pisania kodu.

Te kotwice w Lazarusie to mały krok w dobrym kierunku. Jeszcze nie to, co np ConstraintLayout w Androidzie, ale lepsze to, niż klepanie na małpę gównokodu w onResize. Koncepcja kotwic jest o tyle mało elastyczna, że nie pozwala definiować wzajemnych relacji pomiędzy każdą konkretną kontrolką i/lub krawędziami formularza (jeśli dobrze zrozumiałem)

Gdyby kogoś ciekawiło, jak np Google rozwiązał ten problem: https://developer.android.com/training/constraint-layout

@wloochacz: wczoraj już na forum nie zajrzałem, w międzyczasie watek trochę poszedł do przodu, a ja nabrałem dystansu do sprawy ;) W związku z czym mam propozycję/pytanie - czy zamiast przepychanki, możemy zacząć jeszcze raz?

Jeśli tak, to ja pierwszy ;)

za pomocą masakrującego mechanizmu w Lazarusie?

Co konkretnie miałeś na myśl odnośnie tego, że mechanizm jest masakrujący?

Anchors niczego i nie skaluje. Utrzymuje rozmiar kontrolki względem jej krawędzi, przez co ona będzie większa (np. panel czy inny grid) ale nie będzie przeskalowana.

OK, kwestia nazwania, może użyłem błędnego określenia. W każdym razie - żeby była jasność: chodzi mi o efekt, w którym podczas zmiany rozmiaru okna, jego elementy składowe dynamicznie reagują na zmiany, poprzez przeskalowanie się czy "przyklejenie" do brzegu okna, albo innego elementu. Może nie jest to "prawdziwe" skalowanie, ale w zakresie tego, czego oczekuję (czyli zmiany rozmiaru i/lub położenia) mechanizm oferowany przez Lazarusa działa zgodnie z moimi oczekiwaniami.

nie odpowiada za to Anchor bezpośrednio a pośrednio, ponieważ utrzymuje rozmiar kontrolki względem innych.

Wyjaśnij proszę, jakie to ma znaczenie, jak ten mechanizm działa "pod spodem"? Bo może czegoś nie rozumiem i masz rację, ale na chwilę obecną sytuacja wygląda (z mojego punktu widzenia) następująco: ustawiam sobie kotwiczenie, w którym określam, jak okno ma się zachować. I (co jest bardzo istotne) rozumiem, jak działa to narzędzie, umiem uzyskać pożądany efekt. W związku z czym, co zmienia fakt, czy anchor coś ustawia/przełącza pośrednio, czy bezpośrednio?

Dla mnie jest to jeden z mechanizmów oferowanych przez LCL/VCL. Analogicznie, można by było rozważać jak np. działa constraints - czy bezpośrednio, wykorzystuje API systemu, a może przechwytuje obsługę komunikatu związanego ze zmianą rozmiaru i nie pozwala na wyjście poza zakres? Szczerze mówiąc nie wiem, jak jest zaimplementowany mechanizm coinstraints, tak samo jak nie wiem, w jaki sposób "pod maską" działa anchor. Tak samo jak nie wiem, co dokładnie się dzieje, gdy zmieniam caption okienka. Ale moim zdaniem nie muszę tego wiedzieć, bo to są mechanizmy wyższego poziomu, oferowane przez środowisko, na których można się opierać i wcale nie trzeba rozumieć, co się dokładnie dzieje w chwili, w której się z nic skorzysta. Oczywiście - ta wiedza może się czasem przydać, ale nie jest konieczna.

W każdym razie - nie wiem, na jakiej zasadzie (od strony technicznej implementacji) działają kotwice, ale wiem, jak się powinno z nich korzystać. Czy to jest coś złego?

włącz skalowanie okna, a najprawdopodobniej bardzo szybko je wyłączysz

Być może, ale nie o tym teraz gadamy. Jak pisałem pod drugim cytatem - mi chodzi niekoniecznie o efekt "prawdziwego" skalowania, ale o mechanizm dostarczony w ramach funkcjonalności kotwic. "Prawdziwego" skalowania nie planuję uruchamiać, a nawet jakbym kiedyś do tego przysiadł, to powtórzę - nie tego dotyczy ten wątek.

[Meini napisał(a)

Te kotwice w Lazarusie to mały krok w dobrym kierunku. Jeszcze nie to, co np ConstraintLayout w Androidzie, ale lepsze to, niż klepanie na małpę gównokodu w onResize. Koncepcja kotwic jest o tyle mało elastyczna, że nie pozwala definiować wzajemnych relacji pomiędzy każdą konkretną kontrolką i/lub krawędziami formularza (jeśli dobrze zrozumiałem)

Źle zrozumiałeś, bo właśnie anchor editor w Lazarusie to ustawienie relacji między kontrolkami i krawędziami formularza

Trochę niejasno się wyraziłem, chodziło o to, że każda konkretna kontrolka może mieć relację albo z inną konkretną kontrolką, albo z krawędzią okna, nie zrozumiałem do końca czy te kotwice Lazarusa umożliwiają coś takiego, czy nie

Dlatego w pierwszym poście umieściłem screen z lazarusowego edytora kotwic, w którym specjalnie rozwinąłem listę "sibling" dla górnego kotwiczenia. Widać, że na liście da się wskazać, do czego dana kontrolka ma się doczepić, Można więc ją kotwiczyć względem okienka (Form1), ale także da się to połączyć z Button1, czyli inną kontrolką.

Można także określić jeden z 3 sposobów wyrównania - wyrównanie do środka, górnej krawędzi albo "jedno pod drugim", można także wskazać odstęp między kontrolkami (odpowiednik webowego margin używanego w CSS)

Ciekawa dyskusja, nigdy tych kotwic nie używałem, ale w końcu chciałbym by w moich programach wszystko skalowało/zmieniało rozmiary automatycznie, taki "responsive design" dla aplikacji desktopowych:)

nigdy tych kotwic nie używałem, ale w końcu chciałbym by w moich programach wszystko skalowało/zmieniało rozmiary automatycznie

No to dzięki wujkowi @cerrato masz okazję zapoznać się z nowym, bardzo przydatnym ( w mojej ocenie) mechanizmem ;)

A tak poważnie - jak pisałem, sam wcześniej miałem styczność z tym, jak to było zrobione w Delphi, a później (za namową @furious programming) przyjrzałem się temu rozwiązaniu w Lazarusie i jestem pod jego wrażeniem. A jeśli rzeczywiście jest to wersja rozwojowa, która będzie dopieszczana i poszerzana, to tylko wypada się cieszyć i z niecierpliwością czekać na więcej ;)

Nie lubię słowa „responsywny” – zostało już nieziemsko wyświechtane przez webowych głupków i kojarzy mi się jedynie z krowiastymi stronami internetowymi, ładującymi się pół godziny i marnującymi miejsce na ekranie poprzez wyświetlanie właściwej treści w kolumnie o szerokości 30% ekranu. To nie jest rosponsywność, to żenada do kwadratu. A zwróć takiemu uwagę, że interfejs to kpina, to ci powie, że nie masz pojęcia o projektowaniu UI. :/

Jeśli mowa o Lazarusie to o ile edytor kotwic pozwala wszystko dość łatwo ustawić, o tyle wolałbym jego funkcjonalność zaimplementować bezpośrednio w designerze, tak abym nie musiał obsługiwać dwóch okien (designera i edytora kotwic) i kontrolki wybierać z comboboxów. Ale póki co nie mam konkretnego pomysłu na to jak miało by to wyglądać, więc niczego deweloperom nie sugeruję (tylko pipetę zasugerowałem, o której wspomniałem w poście gdzieś wyżej).

To czego na pewno brakuje to funkcjonalność zawijania komponentów, jeśli nie mieszczą się w jednej linii w komponencie-rodzicu (albo oknie). Obecnie można to rozwiązać za pomocą TFlowPanel, no ale to jednak tylko obejście problemu. Mam nadzieję, że taka funkcjonalność się w przyszłości pojawi i że dosłownie pełne zachowanie interfejsu będzie można wyklikać, bez konieczności pisania kodu.

furious programming napisał(a):

...
Jeśli mowa o Lazarusie to o ile edytor kotwic pozwala wszystko dość łatwo ustawić, o tyle wolałbym jego funkcjonalność zaimplementować bezpośrednio w designerze, tak abym nie musiał obsługiwać dwóch okien (designera i edytora kotwic) ...

Nie wiem czy o to Tobie chodzi, ale po zainstalowaniu pakietów "AnchorDocking" i "Sparta DockedFormEditor" możesz osiągnąć poniższy efekt: