Poszukuję sposobu na osadzenie aplikacji Windows Forms napisanych w języku C# w aplikacji Windows C++. Główne okno aplikacji macierzystej jest podzielone na kilka okien. Aplikacja C# powinna pojawić się w jednym z tych okien, tzn. Okno główne składnika C# (najbardziej zewnętrzna forma) musi być oknem podrzędnym głównej aplikacji.Windows Form jako okno podrzędne niezarządzanej aplikacji
Czy to można zrobić? Jeśli tak to jak?
Jakiś dodatkowy kontekst: Według mojej wiedzy są dwa sposoby na osiągnięcie tego celu. Najpierw host CLR w rodzimej aplikacji za pomocą API .net hosting (ICLRRuntimeHost, itp.). Po drugie, host CLR, umieszczając okna formularza w formancie ActiveX.
Jeśli chodzi o pierwsze podejście, udało mi się uruchomić CLR i załadować zespół C# (w dużej mierze dzięki Mattias Högström). Tam, gdzie trafiam blokadę drogi, nie widzę sposobu, aby powiedzieć komponentowi, który uruchamiam w CLR, że musi on być dzieckiem okna przekazanego od strony C++.
Eksperymentowałem również z drugą metodą (przy użyciu ActiveX i dzięki Daniel Yanovsky). To prawie, ale tylko prawie, działa dla moich celów. Mogę pozwolić, aby dowolne komponenty Windows Forms działały w okienku podrzędnym rodzimej aplikacji. ALE zawsze działają w głównym wątku głównej aplikacji. Oznacza to, że używają pętli wiadomości systemu Windows w głównej aplikacji. MSDN twierdzi, że nie będzie działać niezawodnie, ponieważ standardowe pętle wiadomości systemu Windows nie spełniają wymagań Windows Forms (chciałem opublikować link do MSDN tutaj, ale już wykorzystałem mój nowy użytkownik-dwa-łącze-przydział).
Wyjątki od problemu z pętlą komunikatów to według aplikacji MSDN, Internet Explorer i MFC. Natywna aplikacja, której używam jako hosta, zdecydowanie nie jest przeglądarką Internet Explorer. Ponadto używa interfejsu API systemu Windows jako opakowanego przez wxWidgets, więc MFC nie jest (lub przynajmniej nie jest mile widziane).
Rozwiązania proponowane przez firmę Microsoft polegają na umożliwieniu komponentom języka C# uruchamiania ich własnych pętli komunikatów na ich własnych wątkach. To, przynajmniej z tego, co wiem, koniecznie prowadzi do pierwszego podejścia wspomnianego powyżej. Wracam więc do pytania o sprawdzenie, czy Formularz Windows działa pod przekazanym nadrzędnym oknem.
Ponownie, jestem zainteresowany wszelkimi danymi wejściowymi, które wyjaśniają kwestię okien potomnych, niezależnie od podejść, o których tutaj wspomniałem. Ale w świetle kontekstu mogę zmniejszyć ogólne pytanie na dwa konkretne pytania (i będę potrzebował odpowiedzi na tylko jeden z nich):
- Given Windows Form gościł w kontrolce ActiveX, jak mogę pozwolić formularz do uruchomienia we własnej pętli wiadomości na własnym wątku?
lub
- Biorąc pod Windows Form działa w CLR gospodarzem natywnej aplikacji, w jaki sposób można sprawić, że forma będzie okno dziecko przez okno w natywnej aplikacji?
Udało ci się to rozgryźć? Co to jest link do tego artykułu msdn? –
Do tego nie powinieneś potrzebować ActiveX. Co się stanie, gdy zadzwonisz do formularza. Pokażesz? Możesz przekazać IWin32Window (implementuj ten interfejs, zwracając uchwyt okna C++) jako właściciela, a także znasz zaawansowany interfejs API SetParent: http://msdn.microsoft.com/en-us/library/windows/desktop/ms633541 (v = vs.85) .aspx –
Dziękuję za odpowiedzi. @ Dinis Cruz: To jest link [msdn link] (http://msdn.microsoft.com/en-us/library/ms229600.aspx). @Simon Nie eksperymentowałem z ustawianiem nadrzędnego, ponieważ nie wiedziałem, że Windows Forms oferuje tę opcję i może radzić sobie z rodzimym rodzicem. Chyba muszę przyjrzeć się dokładnie IWin32Window. Ze względu na ograniczenia czasowe musieliśmy to nieco odłożyć na bok. Mam nadzieję, że wrócę do tego na początku 2013 roku. Zacznę od próby ustawienia rodzimego rodzica okna w kontekście hostowania CLR i opublikuję, jak to wszystko działa. – user1824048