2010-05-04 16 views
11

मैं डेल्फी 2010 का उपयोग कर रहा हूं और मैं सोच रहा हूं कि वीसीएल शामिल करने के लिए कॉल के माध्यम से प्रोजेक्ट में मौजूद कोड के माध्यम से पता लगाने का कोई तरीका है या नहीं।क्या डेल्फी में केवल प्रोजेक्ट स्रोत के माध्यम से पता लगाने का कोई तरीका है?

उदाहरण के लिए - यदि आप एक ब्रेकप्वाइंट में डाल दिया और उसके बाद पंक्ति-दर-पंक्ति के माध्यम से पता लगाने के लिए शिफ्ट + एफ 7 का उपयोग करें। अब आप वीसीएल में कुछ लंबी प्रक्रियाओं के लिए कॉल में भाग लेते हैं - मेरे मामले में यह अक्सर मापन स्टूडियो या अन्य घटक होता है जो आईओ/ओ, ओपीसी, या अन्य बिट्स के समूह के लिए डूडैड खींचता है। किसी भी दर पर, क्या होता है कि डीबगर सक्रिय स्रोत फ़ाइल से बाहर हो जाता है, घटक स्रोत खोलता है, और लाइन के माध्यम से उस रेखा के माध्यम से निशान लगाता है। प्रायः यह सैकड़ों या हजारों लाइनों की कोड है जिनकी मुझे परवाह नहीं है - मैं बस इसे निष्पादित करना चाहता हूं और मेरी परियोजना में अगली स्रोत पंक्ति पर वापस जाना चाहता हूं।

जाहिर है आप बाहरी कॉल के हर उदाहरण के चारों ओर ब्रेकपॉइंट्स सेट करके ऐसा कर सकते हैं, लेकिन अक्सर यह व्यावहारिक बनाने के लिए बहुत सारे लोग हैं - मैं हर बार एक सौ ब्रेकपॉइंट्स सेट करने में एक घंटे खर्च करूँगा जब भी मैं एक कदम से गुजरना चाहता था कोड का खंड

क्या कोई सेटिंग या कोई उपकरण है जो ऐसा कर सकता है? परियोजना के भीतर कोड के माध्यम से कोड के माध्यम से पता लगाने की अनुमति दें जबकि चुपचाप परियोजना को बाहरी कोड निष्पादित किया जाए?

उत्तर

12

डिबगर इकाइयों के माध्यम से कदम नहीं होगा कि, डिबग जानकारी नहीं है तो लक्ष्य संकलक इकाइयों आप में कोई दिलचस्पी नहीं कर रहे हैं से डिबग जानकारी को छोड़ देते हैं बनाने के लिए है।

में अपने पुस्तकालय इकाइयों रखो एक अलग पुस्तकालय परियोजना। इससे आपको को प्रोजेक्ट को प्रभावित किए बिना उन इकाइयों के लिए अलग संकलन सेटिंग्स की क्षमता मिलती है। डिबगिंग जानकारी सक्षम किए बिना लाइब्रेरी संकलित करें। फिर अपनी परियोजना से उन लाइब्रेरी इकाइयों को हटा दें। आप उनका उपयोग जारी रख सकते हैं, लेकिन वे अब आपके प्रोजेक्ट से संबंधित नहीं होंगे।

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

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

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


नोट भले ही आप अपने पुस्तकालय इकाइयों के लिए एक अलग पुस्तकालय परियोजना होगा कि, आप लिंक या DLL या पैकेज है कि कि इस परियोजना को उत्पन्न करता है वितरित करने के लिए की जरूरत नहीं है। आप सीधे अपने EXE प्रोजेक्ट में डीसीयू फ़ाइलों का उपयोग करना जारी रख सकते हैं। आप केवल अलग परियोजना स्थापित कर रहे हैं ताकि आप उन इकाइयों के लिए अलग संकलन सेटिंग्स का चयन कर सकें। लाइब्रेरी प्रोजेक्ट के डीसीयू आउटपुट फ़ोल्डर को अपने EXE प्रोजेक्ट के खोज पथ में जोड़ें, और आप लाइब्रेरी प्रोजेक्ट के डीएलएल या पैकेज को वितरित करने की आवश्यकता के बिना सीधे इकाइयों का उपयोग जारी रख सकते हैं।

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

+0

धन्यवाद, रॉब - यह बहुत उपयोगी है। वर्तमान में पुस्तकालयों को परियोजना में शामिल नहीं किया गया है, वे बस बीपीएल हैं जिन्हें सीधे "घटक-> पैकेज स्थापित करें ..." के माध्यम से डेल्फी में जोड़ा गया है। मैंने अपनी बिन/पैकेज निर्देशिका की जांच की, हालांकि, और पाया स्रोत फाइलें वास्तव में डीसीयू के साथ उपफोल्डर में हैं। मैं जो सुझाव देता हूं उसका प्रयास करूंगा और देख सकता हूं कि क्या मैं समझदारी से व्यवहार नहीं कर सकता हूं। धन्यवाद कृपया - मेरी इच्छा है कि मैं आपको एक बियर खरीद सकता हूं! –

+1

मैंने मूल पोस्ट में "शामिल" के अपने अस्पष्ट उपयोग को देखा - मुझे लगता है कि मुझे यह कहना चाहिए था कि इन्हें केवल इस सीमा तक शामिल किया गया था कि उन्हें मेरी इकाइयों के "उपयोग" खंडों में संदर्भित किया गया था और नहीं कि मैं शारीरिक रूप से अटक गया मेरे प्रोजेक्ट में स्रोत। बस वही, मुझे लगता है कि यह वास्तव में बिन फ़ोल्डर में भटक स्रोत था कि डेल्फी अंडरवर्ल्ड से पता लगाने के लिए खोद रहा था। इसे एक छोटे से पट्टा पर रखना होगा, आह? –

3

डीबग जानकारी और स्थानीय प्रतीक सूचना संकलक निर्देशों का उपयोग करने का एक और तरीका है - प्रत्येक इकाई की शुरुआत में {$D-$L-} जोड़ें।

यह हमेशा उस इकाई के लिए डीबग जानकारी की पीढ़ी को दबाने देगा। यदि आपको कोड में पता लगाने की आवश्यकता है, तो निर्देशों पर टिप्पणी करें।

+1

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

+0

@ जस्टिन: शायद आप इसे उन कुछ लोगों के लिए कर सकते हैं जिन्हें आप स्वयं 98% समय में दर्ज करते हैं। – lkessler

+0

@ जस्टिन, @ल्केस्लर - यही वह है जो मैं खुद को "98%" के साथ करता हूं, लेकिन मैंने हाल ही में केवल –

4

बस अपने विकल्पों को पूरा करने के लिए: यदि किसी कारण से आपके पुस्तकालयों को डीबग जानकारी के साथ संकलित किया जाना चाहिए (मैं आम तौर पर वीसीएल और आरटीएल समेत डीबग जानकारी के साथ सब कुछ उपयोग करता हूं) और आप गलती से उस विधि में ट्रेस करते हैं जिसमें आप रुचि नहीं रखते हैं , जब तक विधि आपके कोड पर वापस नहीं आती है तब तक आप Shift + F8 का उपयोग कर सकते हैं।

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

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