تصحيح أخطاء معالجة المصمم في VS 2008

Question

لدي ملكية عامة محددة في نموذج النوع الخاص بي ListE<T> أين:

public class ListE<T> : IList<T>, ICollection<T>, IEnumerable<T>, IList, ICollection, IEnumerable

نعم، إنها مجموعة كبيرة، ولكن هذا ما يطلبه المصمم لكي تظهر كمجموعة قابلة للتحرير في نافذة الخصائص.وهو ما يفعله!لذا، قمت بالنقر فوق الزر الصغير [..] لتحرير المجموعة، ثم انقر فوق "إضافة" لإضافة عنصر إلى المجموعة.

وأسفرت عملية حسابية في تجاوز.

الآن، هذه قائمة أساسية جدًا، وهي ليست أكثر من مجرد مصفوفة موسعة.الجزء الوحيد الذي يقترب من الحساب في الأمر برمته هو في دالة التوسيع، وحتى ذلك يستخدم التحول الأيسر بدلاً من الضرب، لذلك لن يتجاوز ذلك.كل هذا يجعلني أعتقد أن هذا الاستثناء قد تم طرحه داخل المصمم، ربما بسبب بعض عدم الاهتمام البسيط بتفاصيل التنفيذ من جهتي، لكن لا يمكنني العثور على طريقة لاختبار هذا السيناريو أو تصحيحه.هل لدى أي شخص أي أفكار ذكية؟

يحرر:نعم، يمكنني استخدام الخاصية بنجاح، وحتى يدويًا، أي.في ال OnLoad المعالج، وأفترض أن هذا ما سأضطر إلى اللجوء إليه إذا لم أتمكن من تشغيل هذا، لكن هذا لن يكون مثاليًا.:(

Answer 1

لا أستطيع أن أفهم ما الذي يدفعك إلى محاولة إعادة اختراع عجلة List<T> بهذه الطريقة، ولكن للإجابة على سؤالك:أود إضافة سطر "System.Diagnostics.Debugger.Break()" إلى مُنشئ الفصل الدراسي الخاص بك.

ثم حاول استخدامه في المصمم، وستظهر لك نافذة منبثقة تسألك عما إذا كنت تريد إرفاق مصحح أخطاء.قم بإرفاق نسخة ثانية من Visual Studio كمصحح أخطاء، وستتمكن من تعيين بعض نقاط التوقف في التعليمات البرمجية الخاصة بك والبدء في تصحيح الأخطاء.

Answer 2

أحد الأماكن التي يمكن البدء بها هو إجراء العمليات الحسابية باستخدام خاصية ListE`1::Count الخاصة بك.إذا كان هذا به بعض العيوب الدقيقة (أي.إنه أكثر تعقيدًا من إرجاع this.innerList.Count) فقد يتسبب في تجاوز المصمم للحسابات في بعض العمليات.عادةً لا تحدث التجاوزات الحسابية ما لم يُطلب على وجه التحديد استخدام الدالة

checked
{
   // ...
}

بناء الجملة.

Answer 3

ليس عليك إضافة Debugger.Break();اتصل بالرمز الخاص بك لتصحيحه.يمكنك فقط فتح مثيل مختلف لـ VS وإرفاقه بالمثيل الذي تستخدمه فيه ويجب أن تكون قادرًا على تصحيحه دون أي مشاكل (فقط تأكد من تحميل الرموز).