[pabloAntonio]

#it #programowanie #cszarp #programista15k #windowsforms
Mam główne okno aplikacji (Form1 form1), które po kliknięciu przycisku przywołuje drugie okno (Form2 form2), w konstruktorze Form2 przyjmuję jako parametr Form1 form1 i jest przypisany do zmiennej Form1 form1_send zadeklarowanej w Form2, tak żeby móc mieć dostęp do zmiennych instacji form1. Jak najprościej zrobić żeby form2 zachowywał się różnie w zależności od instancji klasy Form1, która go wywołała? Chce wywołać Form2 przez inny obiekt Form1.

[Khaine]

@pabloAntonio: Możesz mu dać Form1 jako argument konstruktora i sobie na poziomie Form2 posprawdzać co powinien zrobić. Generalnie temu Form2 i tak powinieneś dawać Form1 jako parent - bo co się stanie jak zamkniesz Form1 z otwartym Form2? Może Form2 sobie wziąć i zawisnąć, kiedy powinien się zamknąć bo główny wątek aplikacji został wyłączony (chyba, że Form2 ma być samostójką a nie jedynie supportem do Form1 - to wtedy niekoniecznie).

[3.....W]

@pabloAntonio: Tych instancji Form1 może być ile? 2/3/nielimitowana liczba? Jak nielimitowana to generuj jakiś GUID w konstruktorze Form1 (Guid.NewGuid()) i przypisuj do property i na tej podstawie odróżnisz instancje. Co to znaczy "zachowywał się różnie"?

[cecyl]

@pabloAntonio: polecam wpf i viewmodele

[3.....W]

@pabloAntonio: jak mają być 2 instancje to po prostu w momencie tworzenia Form1 przekazuj do konstruktora jakiś stringowy identyfikator i przypisuj do property.

[Khaine]

polecam wpf i viewmodele

@cecyl: Yhy, taa, WPF i MVVM dla kogoś kto ewidentnie dopiero uczy się coś klikać. Ja w tym robię od ponad roku a nadal tego nie lubię, bo pierdyliony linijek kodu trzeba naspamować.

[3.....W]

@pabloAntonio: Coś to dziwne że chcesz mieć 2 instancje głównego okna.

[Khaine]

Coś to dziwne że chcesz mieć 2 instancje głównego okna.

@3THU5_9r3W: Coś chyba źle przeczytałeś, Form2 to inna klasa od Form1. I jedno i drugie ma mieć po jednej instancji, z czego Form2 ma się różnie zachowywać w zależności od tego w jakim stanie jest Form1 - przynajmniej ja tak rozumiem.

[3.....W]

Mam główne okno aplikacji (Form1 form1)

Chce wywołać Form2 przez inny obiekt Form1.

@Khaine:

[Khaine]

@3THU5_9r3W: No ja rozumiem tak, że kliknięcie w coś w obiekcie Form1 utworzy nam obiekt Form2, który ma się zachowywać jakoś odpowiednio w zależności od stanu obiektu Form1.

[pabloAntonio]

@Khaine: > Może Form2 sobie wziąć i zawisnąć, kiedy powinien się zamknąć bo główny wątek aplikacji został wyłączony (chyba, że Form2 ma być samostójką a nie jedynie supportem do Form1 - to wtedy niekoniecznie).

Mam sprecyzowaną funkcję For2_Closing w konstruktorze więc się wszystko zamyka jak powinno

Tych instancji Form1 może być ile? 2/3/nielimitowana liczba? Jak nielimitowana to generuj jakiś GUID w konstruktorze Form1 (Guid.NewGuid()) i przypisuj do property i na tej

[3.....W]

@pabloAntonio: Property = publiczne pole (upraszczając)

[Khaine]

Mam sprecyzowaną funkcję For2_Closing w konstruktorze więc się wszystko zamyka jak powinno

@pabloAntonio: Nie musisz jak ustawisz parenta - moim zdaniem. Więc nie musisz mieć property które przechowuje Form2 osobno, możesz go przechowywać w property które dziedziczysz z Form o nazwie Parent. Minus jest taki, że na poziomie Form2 musiałbyś wtedy dokonywać rzutowania chcąc odnosić się do właściwości charakterystycznych dla Form2 a nie Form.

Form2 myForm =

[3.....W]

No nie prawda. Property może być równie dobrze prywatne czy jakiekolwiek inne. Różnica pomiędzy polem a property jest taka, że property zawiera jakieś ukryte w kompilacji gettery i settery. Property nawet nie musi być powiązane z żadnym polem, to może być getter który dynamicznie zwraca jakieś rzeczy w locie, a ich wartość wcale nie musi być fizycznie przechowywana w jakimś polu klasy (np. może nam otworzyć zapytanie do bazy danych i zwrócić

[pabloAntonio]

Emm, co to znaczy więcej instancji? Generalnie MainForm w aplikacji powinien być jeden.

@Khaine: przyjmijmy że Form1 to nie jest MainForm ;) skłamałem, bo myslałem że gorzej namieszam

Tak poza konkursem to warto iść jeszcze w C# bo z tego co słyszałem to WindowsForms są na wymarciu. Jaką ścieżką iść jakbym chciał to pociągnąć w webdev?

[pabloAntonio]

"weż to upublicznij".

@3THU5_9r3W: tak zrobię zobaczę z jakim efektem

[3.....W]

@pabloAntonio: Winformsy są dobre tylko do prostych rzeczy. Do okienek profesjonalnie używa się WPFa. Jak chcesz robić webdev (w tym jest najwiecej pracy) to ASP.NET MVC albo ASP .net core.

[Khaine]

@pabloAntonio: WinForms są na wymarciu, to prawda. Na wymarciu jest także WPF i wszystkie aplikacje desktopowe ( ͡° ͜ʖ ͡°) Ale z tych dwóch to raczej WPF + wzorzec MVVM.

Ogólnie wzorzec MVVM to taka wstępna wprawka do webu. Bardzo wstępna, ale na pewno bliżej webu niż desktopowy wzorzez MVC.

Natomiast jak niekoniecznie chcesz od razu zaczynać od webu, tylko pobawić się czymś prostszym (mniej do ogarniania) to tak

[pabloAntonio]

@Khaine: poleciłbyś jakąś książkę albo kurs mvvm?
Widzę coś takiego, ale to raczej na apki windowsowe
https://helion.pl/ksiazki/mvvm-i-xaml-w-visual-studio-2015-jacek-matulewski,xamlmv.htm#format/d

[Khaine]

@pabloAntonio: J---j książki ( ͡° ͜ʖ ͡°) Nie są w praktyce do niczego potrzebne, dokumentacja jest w necie, tutoriale też. Przynajmniej jeśli chodzi o sam język. Książki są dobre jakbyś się chciał uczyć algorytmiki czy wzorców projektowych, jedno i drugie jest w necie ale przynajmniej w książce jest zebrane do kupy i uporządkowane - wtedy wzięcie takiej książki do ręki po uprzednim przeczytaniu daje jakieś pomysły

[cecyl]

@Khaine: o widzę że sam wpf poleciłeś.

Co do mvvm to nie trzeba go w pełni implementować. Tu myślę że same v i vm by starczyły.

Co do webowki to mvvm imo to super pomysł w tych technologiach. Mvc mam nadzieję że umrze w mękach :)