C# WindowsForms, Dziedziczenie po kontrolce ?

Tak można tak zrobić. Prosty przykład przycisku, który ma inne tło niż standardowy Button.

 public class WhiteButton : Button
    {
        public WhiteButton():base()
        {
           this.BackColor = Color.White;
        }
    }

dziedziczenie po kontrolkach to proszenie sie o klopoty, zeby wymienic tylko 3 praktyczne problemy - vs designer szybko durnieje, logika zaczyna sie komplikowac, liskov principle zostaje zlamany.
najlepiej zrob sobie custom/user kontrolke zawierajaca ten przycisk + cala reszte wymagan.

Tworzenie własnych kontrolek poprzez dziedziczenie z wbudowanych to dość standardowa i powszechna procedura. Dziedziczenie z istniejącej kontrolki, a tworzenie własnej user kontrolki to są dwie różne rzeczy, i nawet jeśli efekt wizualny będzie taki sam, to nie znaczy, że można to stosować zamiennie. Zwłaszcza, że usercontrol służy do czegoś zupełnie innego - tworzenia fragmentów GUI do łatwego umieszczania w wielu miejscach aplikacji w celu uniknięcia copy&paste.
@JeloneK - jak chcesz mieć swój przycisk, to robisz przycisk, a nie usercontrol.

Co do zarzutów @katelx:

1. Designer nie zwariuje, dopóki nie próbuje się robić jakichś porąbanych rzeczy typu łączenie z bazą albo rzucanie wyjątków w konstruktorze takiej kontrolki.
2. Utworzenie UserControl nie sprawia, że logiki będzie mniej. Czasami wręcz przeciwnie, np. w sytuacji, gdy chcemy korzystać z jakichś metod protected danej kontrolki bazowej.
3. Dziedziczenie samo w sobie LSP nie łamie.

Tak na przyszłość, jeśli będziesz potrzebował dodatkowych metod do istniejących klas (metod, a nie pól), zawsze możesz też posłużyć się rozszerzeniami (extensions). Bardzo fajna sprawa. Ogólnie wygląda to tak, że tworzysz nową klasę statyczną, w której umieszczasz swoje metody (grunt to pierwszy parametr). Po szczegóły odsyłam do google.

@somekind sporo sie nacierpialam przez magikow ktorzy uwazali ze dziedziczenie to sprytny sposob na dodawanie nieskonczonej ilosci rozszerzen do kontrolek, wiec raczej mnie nie przekonasz :)
oczywiscie jak z wiekszoscia dyskusyjnych praktyk, gdy robi sie to z glowa to jest ladnie i dziala, niestety jest to bardzo czesto naduzywane i potem powstaje dlugasna hierarchia z pierdyliardem dziwnych zaleznosci, nie do ogarniecia nawet przez autora, nie mowiac o kolegach robiacych tu i owdzie szybkie poprawki bo cos nie dziala.
co do LSP to jasne ze samo dziedziczenie nie lamie, jednak dodawanie nowych featuresow przez wygodnickich juz zwykle tak.
oczywiscie jesli projekt to jedna kontrolka to pewnie nie jest to takie istotne, no ale tak czy siak bardziej mi sie podoba MyControl : UserControl niz MyControl : Button

A po co pisać button od nowa, skoro potrzebujesz buttona z dodatkową funkcją? To jest normalne dziedziczenie. I tak jak w każdym innym przypadku, jeśli zrobisz to źle, to będzie źle zrobione :)

@Juhas ale nikt tu nie mowi o pisaniu buttona od nowa, btw jakis przyklad funkcji dla ktorej bys po tym przycisku dziedziczyl?

Np. dropdown buttona bym chciał zrobić :) Z tego, co wiem, to nie ma go w standardzie. I tu nie wystarczy ani zwykły extension, ani nawet usercontrol, bo trzeba zmienić nieco wygląd przycisku.
A jakby jeszcze dorzucić mu popup menu, no to już inaczej jak dziedziczenie się nie da. Owszem, można stosować jakieś sztuczki w stylu utworzenia user control z dwoma buttonami. Jeden to będzie ten "główny", a drugi tuż obok niego(tak żeby nie było widać, że to dwa) z odpowiednią ikonką i akcją. OK, da się to zrobić. Ale co w momencie, gdy potrzebujesz mieć dłuższy guzik? Albo krótszy? Zaczynają się już niezdrowe komplikacje, które wprowadzają niepotrzebny chaos.

katelx napisał(a):

@somekind sporo sie nacierpialam przez magikow ktorzy uwazali ze dziedziczenie to sprytny sposob na dodawanie nieskonczonej ilosci rozszerzen do kontrolek, wiec raczej mnie nie przekonasz :)

Ależ nie mam zamiaru przekonywać kogoś, kto tak się upiera, że nie umie zapanować nad kodem do tego, że jednak potrafi. :P

tak czy siak bardziej mi sie podoba MyControl : UserControl niz MyControl : Button

Zakładam, że problem dotyczy tworzenia MyButton, nie MyControl, czyli przycisku z dodatkowymi możliwościami albo zmienionym zachowaniem, nie grupy kontrolek stanowiących jedność. Jak potem wywołujesz metody protected z klasy Button? Refleksją? To dopiero musi być czysty kod nie łamiący żadnych zasad SOLID. ;)

@somekind odwracasz kota ogonem; przeciez nie chodzi mi o to zeby nigdy nie dziedziczyc, ani nawet o to ze jakies solid'owe regulki sie nie zgadzaja. jestem natomiast przekonana ze uzycie kompozycji zamiast dziedziczenia w wypadku kontrolek (i nie tylko) jest duzo latwiejsze do ogarniecia przez poczatkujacego, trudniej sobie strzelic w stope i kod jest pozniej prostszy do zrozumienia i modyfikacji przez autora (i ew. innych).

A mi chodzi o to, że po prostu nie zawsze się da, albo nie zawsze ma sens używanie kompozycji zamiast dziedziczenia. Jeśli masz np. jakiś generyczny mechanizm operujący na TextBoxach, to lepiej jest zrobić własny TextBox, aby współdziałał z istniejącym kodem, niż komponować i pisać oddzielne mechanizmy dla UserControl z TextBoxem w środku. Zwłaszcza, że udostępnianie wewnętrznych kontrolek takiego UserControl będzie łamaniem kolejnych zasad dobrego programowania.

Albo inny przykład - potrzebny jest datepicker, który pozwala użytkownikowi na wybieranie całych miesięcy, nigdy dni. Jak osiągniesz to kompozycją?

ale ja nie twierdze ze kompozycja to zawsze najlepsze rozwiazanie, po cos te kontrolki nie sa sealed, natomiast stanowczo protestuje przeciwko dziedziczeniu gdy nie jest ono potrzebne.

Dziedziczenie opisuje relację "coś jest czymś". Dopóki zielony samogrający przycisk w żółte kropki pozostaje przyciskiem, sensowne jest dziedziczenie z bazowej klasy przycisków.

jasne, z tym ze w takiej sytuacji nie bardzo widze sens dziedziczenia zamiast uzycia wlasciwosci. chodzi mi o przypadki takie jak chocby tutaj (gdzie chodzi o stworzenie pola szachownicy) czy o wspomnianego buttona z popup, nie nazwalabym tych tworow przyciskami.

katelx napisał(a):

jasne, z tym ze w takiej sytuacji nie bardzo widze sens dziedziczenia zamiast uzycia wlasciwosci. chodzi mi o przypadki takie jak chocby tutaj (gdzie chodzi o stworzenie pola szachownicy) czy o wspomnianego buttona z popup, nie nazwalabym tych tworow przyciskami.

Co nie znaczy, że ich użycie w takim przypadku musi być czymś złym/niepoprawnym. Trochę to może być zagmatwane, ale "jeżeli coś jest głupie i działa, to nie jest głupie" ;)

camed_ napisał(a):

Trochę to może być zagmatwane, ale "jeżeli coś jest głupie i działa, to nie jest głupie" ;)
jesli swiadomie sie wybiera zagmatwany sposob to chyba jednak jest ;)

jasne, z tym ze w takiej sytuacji nie bardzo widze sens dziedziczenia zamiast uzycia wlasciwosci. chodzi mi o przypadki takie jak chocby tutaj (gdzie chodzi o stworzenie pola szachownicy) czy o wspomnianego buttona z popup, nie nazwalabym tych tworow przyciskami.

Twoje rozwiązanie („kompozycja” jednego buttona) powoduje dylemat:

• albo twój przycisk jest upośledzony, bo ma zdarzenie Click ale na przykład KeyDown już nie, „bo po co”
• albo twój przycisk zawiera mnóstwo nic nie robiącego kodu, który tylko powiela publiczny interfejs buttona - żeby go odwzorować w całości.

Azarien napisał(a):

Twoje rozwiązanie („kompozycja” jednego buttona) powoduje dylemat:

• albo twój przycisk jest upośledzony, bo ma zdarzenie Click ale na przykład KeyDown już nie, „bo po co”
• albo twój przycisk zawiera mnóstwo nic nie robiącego kodu, który tylko powiela publiczny interfejs buttona - żeby go odwzorować w całości.
  ale od czegos trzeba zaczac :) mam swoje pole z szachownicy ktore jest kompozycja jednego buttona, co nie oznacza ze jest to stan koncowy. co do dylematu - nie widze potrzeby wystawiac typowe dla przycisku property/eventy jesli ich nie potrzebuje albo sa po prostu niepoprawne dla tej kontrolki. gdybym po tym przycisku odziedziczyla to mam do wyboru albo rzucac wyjatki/zjadac subskrybcje/ustawienia property albo liczyc ze ktos nie bedzie chcial uzywac skladowych ktore nie maja sensu.

Ja mam akurat sytuację taką iż w jednym panelu tworze dynamicznie przyciski. Jest ich łącznie 280, lecz w zależności od ustawień wyświetla się mniej więcej od 30 do 45 pod warunkiem iż w danej kategorii są klienci. w przypadku jak nie ma to przyciski się nie tworzą. Do przycisków potrzebuje wrzucić pewne informacje okrojone z 40 zmienych do 4 by przy wyborze zainicjować już konkretną akcję bez nadpisania kontrolki buttona miał bym bardziej skomplikowaną sytuację

class ButtonCategory : Button
    {
        public int idCategory;                              // Id kategori która reperezentujemy
        public string categoryName;                         // Nazwa kategori reprezentowanej
        public int countCustomer;                           // Ilosc klientów w danej kategori przy odpowiednich parametrach kategori perezentowanej
        public int parametrKomornik;                        // Parametr komornik prezentowanej kategori   (parametr otrzymywany z API, nie jest on wykorzystywany nigdzie w aplikacji lecz stanowczo kazali nic nie ruszać oraz iż ma być on przechowywany)

        /// <summary>
        /// Tworzenie przycisku oraz przypisanie jej niezbędnych parametrów
        /// </summary>
        /// <param name="_categoryName">Nazwa</param>
        /// <param name="_countKlientow">Ilosc klientow</param>
        /// <param name="_idKategory">Id kategori</param>
        /// <param name="_parametrKomornik">parametr komornik</param>
        public ButtonCategory(string _categoryName, int _countKlientow, int _idKategory, int _parametrKomornik)
        {                                                                                            
            this.countCustomer = _countKlientow;         // przypisanie
            this.categoryName = _categoryName;           // przypisanie
            this.idCategory = _idKategory;               // przypisanie
            this.parametrKomornik = _parametrKomornik;   // przypisanie
            ConfigButton();                              // Ustawienie profilu przycisku
          
        }

        /// <summary>
        /// Funkcja zarządzająca wizualizacją przycisku
        /// </summary>
        private void ConfigButton()
        {
            
            Content = new TextBlock()                                          // Ustawienie textu na TextBlock dzieki czemu można mieć wiele linijek text w przycisku
            {
                FontSize = 11,                                                 // Ustawienie czcionki
                Text = categoryName + " ( " + countCustomer + " ) ",           // Ustawienie textu na nazwę prezentowanej kategori + "(ilość klientów)"
                TextAlignment = TextAlignment.Center,                          // Ustawienie wysrodkowania
                TextWrapping = TextWrapping.Wrap                               // Ustawienie wapingu

            }; 
            Width = 100;                                                      // Ustawienie szerokości przycisku
            Height = 50;                                                      // Ustawienie wysokości przycisku
            Margin = new Thickness(5, 5, 5, 5);                               // Ustawienie marginesu, żeby przyciski do siebie nie przylegały 
        }
    }
 

To co tutaj jest jest to zlepek 3 kolekcji oraz countCustomer jest to dodanie wybranych grup wiekowych oraz obliczenie z 2 wartości ilość z komornikiem i całkowita ilość. W przypadku wybrania bez komornika z puli 2 grup wiekowych np 231 wycinam ilość z komornikiem 31 i pozostaje mi 200.

Jak ktoś by miał rady jak zrobić takie coś prościej bez takiego nadpisania kontroli. To prosił bym o radę, bo tego nie byłem wstanie zbindować :>

Trochę odkopuje, ale zamiast dziedziczyć możesz też zawsze rozszerzyć klasę Button o swoje własne funkcje, metody np.:

using System;
using System.Drawing;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            var button = new Button();
            b.AdditionalMethod();
            
        }
    }

    public static class ExtendButton
    {
        public static void AdditionalMethod(this Button button)
        {
            MessageBox.Show("Hello from Additional Method!");
        }
    }
}
 

Dzięki temu "dodałem" do klasy Button metodę "AdditionalMethod" i może być ona wywoływana z poziomu Button.AdditionalMethod(), można to wykorzystać jakoś, przy czym właściwości trzeba pisać hmm "manualnie"