C++ i Windows Forms - organizacja kodu

0

Witajcie,
To będą zupełne podstawy, ale utknęłam na samym początku. Mam Visual Studio 2010, tworzę nowy projekt Visual C++/Windows Form Application, o nazwie test. OK, pojawia się formatka, na której można coś dodać, na początek niech będzie ComboBox, samo się nazwało comboBox1. W tej chwili projekt składa się z kilku plików: Form1.h, resource.h, stdafx.h, AssemblyInfo.cpp, stdafx.cpp i test.cpp. W pliku Form1.h zadeklarowała się klasa Form1, w niej comboBox1. I teraz - chciałabym wypełnić sobie wartości do wybrania przez tego combo, ale programowo. Funkcję do dodawania wartości znalazłam - Items->Add(), no tak. Ale teraz gdzie taką funkcję umieścić? Przecież nie w Form1.h, tam gdzie się ta klasa zadeklarowała. Oddzielna funkcja utworzona w pliku test.cpp, protestuje, że nie może się dostać do prywatnej składowej klasy test::Form1. Jak to napisać? Tylko proszę "głośno i wyraźnie", jak "chłop krowie na rowie". Dziękuję z góry.

0

kliknij dwukrotnie (szybko jak otwieranie ikonki) na comboBox1 i automatycznie powinno Ci przejść do edytowania kodu.

0
Resident napisał(a)

kliknij dwukrotnie (szybko jak otwieranie ikonki) na comboBox1 i automatycznie powinno Ci przejść do edytowania kodu.

Po kliknięciu w pliku Form1.h(!) pojawia się nowa funkcja:

	private: System::Void comboBox1_SelectedIndexChanged(System::Object^  sender, System::EventArgs^  e) {
			 }
	}; 

Tak to właśnie ma być? Cały kod związany z obsługą kontrolek ma trafić do pliku Form1.h? Odczuwam jakiś wewnętrzny sprzeciw, ale jeśli taka jest dobra praktyka programowania w Windows Forms, to mogę stłamsić to uczucie.

0

No tak generalnie, programowanie interfejsów użytkownika w C++/CLI jest głupie. A już nauka C++ / .NET zaczynając od tego tworu to jeszcze większa głupota. C++/CLI używa się głównie do pisania wrapperów, żeby właśnie interfejs do jakiejś natywnej rzeczy sobie napisać w C#.

0

zaiste tak ma być. Wpisz sobie w google, jest wiele poradników albo popatrz na YouTube, większość robią w Form1.h ;)

0
Resident napisał(a)

zaiste tak ma być. Wpisz sobie w google, jest wiele poradników albo popatrz na YouTube, większość robią w Form1.h ;)

Na YouTube nie patrzyłam (to błąd, chyba), ale google raczej obadałam dość dokładnie. Przykłady są różne, ale albo są niekompletne, albo nie kompilują mi się pod 2010 jak na przykład ten: http://msdn.microsoft.com/en-us/library/system.windows.forms.combobox%28v=vs.71%29.aspx). Nic to, jak tak być, to Form1.h na tapetę i do dzieła. Dziękuję za pomoc.

0

Tak to właśnie ma być? Cały kod związany z obsługą kontrolek ma trafić do pliku Form1.h?

IDE Visual Studio generując kod wrzuca wszystko do pliku h. Sam kompilator skompiluje ci zarówno w .h jak i w .cpp — jest to tylko ograniczenie środowiska.
Możesz przerzucić funkcję do .cpp, będzie działać — ale spodziewaj się, że środowisko może od tego ogłupieć.

Po prostu twórcom VS nie chciało się tego rozbijać na dwa pliki.

No tak generalnie, programowanie interfejsów użytkownika w C++/CLI jest głupie.
Dlaczego? w C# w ogóle nie masz podziału na .h i .cpp i jakoś głupie nie jest…

A już nauka C++ / .NET zaczynając od tego tworu to jeszcze większa głupota. C++/CLI używa się głównie do pisania wrapperów, żeby właśnie interfejs do jakiejś natywnej rzeczy sobie napisać w C#.
Nie widzę istotnych przeciwwskazań. C++/CLI to nie tylko „C# z tymi głupimi ptaszkami”. Są rzeczy możliwe w C++/CLI i niemożliwe w C#, i odwrotnie.
Ale to na poziomie „linijki kodu”. W obu językach można pisać duże, w pełni funkcjonalne programy.

0

A ktoś pisze duże, w pełni funkcjonalne programy w C++/CLI?

1 użytkowników online, w tym zalogowanych: 0, gości: 1