دلفي وكوم:TLB وقضايا الصيانة

Question

في الشركة التي أعمل بها، نقوم بتطوير كل واجهة المستخدم الرسومية بلغة C#، ولكن تم تطوير نواة التطبيق بشكل أساسي في دلفي 5 (لأسباب تاريخية)، مع الكثير من المكونات المصنوعة في COM+.فيما يتعلق بهذا النوع المحدد جدًا من التطبيقات، لدي سؤالان:

• أيها الرجال ذوو الخبرة في دلفي و/أو COM، هل لديكم أي حلول بديلة للعمل مع واجهة TLB التي تجرها الدواب؟بعض الأخطاء هي:تعطل IDE أثناء إصدار TLB كبير، أو فقدان معرفات الأساليب، أو تلف TLB، وما إلى ذلك.وهنا لم نجد أي حل جيد.في الواقع حاولنا القيام بالترقية إلى الإصدار الجديد 2007.لكن واجهة IDE TLB الجديدة بها نفس الأخطاء التي اكتشفناها من قبل.

• كيف يمكنك التحكم في إصدارات TLBs؟ملف TLB بتنسيق ثنائي ومن الصعب جدًا حل التعارضات.لقد حاولنا القيام بذلك عن طريق تصدير أوصاف الواجهات إلى IDL والالتزام بـ CVS، لكننا لم نجد أي طريقة جيدة لإنشاء TLBs من IDL باستخدام دلفي.بالإضافة إلى ذلك، لم تقم أداة MIDL المقدمة من Microsoft بتحليل ملفات IDL التي قمنا بتصديرها من دلفي بشكل صحيح.

Answer 1

أعتقد أنه يجب عليك إلقاء نظرة فاحصة على دلفي 2009.

يحتوي Delphi 2009 على تغييرات في دعم COM، بما في ذلك الاستبدال المستند إلى النص لملفات TLB الثنائية.

يمكنك قراءة المزيد عن مدونة كريس بنسن.

Answer 2

في الماضي البعيد (قبل أن أبدأ العمل في CodeGear) تخليت عن لغة IDL الغريبة التي تم تقديمها بواسطة IDE، وكتبت IDL الخاصة بي وقمت بتجميعها باستخدام MS midl.نجح هذا إلى حد كبير.كان المصيد الوحيد، IIRC، هو التأكد من صحة dispids (سمة المعرف) على واجهات التشغيل الآلي (واجهات dispinterface) لمحصلي الملكية ومحدداتها - كان هناك بعض الثوابت التي توقعها tlibimp ولكن midl لم يضمنها.

ومع ذلك، الآن بما أن دلفي 2009 يستخدم مجموعة فرعية آمنة من بناء جملة midl، ويتضمن مترجمًا لهذا midl في الصندوق ومدمجًا في IDE، فيجب أن تكون هذه المشكلات شيئًا من الماضي.

Answer 3

لقد قمنا أيضًا بتثبيت Delphi 2009 للتو ويبدو أنه قد قمنا بتحسين الدعم لمكتبات Typelibraries.ومع ذلك، فقد عملت مع COM ومكتبات الكتابة لبعض الوقت، وإليكم الأخطاء العامة التي وجدتها على مر السنين.أوافق على أنها عربات التي تجرها الدواب الجميلة وهي تصل إلى Delphi 2006 (الإصدار الخاص بنا قبل استخدام 2009).

• اجعل كل ملف قابلاً للكتابة دائمًا قبل فتحه.قد يبدو هذا واضحًا، ولكن عند العمل مع التحكم بالمصادر أحيانًا ننسى القيام بذلك ونحاول إزالة علامة القراءة فقط بعد فتح ملف - لا تستطيع دلفي التعامل مع هذا.تأكد من أن tlb قابل للكتابة قبل الفتح.
• في حالة تحرير مكتبة طباعة مستقلة، يجب أن يكون لديك مشروع مفتوح.لسبب ما، إذا قمت بفتح مكتبة نوع بمفردها، فلن يتم حفظها.أنشئ مشروعًا فارغًا ثم افتح مكتبة الطباعة الخاصة بك.لسبب ما يسمح هذا بحفظ مكتبة النوع.
• إذا تم استخدام مكتبة النوع الخاصة بك بواسطة تطبيق أو COM+ فتأكد من إيقاف تشغيل التطبيق أو تعطيل COM+ قبل فتح مكتبة النوع.ستمنع أي تطبيقات مفتوحة حفظ مكتبة النوع.

ومع ذلك أعتقد أن الحل الأفضل لك هو على الأرجح الترقية.يمكنك الحصول على دعم Unicode أيضًا.

Answer 4

أدى استخدام Delphi 2009 إلى تخفيف الكثير من المعاناة عن ملفات TLB الضخمة، وكان تحويل الكائنات الموجودة لدينا سهلاً، ولكن كائنات com الخاصة بنا لا تستخدم أي مكتبات تابعة لجهات خارجية.

سنقوم بترحيل تطبيقات واجهة المستخدم الرسومية الخاصة بنا بمجرد قيام موردي المكتبات بإصدار الإصدارات المدعومة.

Answer 5

نفس التجربة مع واجهة TLB هنا:لقد توقفنا ببساطة عن استخدامه.

نحن نعمل مع عدة ملفات IDL منفصلة (مصممة يدويًا) لأجزاء مختلفة من إطار العمل الخاص بنا، مع الاستفادة من بنية #include لتضمينها في IDL للتطبيق الفعلي، ثم قم بإنشاء ملف tlb واحد باستخدام MIDL وtlibimp عليه.إذا لم يكن التطبيق يحتوي على IDL خاص به، فستتوفر نسخة مجمعة مسبقًا من ملفات TLB الإطارية المختلفة.

عندما يدخل إطار العمل إلى إصدار جديد، يتم تشغيل برنامج نصي لإعادة إنشاء GUIDS على كافة الواجهات الضرورية في ملفات IDL.

لقد خدمنا هذا جيدًا لسنوات عديدة، ولكي ننتقل إلى مجموعة أدوات Delphi 2009 IDL/TLB الجديدة، يجب ألا يتم دمجها في IDE فحسب، بل أيضًا متعددة الاستخدامات عندما يتعلق الأمر بالبنيات الآلية وما إلى ذلك.لا أستطيع الانتظار حتى أتسخ يدي ببعض التجارب!