Temat: Dynamiczny Graphics WinForms

Witam.
Piszę program, który rysuje graf .
Picturebox jest automatycznie skalowany podczas zmiany rozmiaru okna głównego aplikacji( właściwość Anchor).
Podczas skalowania jednak sam Graphics nie jest automatycznie dostosowywany do rozmiaru okna tak jak sam picturebox, przez co rysunek zostaje ograniczony do pewnego stałego obszaru.

Mój picturebox-> graphArea.Image = new Bitmap(graphArea.Width, graphArea.Height);
Wyjsciowo jest tworzona bitmapa o rozmiarach picturebox'a(jak wyżej).
Dalej:gdzie g=>Graphics
g = Graphics.FromImage(graphArea.Image);

Próbowałem już z podmianą bitmapy podczas skalowania okna - new Bitmap(graphArea.Width, graphArea.Height);
Teoretycznie wysokość i szerokość powinna ulec zmianie tak jak sam picturebox->graphArea ale w rzeczywistości tak nie jest . Jakieś pomysły jak to rozwiązać?
Pozdrawiam.Ten post został edytowany przez Autora dnia 04.11.14 o godzinie 08:14

Temat: Dynamiczny Graphics WinForms

Jeśli dobrze zrozumiałem to podam przykład.

             pictureBox1.Image = Image.FromFile("pobrane.jpg");

            Graphics g = Graphics.FromImage(pictureBox1.Image);

do przeładowania metody onLoad wrzuciłem ten kod, nic nadzwyczajnego. I tak jak w twoim przypadku w momencie rozszerzania okna obrazek nie skalował się mimo iż picture box był zadokowany.
Proponuję badać moment przekroczenia wysokości ona i zmieniać SizeMode pictureBoxa na StretchImage - wtedy zmiana rozmiaru okna będzie także zmieniała rozmiar obrazka w środku.

Jeśli nie o ten problem chodziło, proszę o więcej informacji lub po prostu kod źródłowy. I podziałamyTen post został edytowany przez Autora dnia 04.11.14 o godzinie 12:25

Temat: Dynamiczny Graphics WinForms

Powiem tak, to po części rozwiązuje problem jeśli chodzi o samo wyświetlanie(czegoś podobnego próbowałem wcześniej).
Może podam przykład o co dokładniej mi chodzi:
Tworzę sobie przestrzeń roboczą:
InitializeComponent();
graphArea.Image = new Bitmap(graphArea.Width, graphArea.Height);
g = Graphics.FromImage(graphArea.Image);
rysuje sobie punkt
g.FillEllipse(new SolidBrush(Color.Red), x, y, 10, 10);

Przy czym x,y - użyte wyżej współrzędne punktu losuje sobie używając randoma na obszarze ograniczonym
graphArea.Width, graphArea.Height =>
x = r.Next(0, graphArea.Width);
y = r.Next(0, graphArea.Height);
g.FillEllipse(new SolidBrush(Color.Red), x, y, 10, 10);
PictureBox(mój graphArea) jest zadokowany => dock in Parent Container

Po uruchomieniu aplikacji okno nie jest zmaksymalizowane na fullScreen,
załóżmy że jest w rozmiarze 600x450.
GraphArea.Width , graphArea.Height pobierze aktualny stan okna , wylosuje punkty z tego obszaru od 0 - podanych wartości(Height,Width), narysuje je.

Robie resize na fullscreen. GraphArea.Width graphArea.Height się zmienia .
Poprzednie wartości pozostają w mniejszym obszarze w części 450x600 (tak jak to było przed maxymalizacją na fullscreen) patrząc od lewego górnego rogu(0,0) a reszta z obszaru 1024x768 po resize na fullScreen jest pusta.
Sam strechImage jest ok , tylko że on po maksymalizacji przybliża obrazek - powiększa/rozciąga .
Bardziej chodzi mi o efekt centerImage z możliwością zachowania proporcji obrazka.W tym momencie samo centerImage jest dobre, jednak dana przestrzeń dalej jest ograniczona do 600x450 leżąc w centralnej części okna w przy fullRezise .Chyba nie pozostaje mi nic innego jak podczas resize przerysowac obrazek z uwzględnieniem przesunięcia punktów dla pełnej rozdzielczości=> tak, żeby punkty były rozrzucone równomiernie w zmaksymalizowanym oknie przy zachowaniu proporcji.

Tak widocznie musi być skoro same współrzędne punktów zamykają się pierwotnie w mniejszym obszarze(charakterystycznym dla początkowego uruchomienia aplikacji).

Dziwne jednak jest to, że ten obszar po zmaksymalizowaniu i próbie losowania punktu nie rozszerza się, tylko zawsze wyjściowym ograniczeniem jest Width i Height z okna niezmaksymalizowanego (600x450) a nie z fullscreen np.(1024x768),to tak jakby graphArea.Width i graphArea.Height się nie zmieniały.
Możliwe, że odczytania wartości należy dokonać podczas wywołania metody resize na oknie.
Nie wiem czy podany przykład okaże się zrozumiały, mam nadzieję, że tym razem udało mi się naświetlić problem.
Pozdrawiam.Ten post został edytowany przez Autora dnia 05.11.14 o godzinie 20:30

Temat: Dynamiczny Graphics WinForms

Z rozszerzalnością itp. nie ma problemu tak jak wspomniałeś zachowanie odpowiednich skali w punktach narysowanych przed zmianom wielkości, w tym tkwi problem. Bo obszar Graphics się rozszerza i podąża za rozmiarem pictureboxa ale niestety punkty które poprzednio zostały narysowane zmieniają swój rozmiar.

Albo zastosować jakąś macierz transformacji i skalować.
Pomysł aby generowane punkty dodawać do listy i przy resize_end i generowaniu nowej grafiki przerysowywać je. Wszystko fajnie zachowujemy wielkości punktów itd. Tyle, że przy zmniejszaniu zasłonimy sobie te które są wygenerowane poza tym obszarem (ale to normalne)

Temat: Dynamiczny Graphics WinForms

Koniec końców albo właśnie zastosuję wspomnianą macierz transformacji 2D żeby sobie wprowadzić zależności między położeniem punktów albo coś spróbuję zrobić jeszcze z tym przerysowaniem na nowo.
Dziękuję za cenne uwagi no i zamykam temat.
Pozdrawiam.Ten post został edytowany przez Autora dnia 05.11.14 o godzinie 20:33

Temat: Dynamiczny Graphics WinForms

Do takich rzeczy polecam WPF, który oparty jest o grafikę wektorową i jest bardzo szybki dzięki wsparciu ze strony DirectX. Ale podejrzewam, że w twoim projekcie już za późno na zmianę technologii.

Temat: Dynamiczny Graphics WinForms

Marcin ma rację Formsy to raz że przeżytek dwa skalowanie automatyczne bez grafiki wektorowej kosztuje więcej pracy niż z niej zysku.

Temat: Dynamiczny Graphics WinForms

Tak, generalnie jeśli chodzi o sam projekt, to w sumie nic wielkiego - trochę zabawa na własną rękę z grafami, które równie dobrze można by wyświetlić jako macierz lub lista sąsiedztwa w konsoli.
To prawda , Formsy już praktycznie odeszły w niepamięć. W WPF z pewnością byłoby to o wiele prostsze ale trochę już na to teraz za późno, także tym razem jeszcze będzie wymagało to większego nakładu pracy a na przyszłość WPF.