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.
kliknij dwukrotnie (szybko jak otwieranie ikonki) na comboBox1 i automatycznie powinno Ci przejść do edytowania kodu.
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.
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#.
zaiste tak ma być. Wpisz sobie w google, jest wiele poradników albo popatrz na YouTube, większość robią w Form1.h ;)
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.
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.
A ktoś pisze duże, w pełni funkcjonalne programy w C++/CLI?