وراثة معالجات الأحداث في C#

Question

لقد المدعومة نفسي في زاوية هنا.

لدي سلسلة من UserControls أن يرث من الوالدين ، الذي يحتوي على اثنين من الأساليب والأحداث إلى تبسيط الأمور لذلك أنا لم يكن لديك لكتابة خطوط شبه متطابقة رمز.كما كنت تفعل.الأم لا يحتوي على عناصر تحكم أخرى.

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

هنا سؤالي.Visual Studio يعتقد أنا ذكي جدا بمقدار النصف ، ويحذر لي أن "الأسلوب 'CheckReadiness' [معالج الحدث في [الأم] لا يمكن أن يكون طريقة لهذا الحدث لأن فئة هذه الفئة مشتقة من يعرف طريقة." نعم, Visual Studio ، هذا هو المقصود.أنا تريد أن يكون معالج الحدث هذا فقط يتعامل مع الأحداث القيت من قبل الطبقات الطفل ، مهمته فقط لتمكين لي أن ربط الأطفال دون الحاجة إلى كتابة سطر واحد من التعليمات البرمجية.لا تحتاج تلك معالجات إضافية - كل وظيفة لا تحتاج بطبيعة الحال كما دعا الأطفال عملية إدخال المستخدم.

لست متأكدا من السبب في Visual Studio بدأت تشكو من هذا الآن (كما اسمحوا لي أن تفعل ذلك من قبل) ، وأنا لست متأكدا كيف لجعله يذهب بعيدا.ويفضل أود أن تفعل ذلك من دون الحاجة إلى تحديد الأسلوب الذي يدعو فقط CheckReadiness.ما سبب هذا التحذير ، ما تسبب تأتي الآن عندما لم ساعه كيف يمكنني جعله يذهب بعيدا دون اللجوء إلى بعض معالجات في جميع الطفل الطبقات ؟

Answer 1

تعلن الوالد الأسلوب الظاهري ، تجاوز ذلك في فصول الأطفال و الاتصال

base.checkReadyness(sender, e);

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

الشيء الوحيد الذي لاحظته هو أنه إذا كان كل هذا الرمز يتم وضعها داخل dll ثم قد تواجه الأداء ضرب أحاول الاتصال معالج الحدث من داخل dll.

Answer 2

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

ما يجري هو صالح - التحكم التي لا توجد إلا في اشتقاق فئة و فئة مشتقة هو ربط معالج الحدث إلى أحد من السيطرة على الأحداث.حقيقة أن الطريقة التي يتم التعامل مع الحدث يتم تعريف في قاعدة الطبقة لا هنا ولا هناك ، وهي متوفرة عند نقطة الربط إلى الحدث.هذا الحدث لا تعلق مرتين أو أي شيء سخيف مثل هذا, انها مجرد مسألة من حيث الأسلوب الذي يتعامل مع الحدث المحدد.

بالتأكيد هو ليس أسلوب الظاهري - أنا لا أريد طريقة للتجاوز من قبل فئة مشتقة.محبطة جدا و في رأيي خطأ في dev-ستوديو.

Answer 3

أنا أيضا واجهت هذه المشكلة لأنه في الإصدارات السابقة من مقابل ، يمكن أن "يرث" معالجات الأحداث.لذلك الحل وجدت دون الحاجة إلى تجاوز الأساليب هو ببساطة تعيين معالج الحدث في مكان ما في مرحلة التهيئة من النموذج.في حالتي القيام به في منشئ (أنا متأكد OnLoad() من شأنه أن تعمل بشكل جيد):

    public MyForm()
    {
        InitializeComponent();
        btnOK.Click += Ok_Click;
    }

حيث Ok_Click معالج يقيم في شكل قاعدة.غذاء للفكر.

Answer 4

لقد واجهت نفس المشكلة Merus أول من أثار مثل الآخرين الذين نشر الردود, أنا ليس من الواضح ما VS (أنا الآن باستخدام Visual C# 2010 Express) الكائنات إلى وجود معالج الحدث المحدد في الفئة الأساسية.السبب أنا نشر الرد هو أنه في عملية الحصول على جميع أنحاء المشكلة من خلال جعل قاعدة الطبقة رمز الحماية طريقة أن الفئات المشتقة ببساطة الاحتجاج في (الأساس فارغ) معالجات الأحداث ، فعلت ريفاكتور إعادة تسمية قاعدة الطبقة الأسلوب و لاحظت أن VS مصمم توقفت عن الشكوى.أي أنها سميت معالج الحدث التسجيل (حتى أنه لم يعد يتبع مقابل مصمم الاتفاقية تسمية معالجات الأحداث مع ControlName_EventName) ، ويبدو أن تفي بذلك.عندما حاول تسجيل (التي أعيدت تسميتها الآن) قاعدة معالج الحدث ضد فئة مشتقة الضوابط من خلال إدخال اسم في مقابل الحدث, مصمم إنشاء حدث جديد معالج في فئة مشتقة الذي ثم حذف ، وترك فئة مشتقة التحكم المسجلة في الفئة الأساسية (معالج الحدث) الأسلوب.صافي, كما كنت تتوقع, C# يجد ما نريد أن نفعله شرعي.انها فقط مقابل مصمم أن لا أحب ذلك عندما كنت التالية المصمم معالج الحدث اصطلاح التسمية.أنا لا أرى ضرورة مصمم للعمل بهذه الطريقة.على أية حال, الوقت للقيام.

Answer 5

إذا كان هذا الحدث الخاص بك هو بالفعل تعريف في فئة الأم لا تحتاج إلى أسلاك مرة أخرى في طفلك الدرجة.التي من شأنها أن تسبب الحدث إلى النار مرتين.

تحقق إذا كان هذا هو ما يحدث.HTH :)

Answer 6

هذه المادة على MSDN ينبغي أن يكون نقطة انطلاق جيدة: تجاوز معالجات الأحداث مع Visual Basic .صافي.نلقي نظرة على كيف يعالج البند يمكن أن يسبب مشاكل في فئة مشتقة القسم.

Answer 7

لماذا لا تعلن الأسلوب كما الظاهري في فئة الأم ثم يمكنك تجاوز ذلك في الفئات المشتقة لإضافة وظائف إضافية?

Answer 8

ننسى أنه معالج الحدث و المناسبة العادية طريقة تجاوز الطفل في الصف.

Answer 9

هنا هو ما فعلته للحصول على قاعدة أساليب عدة مماثلة تبحث أشكال ، كل واحد منهم وجود عدد قليل من ميزات اضافية لتلك الشائعة:

        protected override void OnLoad(EventArgs e)
    {
        try
        {
            this.SuspendLayout();
            base.OnLoad(e);

            foreach (Control ctrl in Controls)
            {
                Button btn = ctrl as Button;
                if (btn == null) continue;

                if (string.Equals(btn.Name, "btnAdd", StringComparison.Ordinal))
                    btn.Click += new EventHandler(btnAdd_Click);
                else if (string.Equals(btn.Name, "btnEdit", StringComparison.Ordinal))
                    btn.Click += new EventHandler(btnEdit_Click);
                else if (string.Equals(btn.Name, "btnDelete", StringComparison.Ordinal))
                    btn.Click += new EventHandler(btnDelete_Click);
                else if (string.Equals(btn.Name, "btnPrint", StringComparison.Ordinal))
                    btn.Click += new EventHandler(btnPrint_Click);
                else if (string.Equals(btn.Name, "btnExport", StringComparison.Ordinal))
                    btn.Click += new EventHandler(btnExport_Click);
            }

فرصة إغفال استخدام زر الثابتة الاسم يبدو لي فرصة لا الأسلاك الموروثة معالج يدويا.

ملاحظة قد تحتاج إلى اختبار هذا.DesignMode بحيث يمكنك تخطي رمز في مقابل مصمم على الإطلاق, لكنه يعمل بشكل جيد بالنسبة لي حتى من دون تحقق.