2012-11-14 6 views
6

मैं सी ++ विंडोज़ एप्लिकेशन में सी # में लिखे गए विंडोज फॉर्म एप्लिकेशन को एम्बेड करने का एक तरीका ढूंढ रहा हूं। मूल अनुप्रयोग मुख्य विंडो कई पैन में विभाजित है। सी # ऐप उन पैनों में से एक के भीतर दिखाई देना चाहिए, यानी सी # घटक (बाहरीतम रूप) की मूल विंडो मुख्य अनुप्रयोग की एक बाल खिड़की होनी चाहिए।एक अप्रबंधित ऐप की बाल विंडो के रूप में विंडोज फॉर्म

क्या यह किया जा सकता है? यदि हां, तो कैसे?

कुछ अतिरिक्त संदर्भ: मेरे ज्ञान के लिए, इसके बारे में जाने के दो तरीके हैं। सबसे पहले, .NET होस्टिंग API (ICLRRuntimeHost, आदि) का उपयोग करके मूल ऐप में सीएलआर होस्ट करें। दूसरा, विंडोज़ फॉर्म को ActiveX नियंत्रण में डालकर सीएलआर होस्ट करें।

पहले दृष्टिकोण के संबंध में, मैंने सीएलआर शुरू करने और सी # असेंबली लोड करने में कामयाब रहा है (काफी हद तक Mattias Högström पर धन्यवाद)। जहां मैं एक रोड ब्लॉक मार रहा हूं, यह है कि मुझे सीएलआर में चल रहे घटक को बताने का कोई तरीका नहीं है कि इसे सी ++ पक्ष से गुजरने वाली खिड़की का बच्चा होना चाहिए।

मैंने दूसरी विधि (ActiveX का उपयोग करके और Daniel Yanovsky के लिए धन्यवाद) के साथ भी प्रयोग किया है। यह लगभग, लेकिन केवल लगभग, मेरे उद्देश्यों के लिए काम करता है। मैं देशी ऐप के एक बच्चे के फलक में मनमाने ढंग से विंडोज फॉर्म घटकों को चला सकता हूं। लेकिन वे हमेशा मुख्य ऐप के मुख्य धागे पर चलते हैं। इसका मतलब है कि वे मुख्य ऐप के विंडोज़ संदेश लूप का उपयोग करते हैं। एमएसडीएन का कहना है कि यह विश्वसनीय रूप से काम नहीं करेगा क्योंकि मानक विंडोज संदेश लूप विंडोज फॉर्म की आवश्यकताओं को पूरा नहीं करते हैं (मैं यहां एमएसडीएन को लिंक पोस्ट करना चाहता था लेकिन पहले से ही अपने नए उपयोगकर्ता-दो-लिंक-आवंटन का उपयोग कर चुका हूं)।

एमएसडीएन, इंटरनेट एक्सप्लोरर और एमएफसी ऐप्स के अनुसार, संदेश लूप मुद्दे के अपवाद हैं। एक मेजबान के रूप में उपयोग कर रहा मूल ऐप निश्चित रूप से इंटरनेट एक्सप्लोरर नहीं है। साथ ही, यह विंडोज एपीआई का उपयोग wxwidgets द्वारा लिपटे के रूप में करता है, इसलिए एमएफसी नहीं है (या कम से कम स्वागत नहीं है) विकल्प।

माइक्रोसॉफ्ट के प्रस्तावों में सी # घटकों को अपने स्वयं के धागे पर अपने संदेश loops में चलाने के प्रस्ताव शामिल हैं। यह, कम से कम जहां तक ​​मैं कह सकता हूं, जरूरी है कि उपरोक्त वर्णित पहले दृष्टिकोण पर वापस जाएं। तो मैं एक पारित पैरेंट विंडो के तहत काम करने के लिए एक विंडोज फॉर्म प्राप्त करने के सवाल पर वापस आ गया हूं।

फिर से, मुझे किसी भी इनपुट में दिलचस्पी है जो बाल खिड़की के मुद्दे को स्पष्ट करता है, जो मैंने यहां उल्लेख किए गए दृष्टिकोण से स्वतंत्र है। लेकिन संदर्भ के आलोक में मैं दो विशिष्ट प्रश्न के लिए सामान्य प्रश्न कम कर सकता है (और मैं उनमें से केवल एक का जवाब की आवश्यकता होगी):

  • को देखते हुए एक Windows प्रपत्र एक एक्टिव एक्स नियंत्रण में होस्ट, मैं कैसे अनुमति दे सकते हैं अपने स्वयं के धागे पर अपने संदेश लूप में चलाने के लिए फार्म?

या

  • एक Windows प्रपत्र एक CLR एक स्थानीय एप्लिकेशन द्वारा की मेजबानी में चल रहा यह देखते हुए, मैं कैसे प्रपत्र स्थानीय ऐप्लिकेशन में एक खिड़की का एक बच्चा खिड़की होना कर सकते हैं?
+0

क्या आप इसे समझने में कामयाब रहे? इसके अलावा एमएसडीएन लेख का लिंक क्या है? –

+0

आपको इसके लिए ActiveX की आवश्यकता नहीं है। जब आप फॉर्म कहते हैं तो क्या होता है। दिखाओ? आप एक IWin32Window (C++ विंडो हैंडल को वापस करने वाले इस इंटरफ़ेस को लागू कर सकते हैं) को मालिक के रूप में पास कर सकते हैं और आप शक्तिशाली सेटपैरेंट एपीआई के बारे में भी जानते हैं: http://msdn.microsoft.com/en-us/library/windows/desktop/ms633541 (v = vs.85) .aspx –

+0

आपके उत्तरों के लिए धन्यवाद। @ डेनिस क्रूज़: यह [एमएसडीएन लिंक] है (http://msdn.microsoft.com/en-us/library/ms229600.aspx)। @ सिमॉन मैंने पैरेंट को स्थापित करने के साथ प्रयोग नहीं किया है क्योंकि मुझे पता नहीं था कि विंडोज फॉर्म उस विकल्प की पेशकश करते हैं और मूल मूल के साथ मजबूती से निपट सकते हैं। मुझे लगता है कि मुझे IWin32Window पर नज़र डालने की आवश्यकता है। समय की बाधाओं के कारण हमें इसे थोड़ा बर्नर पर थोड़ा सा रखना पड़ा। मैं 2013 की शुरुआत में इसे वापस आने की उम्मीद कर रहा हूं। मैं सीएलआर की मेजबानी के संदर्भ में मूल खिड़की के माता-पिता को स्थापित करने की कोशिश करने से शुरू करूंगा और पोस्ट करूंगा कि चीजें कैसे काम करती हैं। – user1824048

उत्तर

1

हाँ, यह किया जा सकता है। हमने साल पहले एक ही काम किया था। यह हमारा दृष्टिकोण है: .NET नियंत्रण में मूल विंडो हैंडल भी है, हम इन्हें सी ++/सीएलआई के माध्यम से प्राप्त करते हैं और उन्हें Win32 पर पास करते हैं, और इन हैंडल को देशी विंडो के बच्चों के रूप में जोड़ते हैं। इसलिए .NET नियंत्रण मुख्य ऐप के मुख्य थ्रेड पर चलते हैं, समस्याग्रस्त हिस्सा संदेश लूप है, जैसा कि आपने अपने प्रश्न में उल्लेख किया है। यदि आवश्यक हो तो हमें राष्ट्र और .NET विंडो के बीच संदेश को रूट करने की आवश्यकता है। जैसा कि मैंने याद किया, हमने इससे संबंधित कई बग तय की, और फिर भी कुछ रहस्यमय समस्याएं थीं जिन्हें हमने नहीं समझा था।

एनोथ तरीका है: WPF इंटरऑप का उपयोग करना। http://msdn.microsoft.com/en-us/library/ms742522.aspx। एमएस के अनुसार, यह संदेश की समस्याओं को ठीक करना चाहिए, लेकिन हमने इस दृष्टिकोण को आजमाया नहीं है। आप WPF होस्ट करने के लिए केवल Win32 का उपयोग कर सकते हैं, फिर Winform होस्ट करने के लिए WPF का उपयोग करें।

अपने पिछले 2 प्रश्नों के लिए

तो:

  1. आप नहीं कर सकते। केवल एक संदेश पाश।
  2. हैंडल का उपयोग करें। यह आलेख विंडोज प्रपत्रों के हैंडल के बारे में बात करता है: http://blogs.msdn.com/b/jfoscoding/archive/2004/11/24/269416.aspx
+0

लेख 2 को बहुत दिलचस्प है। मैं Win32/C++ व्यक्ति से अधिक हूं और अक्सर यह सुनिश्चित नहीं करता कि सभी .NET तत्व अंतर्निहित (?) Win32 ब्रह्मांड से कितने कड़े हैं। वह लेख दिशा में इंगित करता है: एक फॉर्म अभी भी एक खिड़की है। जब मैं इसके साथ आगे बढ़ता हूं तो मैं फॉर्म को "सामान्य" बाल खिड़की के रूप में समझने की कोशिश करने के सुविधाजनक बिंदु से शुरू करूंगा और फिर उम्मीद करता हूं कि सीएलआर लागू नहीं होगा। – user1824048

संबंधित मुद्दे