2011-01-07 32 views
11

मुझे विंडोज 7 के तहत बोरलैंड सी ++ बिल्डर 5.0 से विंडोज 7/एमआईजीडब्ल्यू के तहत जी ++ का उपयोग करके क्यूटी 4.7.1 में एक प्रोजेक्ट पोर्ट करना होगा। पुस्तकालयों और कमांड लाइन उपयोगिताएं की जाती हैं, और अब मुझे जीयूआई अनुप्रयोगों से निपटना है, जो बोर्लैंड वीसीएल का उपयोग करते हैं।
क्या कोई इस कार्य को आसान बनाने के लिए किसी भी उपकरण या पुस्तकालयों की सिफारिश कर सकता है?
क्या किसी के पास इसका कोई अनुभव है?पोर्टिंग बोरलैंड सी ++ बिल्डर को क्यूटी

जोड़ने के लिए संपादित: ठीक है, मैंने सींग से बैल लिया, और जीयूआई को खरोंच से लागू किया। और मुझे कहना है, टिप्पणीकार सही थे: प्रक्रिया को कम करने के लिए मौजूदा बोर्लैंड जीयूआई का उपयोग करने का कोई तरीका नहीं दिख रहा है।

+0

आपके सी ++ बिल्डर जीयूआई के कितने रूप हैं? केवल कुछ, दर्जनों, सैकड़ों? जैसा कि आप शायद जानते हैं, यदि आप स्क्रैच से क्यूटी जीयूआई बनाते हैं तो आपको सर्वोत्तम परिणाम मिलते हैं। –

+0

कुछ दर्जन रूप। उनमें से कुछ पेड़ के दृश्य, टैब इत्यादि के साथ काफी जटिल हैं। इसलिए यदि मैं इससे बच सकता हूं तो मैं उन सभी को स्क्रैच से नहीं बनाना चाहता हूं। – TonyK

+0

मैं सोच रहा हूं कि कोई इस सवाल से पूछता है :) वीसीएल से क्यूटी तक स्वचालित रूपांतरण संभव कार्य नहीं लगता है। –

उत्तर

8

वीसीएल और क्यूटी के बीच कई बड़े अंतर हैं जो स्वचालित रूपांतरण प्रक्रिया को काफी कठिन बना देंगे।

  • क्यूटी संकेतों और स्लॉट और विरासत का उपयोग करता है जहां VCL घटनाओं का उपयोग करता है।
  • वीसीएल घटक पूर्ण निर्देशांक का उपयोग करते हैं और क्यूटी लेआउट का उपयोग करता है। बेशक, आप क्यूटी के साथ भी पूर्ण निर्देशांक का उपयोग कर सकते हैं, लेकिन जीयूआई तब काफी भयानक होंगे।
  • वीसीएल के टीएलिस्टबॉक्स और टीटीवी व्यू कक्षाएं क्यूटी के दृश्य और मॉडल वर्गों से काफी अलग हैं (हालांकि आप इसके बजाय QListWidget और QTreeWidget का उपयोग कर सकते हैं)।

मुझे लगता है कि क्यूटी के साथ पूरी तरह से नए जीयूआई डिजाइन करने के लिए यह एक तेज़ वीसीएल-टू-क्यूटी कनवर्टर बनाने के लिए बहुत तेज है। और कोड बनाए रखने के लिए बहुत आसान होगा। मेरा सुझाव है कि आप मध्यम जटिलता का एक वीसीएल फॉर्म लें और क्यूटी के साथ इसे फिर से बनाएं। इसके बाद आप कुल मनोरंजन कार्य का आकलन कर सकते हैं। इसके अलावा आपको एक रूपांतरण टूल की व्यवहार्यता के बारे में बेहतर समझ होगी, जिसे आपको शायद अपने आप को बनाना होगा।

1

किसी एक उपकरण क्यूटी ui फ़ाइलों को DFM के कन्वर्ट करने के लिए लिखा है:

http://sourceforge.net/projects/dfm2qt4ui/

इसके कुछ छोटे कीड़े है, लेकिन यह समय पोर्टिंग फॉर्म डिजाइन के कई घंटे बचा सकता है। कुछ मामलों में विशिष्ट रूपों को फिर से डिजाइन करना बेहतर होता है - लेकिन कई मामलों में, आपके पास स्थित लेबल और लगभग बराबर नियंत्रण वाले नियंत्रण होने से बहुत सी बिंदु-और-क्लिक कार्रवाई होती है।

+0

उपकरण का प्रयास किया। नतीजा मुझे बिल्कुल संतुष्ट नहीं करता था।मैं देखता हूं कि परियोजना को बंद करने का सबसे अच्छा तरीका स्क्रूच से जीयूआई लागू कर रहा है क्योंकि लेखक ने कहा। – vrogach

+0

पूरी तरह से फॉर्म पर नियंत्रण की संख्या पर निर्भर करता है। इसने मुझे बहुत सारे कामों को बचाया है, लेकिन अभी भी .ui फ़ाइलों को फिर से व्यवस्थित करने की आवश्यकता है। लेकिन कम से कम नियंत्रणों में समान वैरिएबल नाम होते हैं और पहले से ही फॉर्म में जोड़े गए हैं। एक पूर्ण पुनर्लेख हमेशा नई बग पेश करेगा। – Pete

1

मैं वर्तमान सर्वसम्मति से सहमत हूं कि वीसीएल से क्यूटी तक स्वचालित रूपांतरण एक अच्छा विचार नहीं है क्योंकि दोनों के पीछे की अवधारणा बहुत अलग है, और आप "क्यूटी मार्ग" सीखने और शुरुआत से इसका उपयोग करने से काफी बेहतर हैं।
हालांकि एक बड़ा कदम है कि किसी ने अभी तक उल्लेख नहीं किया है: refactoring! शुरू करने से पहले, सुनिश्चित करें कि आप जितना संभव हो उतना व्यवसाय तर्क निकालने के लिए मूल रूपों को दोबारा दोहराएं और वास्तव में केवल जीयूआई कोड छोड़ दें। यह इस बात पर निर्भर करता है कि आपका आर्किटेक्चर पहले से ही कितना अच्छा है, लेकिन वीसीएल डिजाइनर फॉर्म में जितना संभव हो सके उतना संभव बनाने के लिए प्रोत्साहित करता है (यहां तक ​​कि अदृश्य दृश्य डेटा के साथ अदृश्य "डेटा फॉर्म" भी जा रहा है), तो आप अक्सर पाते हैं उस रूप में बहुत सारी चीज़ें जो वहां नहीं होनी चाहिए।

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