Maksymalizacja okna Form przy projektowaniu

Niedawno wróciłem do pisania w delphi. Ostatni kontakt miałem z wersja 6. Obecna 10.3 i mam problem z maksymalizacja okna formy podczas projektowania. W starych wersjach nie było z tym problemu a przyznaję, że jest to pomocne aby dobrze rozplanować komponenty na formie
Niestety w obecnej wersji klawisz maksymalizacji okna podczas projektowania nie jest aktywny - tzn można w niego klikać ale bez efektu.. Może, ktoś wie jak to odblokować?

Using the Floating Form Designer in Delphi – przeczytaj, może zestaw opcji jest taki sam jak w 10.1.

Z tego co można wywnioskować z tego artykułu, po zmianie ustawień designera, całe IDE zmieni się w wielookienkowe, czyli będzie wyglądać tak samo jak Delphi 7 czy Lazarus. Samego designera najpewniej nie da się odpiąć, ale poszukaj sam odpowiedzi na to pytanie.

jeśli potrzebujesz okna na pełnym ekranie to robisz coś źle - aplikację trzeba tak projektować aby była niezależna od rozmiaru pulpitu, a co za tym idzie powinno się dać z nią pracować zarówno przy 1024x768 (jeszcze cały czas popularna rozdzielczość na laptopach) jak i przy 2560×1440

Dokładnie jak @abrakadaber napisał wyżej. U mnie w systemie jest ustalone, że maksymalny rozmiar okna jest na 900x600 dzięki czemu chyba na każdym współczesnym komputerze całe okno będzie widoczne zawsze i zmieści się w pełni na pulpicie. Oczywiście użytkownik może je sobie powiększyć, ale całość elementów musi być widoczna dla takiego rozmiaru okna. I nie mam żadnych problemów z umieszczaniem komponentów w oknie.

Lolek50 napisał(a):

Niedawno wróciłem do pisania w delphi. Ostatni kontakt miałem z wersja 6. Obecna 10.3 i mam problem z maksymalizacja okna formy podczas projektowania. W starych wersjach nie było z tym problemu a przyznaję, że jest to pomocne aby dobrze rozplanować komponenty na formie

@abrakadaber i @Mr.YaHooo: gdzie wy tu widzicie jakąkolwiek chęć przywiązania okna do konkretnej rozdzielczości, nieważne czy rozdzielczości formy czy ekranu? Bo ja nie widzę niczego, co by na to wskazywało.

IMO gość po prostu chce widzieć cały formularz podczas projektowania i chce również widzieć cały formularz w trybie pełnoekranowym, tak aby widzieć jak będzie wyglądało okno gdy jest małe i gdy jest maksymalnie wielkie. Oczywiście że to ułatwi projektowanie i oczywiście nie ma w tym nic złego.

abrakadaber napisał(a):

[…] aplikację trzeba tak projektować aby była niezależna od rozmiaru pulpitu […]

OP nigdzie nie napisał, że zamierza uzależnić program od konkretnej rozdzielczości. A nawet jeśli chce ustalić statyczny rozmiar głównego formularza to również nie ma w tym nic złego. Wiele programów nie posiada formularzy z taką zawartością i nie posiada takiej funkcjonalności, aby rozciągnięcie okna na pełen ekran miało jakikolwiek sens (np. kalkulator), stąd ustalenie stałego rozmiaru formularza nie jest złem wcielonym.

Mr.YaHooo napisał(a):

U mnie w systemie jest ustalone, że maksymalny rozmiar okna jest na 900x600 […]

W jakim „systemie” i dlaczego „maksymalny rozmiar”, a nie minimalny?

Ustawienie okna na 900x600 jest właśnie przywiązaniem do rozdzielczości. To że ono powinno być użyteczne w każdym rozmiarze nie wiąże się z widocznością wszystkich elementów w pierwotnej formie. Np. gridy powinny proporcjonalnie zmieniać rozmiar. Panele powinny włączać scrolle jak elementy się nie mieszczą a reprezentacja się zmieniać. Np. Ribbon z DevExpress w dużym oknie ma duże ikony. Jak się zmniejsza okno to zmienia je na mniejsze a na końcu ukrywa labelki. Zresztą maksymalizacja służy też zbadaniu jak ono się zachowa - czy kotwice poprawnie zadziałają etc.

furious programming napisał(a):

@abrakadaber i @Mr.YaHooo: gdzie wy tu widzicie jakąkolwiek chęć przywiązania okna do konkretnej rozdzielczości, nieważne czy rozdzielczości formy czy ekranu? Bo ja nie widzę niczego, co by na to wskazywało.

Mi bardziej chodzi o to, że maksymalizacja formatki w designtime nie ma zupełnego sensu. Programista zapewne ma ekran o rozdzielczości FullHD, a trzeba pamiętać, że duża część userów będzie miała o wiele mniejsze rozdzielczości. Dlatego zasadniczo nie ma takiej potrzeby, ponieważ całe okno powinno się ładnie zmieścić na ekranie. Jeśli programista nie ma dużego ekranu to niestety powinien zainwestować w sprzęt :)

Co więcej, takie podglądanie w IDE powoduje to, że trzeba to potem odwracać ręcznie przed kompilacją końcową, co za tym idzie można o tym zapomnieć. I potem wychodzą kwiatki, że userowi na malutkim ekranie pojawia się okno wielkości 1200x1600. Nie za bardzo elegancko to wygląda. Ustawianie wielkości okien w konstruktorze raczej średnio mi się podoba.

furious programming napisał(a):

IMO gość po prostu chce widzieć cały formularz podczas projektowania i chce również widzieć cały formularz w trybie pełnoekranowym, tak aby widzieć jak będzie wyglądało okno gdy jest małe i gdy jest maksymalnie wielkie. Oczywiście że to ułatwi projektowanie i oczywiście nie ma w tym nic złego.

Od tego są testy podczas działania programu. Co więcej u mnie w systemie dzieje się również magia w zdarzeniu OnResize dla niektórych formatek ponieważ nie wszystko się udawało zrobić za pomocą kotwiczenia i tym podobnych mechanizmów. Więc sama maksymalizacja formatki w IDE nie odda zazwyczaj wyglądu okna podczas działania programu.

furious programming napisał(a):

W jakim „systemie” i dlaczego „maksymalny rozmiar”, a nie minimalny?

W tym co go piszę w pracy, a piszę i końca nie widać ;)
Może źle się wyraziłem. Jest to maksymalny rozmiar domyślnej wielkości okna. Użytkownik może sobie to zmienić, ale domyślnie okno nie może być większe niż 900x600 właśnie z tego powodu, że mam jeszcze userów którzy korzystają z dość starych maszyn z ekranami 1024x768. Takie założenie powoduje to, że zawsze i na każdym systemie całe okno będzie widoczne. Co do minimalnego rozmiaru okna to tu nie ma w zasadzie żadnych ustaleń, ponieważ mam okna z 2-3 polami, jak również takie na których przy rozmiarze 900x600 trzeba się gimnastykować aby ułożyć komponenty.

somedev napisał(a):

Ustawienie okna na 900x600 jest właśnie przywiązaniem do rozdzielczości. To że ono powinno być użyteczne w każdym rozmiarze nie wiąże się z widocznością wszystkich elementów w pierwotnej formie. Np. gridy powinny proporcjonalnie zmieniać rozmiar. Panele powinny włączać scrolle jak elementy się nie mieszczą a reprezentacja się zmieniać. Np. Ribbon z DevExpress w dużym oknie ma duże ikony. Jak się zmniejsza okno to zmienia je na mniejsze a na końcu ukrywa labelki. Zresztą maksymalizacja służy też zbadaniu jak ono się zachowa - czy kotwice poprawnie zadziałają etc.

O takim rozmieszczeniu okien mi nie musisz mówić, bo zawsze mam tak zrobione, że grid dopasowuje się do zawartości okna automatycznie. Z tym scrollbarami to jest tak, że fajnie to się pisze z punktu widzenia programisty. Potem przychodzi klient (który nie zawsze jest dobrze obyty z komputerem) i niestety takie rzeczy jak scrollbary nie zawsze przejdą. Co więcej bardzo często warto trzeba mieć dużo pól na jednym oknie i jakoś to sensownie rozłożyć tak aby tych scrollbarów nie było. Osobiście nie wyobrażam sobie okna np. edycji kontrahenta gdzie cześć pól jest niewidoczna i wymaga sięgnięcia po mysz aby scrollować coś. Tak samo jak wcześniej napisałem u mnie w niektórych oknach podczas zmiany rozmiaru okna dzieje się magia, która w IDE nie wykona się.

Dodatkowo jeśli ułożę wszystko ładnie w takiej wielkości okienka mam 100% pewność, że na każdym komputerze będzie to wyglądać identycznie i ładnie.

Co do przywiązania do rozdzielczości już samo IDE wymaga takie przywiązanie. Zrób test. W moim przypadku mam laptopa z ekranem o rozdzielczości 1600x600 i maksymalna wielkość okna jaką mogę ustawić w properities to Height=912 a Width=1612. Mogę tam wpisać 2000x2000 i tak IDE zmienia mi samo na takie wartości. O ile pamiętam, to przy innych rozdzielczościach są tam inne limity.

Mr.YaHooo napisał(a):

Mi bardziej chodzi o to, że maksymalizacja formatki w designtime nie ma zupełnego sensu.

A mi chodzi o to, że jak najbardziej ma sens. Mogę sobie ręcznie rozciągnąć okno i przesunąć tak aby zakrywało cały ekran, ale mogę to zrobić jednym przyciskiem – maksymalizacji. I od razu będę widział jak się zachowuje zawartość.

Co więcej, takie podglądanie w IDE powoduje to, że trzeba to potem odwracać ręcznie przed kompilacją końcową, co za tym idzie można o tym zapomnieć.

Nie wiem czy widzisz, ale właśnie zdeprecjonowałeś proponowaną przez siebie praktykę. ;)

I potem wychodzą kwiatki, że userowi na malutkim ekranie pojawia się okno wielkości 1200x1600. Nie za bardzo elegancko to wygląda. Ustawianie wielkości okien w konstruktorze raczej średnio mi się podoba.

No i sam widzisz, że maksymalizacja jest wyjściem z twarzą w takiej sytuacji. Jeśli Ty zapomnisz z powrotem zmniejszyć rozmiar formularza w designerze, to użytkownikowi mającemu peceta z niewielką rozdzielczością okno nie zmieści się na ekranie.

Natomiast jeśli ja zapomnę wyłączyć maksymalizacji w designerze, to użytkownikowi uruchomi się program w formie zmaksymalizowanej, ale z zachowaniem oryginalnych rozmiarów. Co więcej, aby naprawić swój deweloperski błąd, wystarczy że w designerze kliknę przycisk maksymalizacji ponownie (tj. przywróć) – poprzednie rozmiary są w cały czas zapisane w lfm/dfm, więc zostaną przywrócone.

Zresztą to jest przypadek brzegowy i winny jest niedbały programista, a nie IDE.

Od tego są testy podczas działania programu.

Szczerze pisząc, nie. Po to masz designer, abyś nie musiał uruchamiać programu i sprawdzać jak będzie wyglądać i zachowywać się jego zawartość. Ale rozumiem – designer Delphi sam z siebie nie pozwala na zdefiniowanie wszystkich zachowań zawartości, więc trzeba się posiłkować OnResize, aby dodać brakujące funkcje.

W Lazarusie mamy znacznie szerszą funkcjonalność kotwic, więc wszystko można zdefiniować w designerze, bez uruchamiania i testowania programu. Oczywiście wszystko dotyczące kotwiczenia, bo np. zawijanie kontrolek (wielowierszowość czy wielokolumnowość) nie jest wspierane i nie wiadomo czy w przyszłości będzie – nie znam planów.

Może źle się wyraziłem. Jest to maksymalny rozmiar domyślnej wielkości okna.

Tu też wyrażasz się nie do końca jasno. Bo dla mnie „maksymalny rozmiar” ustala się za pomocą Constraints, ale to powoduje, że okno nigdy nie może być większe niż podane wartości. Co ciekawe, nie blokuje to możliwości maksymalizacji okna – da się zmaksymalizować, ale tylko do rozmiaru określonego w Constraints. Czyli w sumie nic odkrywczego.

I w takim przypadku przycisk maksymalizacji też jest pomocny, bo jednym kliknięciem mogę sprawdzić jak będzie okno wyglądać na maksymalnych możliwych rozmiarach, a drugim kliknięciem powrócić do tych domyślnych, bez ręcznej zmiany wartości w OI czy manualnego rozciągania okna myszą.

Użytkownik może sobie to zmienić, ale domyślnie okno nie może być większe niż 900x600 […]

Chodzi Ci o to, że masz w designerze ustawiony rozmiar 900×600 px? Bo nadal nie rozumiem o czym piszesz. ;)

Z tym scrollbarami to jest tak, że fajnie to się pisze z punktu widzenia programisty. Potem przychodzi klient (który nie zawsze jest dobrze obyty z komputerem) i niestety takie rzeczy jak scrollbary nie zawsze przejdą.

Może czas zainwestować w TPageControl?

Osobiście nie wyobrażam sobie okna np. edycji kontrahenta gdzie cześć pól jest niewidoczna i wymaga sięgnięcia po mysz aby scrollować coś.

Racja, choć nawet jeśli część pól będzie niewidoczna i trzeba będzie zescrollować zawartość, to po to jest klawisz Tab, aby nie musieć sięgać po mysz. Ale to już kwestia wyszkolenia użytkownika, bo nie każdy ogarnia po co ten klawisz istnieje.

Co do przywiązania do rozdzielczości już samo IDE wymaga takie przywiązanie. Zrób test. W moim przypadku mam laptopa z ekranem o rozdzielczości 1600x600 i maksymalna wielkość okna jaką mogę ustawić w properities to Height=912 a Width=1612. Mogę tam wpisać 2000x2000 i tak IDE zmienia mi samo na takie wartości. O ile pamiętam, to przy innych rozdzielczościach są tam inne limity.

Hmm… trochę zdziwiony jestem istnieniem takiego ograniczenia. No bo co jeśli Ty ustawisz sobie rozmiar 900×600px na swoim komputerze, a kolega z pracy ma duży ekran na swoim komputerze i zmieni rozmiar na 2000×2000px? Ty sobie po takiej zmianie odpalisz u siebie IDE, otworzysz formularz i zmiany wprowadzone przez kolegę szlag trafi – przez durną nadgorliwość środowiska.

furious programming napisał(a):

A mi chodzi o to, że jak najbardziej ma sens. Mogę sobie ręcznie rozciągnąć okno i przesunąć tak aby zakrywało cały ekran, ale mogę to zrobić jednym przyciskiem – maksymalizacji. I od razu będę widział jak się zachowuje zawartość.

No ok, jeśli o to chodzi mea culpa. Zasugerowałem się z tym z czym ja mam do czynienia :)

furious programming napisał(a):

Nie wiem czy widzisz, ale właśnie zdeprecjonowałeś proponowaną przez siebie praktykę. ;)

Nie, jeśli po prostu oglądam okno w IDE cały czas w tym samym rozmiarze.

furious programming napisał(a):

No i sam widzisz, że maksymalizacja jest wyjściem z twarzą w takiej sytuacji. Jeśli Ty zapomnisz z powrotem zmniejszyć rozmiar formularza w designerze, to użytkownikowi mającemu peceta z niewielką rozdzielczością okno nie zmieści się na ekranie.

Nie, jeśli podczas edycji zmieniam rozmiar okna tylko wtedy, gdy ma się naprawdę zmienić wartość domyślna rozmiarów okna.

furious programming napisał(a):

Szczerze pisząc, nie. Po to masz designer, abyś nie musiał uruchamiać programu i sprawdzać jak będzie wyglądać i zachowywać się jego zawartość. Ale rozumiem – designer Delphi sam z siebie nie pozwala na zdefiniowanie wszystkich zachowań zawartości, więc trzeba się posiłkować OnResize, aby dodać brakujące funkcje.

W Lazarusie mamy znacznie szerszą funkcjonalność kotwic, więc wszystko można zdefiniować w designerze, bez uruchamiania i testowania programu. Oczywiście wszystko dotyczące kotwiczenia, bo np. zawijanie kontrolek (wielowierszowość czy wielokolumnowość) nie jest wspierane i nie wiadomo czy w przyszłości będzie – nie znam planów.

Tu się niestety muszę zgodzić. Delphi ma bardzo ubogie kotwiczenie i muszę się posiłkować przesuwaniem kontrolek z poziomu kodu zamiast wygodnie wyklikać to sobie w IDE. Tu Lazarus wygrywa z jego zaawansowanym zakotwiczaniem. Weźmy na przykład okno gdzie mamy komponenty TEdit ułożone w 3 kolumnach. Nie da się wyklikać zmiany rozmiary wszystkich pól proporcjonalnie do zmiany szerokości okna.

furious programming napisał(a):

Tu też wyrażasz się nie do końca jasno. Bo dla mnie „maksymalny rozmiar” ustala się za pomocą Constraints, ale to powoduje, że okno nigdy nie może być większe niż podane wartości. Co ciekawe, nie blokuje to możliwości maksymalizacji okna – da się zmaksymalizować, ale tylko do rozmiaru określonego w Constraints. Czyli w sumie nic odkrywczego.

Może opiszę dokładniej jak to u mnie działa.
Każde okno w systemie ma swoje domyślne rozmiary. Słusznie zauważyłeś kwestię Constraints. U mnie jest tak, że większość okien umożliwia zmianę rozmiaru. Wtedy ustawiam sobie constrainsy w których minimalna wysokość oraz szerokość jest równa domyślnej wielkości okna i równa jest wielkości okna w IDE (wtedy user pierwszy raz uruchamiając okno widzi je dokładnie tak jak ja w IDE, potem przy zamykaniu okna aktualne rozmiary okna są zapisywane i jak je zmieni będzie widział iinne). Idąc dalej wszelkie okna projektowane są tak, aby zmieściły się w wielkości 900x600 (jest wymaganie aby apka była dobrze widoczna na rozdzielczości 1024x768). I większego okna nie mam w IDE, co za tym idzie to są maksymalne wartości parametrów MinHeight=600 oraz MinWidth=900 Oczywiście jak user ma większy monitor może sobie zwiększyć wielkość okienek.

furious programming napisał(a):

Chodzi Ci o to, że masz w designerze ustawiony rozmiar 900×600 px? Bo nadal nie rozumiem o czym piszesz. ;)

Otóż to, może wyżej wyjaśniłem lepiej, może nie. Ale ogólnie o to chodzi. I wielkości okienek w designerze nie zmieniam.

furious programming napisał(a):

Może czas zainwestować w TPageControl?

I tak dokładnie to rozwiązuję, jednak są klienci którzy i na to kręcą nosem. Co więcej musiałem dołożyć przechodzenie do kolejnego pola edycyjnego za pomocą klawisza ETNER, bo tak mieli przez 20 lat w programie DOS'owym. Tutaj też musiałem oprogramować aby z ostatniej kontrolki na aktualnej zakładce focus przechodził do następnej zakładki i pierwszego pola na niej. Niestety czasami takie rzeczy są trudniejsze niż realne zadania wykonywane przez system.

furious programming napisał(a):

Racja, choć nawet jeśli część pól będzie niewidoczna i trzeba będzie zescrollować zawartość, to po to jest klawisz Tab, aby nie musieć sięgać po mysz. Ale to już kwestia wyszkolenia użytkownika, bo nie każdy ogarnia po co ten klawisz istnieje.

A niektórzy jeszcze bardziej żądają zastepowania klawisza TAB klawiszem ENTER ;)

furious programming napisał(a):

Hmm… trochę zdziwiony jestem istnieniem takiego ograniczenia. No bo co jeśli Ty ustawisz sobie rozmiar 900×600px na swoim komputerze, a kolega z pracy ma duży ekran na swoim komputerze i zmieni rozmiar na 2000×2000px? Ty sobie po takiej zmianie odpalisz u siebie IDE, otworzysz formularz i zmiany wprowadzone przez kolegę szlag trafi – przez durną nadgorliwość środowiska.

Dla mnie coś takiego też jest zupełnie bez sensu. Niestety, ale Delphi potrafi uprzykrzyć życie ;)

Mr.YaHooo napisał(a):

Nie, jeśli podczas edycji zmieniam rozmiar okna tylko wtedy, gdy ma się naprawdę zmienić wartość domyślna rozmiarów okna.

No to nie rozumiem skąd argument o „zapominaniu”.

Tu Lazarus wygrywa z jego zaawansowanym zakotwiczaniem.

Owszem, ale też ma to swoje ograniczenia. O ile całe kotwiczenie da się wyklikać i od razu sprawdzić (bez kompilacji i uruchamiania), o tyle np. zawijania kontrolek zrobić się nie da. No i sam designer nie obsługuje AutoSize (ten w Delphi też nie), więc edycja zawartości okna nie powoduje aktualizowania jego rozmiaru – trzeba uruchomić i sprawdzić. Mimo wszystko i tak zaawansowane kotwiczenie znacznie ułatwia projektowanie.

Idąc dalej wszelkie okna projektowane są tak, aby zmieściły się w wielkości 900x600 (jest wymaganie aby apka była dobrze widoczna na rozdzielczości 1024x768). I większego okna nie mam w IDE, co za tym idzie to są maksymalne wartości parametrów MinHeight=600 oraz MinWidth=900 […]

Nadal nie rozumiem dlaczego o minimalnych rozmiarach piszesz, że są maksymalnymi. ;)

I tak dokładnie to rozwiązuję, jednak są klienci którzy i na to kręcą nosem.

Wszystkich nie da się zadowolić, dlatego trzeba polegać na sprawdzonych i logicznych rozwiązaniach, a nie na tym co wybredny użytkownik sugeruje.

Co więcej musiałem dołożyć przechodzenie do kolejnego pola edycyjnego za pomocą klawisza ETNER, bo tak mieli przez 20 lat w programie DOS'owym. Tutaj też musiałem oprogramować aby z ostatniej kontrolki na aktualnej zakładce focus przechodził do następnej zakładki i pierwszego pola na niej.

Robiłeś uniwersalny mechanizm do tego, czy hardkodowałeś docelowe zakładki/komponenty?

furious programming napisał(a):

No to nie rozumiem skąd argument o „zapominaniu”.

Właśnie to jest sposób na zmniejszenie błędów. Niestety ludzie są tylko ludźmi ;)

furious programming napisał(a):

Owszem, ale też ma to swoje ograniczenia. O ile całe kotwiczenie da się wyklikać i od razu sprawdzić (bez kompilacji i uruchamiania), o tyle np. zawijania kontrolek zrobić się nie da. No i sam designer nie obsługuje AutoSize (ten w Delphi też nie), więc edycja zawartości okna nie powoduje aktualizowania jego rozmiaru – trzeba uruchomić i sprawdzić. Mimo wszystko i tak zaawansowane kotwiczenie znacznie ułatwia projektowanie.

Tak, jednak mam już wypracowane metody i sposoby na ręczne ustawianie kontrolek które działają, więc w zasadzie automat mi nie jest potrzebny. Chociaż chciałoby się trochę automatyzacji.

furious programming napisał(a):

Nadal nie rozumiem dlaczego o minimalnych rozmiarach piszesz, że są maksymalnymi. ;)

Dobra, to kwestia techniczna z tym nazewnictwem (wiem, że mało precyzyjne, ale u nas każdy wie o co biega :) ). Przyjmijmy, że w uproszczeniu w systemie żadne okno nie przekracza rozmiarów 900x600 Co za tym idzie nie mam problemu z brakiem maksymalizacji formy w designtime. Swoją drogą nie pamiętałem, że w starym Delphi była taka możliwość.

furious programming napisał(a):

Wszystkich nie da się zadowolić, dlatego trzeba polegać na sprawdzonych i logicznych rozwiązaniach, a nie na tym co wybredny użytkownik sugeruje.

Dlatego też staram się metodą małych kroczków userów przyzwyczajać do nowych zmian wprowadzając je po kolei prawie niezauważalnie, a starsze rozwiązania usuwam po pewnym czasie.

furious programming napisał(a):

Robiłeś uniwersalny mechanizm do tego, czy hardkodowałeś docelowe zakładki/komponenty?

Niestety nie było czasu na pisanie pełnego automatu który wyszuka sobie jaką zakładkę najpierw trzeba włączyć, a potem którą kontrolkę. Zrobiłem w ten sposób, że mam obiekt zarządzający przechodzeniem pomiędzy kontrolkami utworzony dla każdego okna oddzielnie. W konstruktorze okna podaję do tego obiektu listę kontrolek dla występują "anomalie". Działa to dość sprawnie, jednak doskwiera brak automatyzacji. Czasami po dodaniu nowego pola edycyjnego na końcu zaburzona jest kolejność tabulacji i nie daje się przejść do nowego pola z klawiatury. Dlatego muszę po prostu bardziej testować takie rzeczy.

Mr.YaHooo napisał(a):

Swoją drogą nie pamiętałem, że w starym Delphi była taka możliwość.

We wszystkich niedokowanych RAD-ach istnieje taka możliwość, bo okno designera jest po prostu osobno. No i w takim przypadku przyciski systemowe są zgodne z ustawieniami BorderIcons. ;)

furious programming napisał(a):

Mr.YaHooo napisał(a):

Swoją drogą nie pamiętałem, że w starym Delphi była taka możliwość.

We wszystkich niedokowanych RAD-ach istnieje taka możliwość, bo okno designera jest po prostu osobno.

Nigdy nie lubiłem tego niedokowanego układu. A w BCB6 pracowałem dosłownie chwilkę, więc temu nie pamiętałem :)