widzialem tu na forum czesto zadawane pytanie odnosnie subclassowania okna...
wiem ze nie musze zakladac watku na ten temat bo to jest nie ta tematyka i bylo juz poruszane.

aleee.. chce sie podzielic tym co sam zrobilem na potrzeby mojej wtyczki ..
bedzie to na razie jedna klasa tyczy sie ona subclassingu..

prostota wykonania jak i jej uzycia mysle ze nie sprawi nikomu trudnosci w zrozumieniu ...

przyklad uzycia:


class cSubWnd: public cWndEvents
{
public:

//------------------------
//metody
long OnSize(uint resizing, uint nWidth, uint nHeight)
{

//...

// mozemy recznie przekazac parametry do oryginalnej proc. okna
return DefaultProc(_uMsg, _wParam, _lParam);

};

long OnEraseBkgnd(HDC hDC)
{

// zawsze mamy dostep do zmiennych
// _hWnd, _uMsg, _wParam, _lParam

//...

return DefaultProc();

};

public:

//------------------------
//konstruktor
cSubWnd()
{

// tu gdzies pobieramy sobie uchwyt do subclass-owanego okna
// hWnd

// przychwytujemy komunikaty trafiajace do okna
GetWndProc(hWnd, true);

};

//------------------------
//destruktor
~cSubWnd()
{

// konczymy subclass-owanie
EndSubClass();

};

};


mysle ze kazdy jesli ma jakies uwagi badz chce cos dodac, poprawic w tej klasie lub chce sie
podzielic wlasnymi kawalkami kodow niech wkleja tutaj w tym watku...
Gotowe pliki z funkcjami / klasami do uzycia...
Czekam na pomysly i propozycje...

w niedalekiej przyszlosci bede dodawal tego typu pliki do tego tematu zeby kazdy mogl
wykorzystac to co wypocilem

Kliknij, aby zobaczyć załącznik (subclass.rar)

Ja pozostanę jednak przy subclassowaniu nie obiektowym

(Nie wiem czy moja opinia z programistycznego punktu widzenia jest najlepsza, ale takie wnioski nasuwają mi się po zsubclassowaniu jakiejś ilości okien)

Fajnie by było aby dodawanie nowych eventów polegało na czymś w stylu Subclass.RegisterEvent(WM_NOTIFY, Namespace::MojaProcedura); - wtedy IMO byłoby dużo łatwiej, bez zmian w kodzie klasy Te komunikaty które w swoim kodzie subclassujesz mają się nijak do tych obsługiwanych przez np. tabletKę czy temaciKa czy k.Lawę czy potrzebnych innym programistom. Powinna być możliwość również rezygnacji z otrzymywania danych komunikatów. Wadą mojego rozwiązania jest zrzucanie obowiązku castowania parametrów do odpowiednich typów i struktur na końcowego programistę - coś za coś...

Inna ważna sprawa, jedna instancja klasy powinna być w stanie subclassować wiele okien, i tu ważna uwaga - każde z tych okien mogło mieć inną procedurę przy subclassowaniu (ja takie informacje przechowuje poprzez użyty tu SetProp/GetProp). Tutaj również poza funkcją uruchamiającą przechwytywanie komunikatów powinna być funkcja wyrejestrowująca. Oczywiście klasa domyślnie musiałaby przechwytywać WM_DESTROY, aby usunąć zbędny wpis z tablicy z subclassowanymi oknami.

Na razie to chyba tyle z mojej strony.

Wiec tak

1. klasa cWndEvents jak najbardziej jest rozszerzalna to jest wstepna ilosc obsluzonych komunikatow.
W miare czasu ta klasa bedzie poszerzana o pozostale komunikaty. Nawet wskazane byloby gdyby ktos sobie
dodawal do tej klasy i tu np uaktualnia ta klase.

2. jest tam tez taka metoda jak OnExtEvents(); ktora jest jakgdyby uzupelnieniem na wypadek gdyby
jakis komunikat nie zostal uwzgledniony w tej klasie. Nalezy w swojej klasie dziedziczacej uwzglednic ta
metode i wypelnic ja obsluga jakiegos komunikatu. Wiec samemu mozna zrobic tak:
switch(_uMsg)
{
case WM_DUPA:
{
//...
}
return DefaultProc();
};
i w tym miejscu juz mamy obsluzony wyjatkowy komunikat ktorego w tej klasie nie ma

3. Klasa cSubClass wykorzystuje dwie metody subclassowania "nowsza / starsza" na temat
mozliwosci nowego subclass-owania mozna poczytac w MSDN - Subclassing Controls. Metoda
GetWndProc(HWND hWnd, bool NewStyle) posiada wybor stylu subclass-owania.

4. Mozna wogole nie kozystac z klasy cWndEvents (ktora jest tylko dla uproszczenia obslugi
komunikatow) a odrazu odziedziczyc po klasie cSubClass i bawic sie po swojemy nie troszczac
sie o obsluge funkcji subclass-ujacych.

5. W klasie z obsluga "starego" typu subclass-owania jest uzyte wszystko to o czym mowisz
SetProp(_hWnd, "this", this); GetProp(hWnd, "this"); RemoveProp(_hWnd, "this");. Oczywiscie mozna
dodac opcje wyboru nazwy ustawianej wlasciwosci. Mozna przekazywac rowniez do funkcji paramter
w inny sposob (nie polecam ):
SetWindowLong(hWnd, GWL_USERDATA, /*jakis parametr do przekazania - u nas wskaznik this*/);
/*pobieramy parametr - u nas wskaznik this*/ = GetWindowLong(hWnd, GWL_USERDATA);

6. Z tego co sie orientuje to nie ma raczej mozliwosci subclass-owac tylko wybrane komunikaty.
Jesli cos jest subclass-owane to utrzymujemy wszystkie komunikaty i aby pozbyc sie ich obslugi jedynie
mozemy zwrocic ich obsluge wlascicielowi - wykonuje sie to wlasnie w jeden ze sposobow:
DefSubclassProc(hWnd, uMsg, wParam, lParam);
CallWindowProc(OldWndProc, hWnd, uMsg, wParam, lParam);

w mojej klasie jest to metoda DefaultProc

7. Kazde subclass-owane okno mozna przedstawic jako oddzielny obiekt, badz wszystkie subclasowane
okna jako jeden obiekt - to jest kwestia juz tylko dalszej implementacji korzystajcego z TEJ klasy.
przykladem na takie rozwiazanie jest moja wtyczka Tłok ktora w tej chwili subclass-uje glowne okno
i subclass-uje ListView-a i te dwa subclassowane okna sa widziane jako jeden obiekt - co ulatwia mi
operowanie na wyswietlanych obrazkach.

Na koniec tego wywodu dla programujacych nie wtajemniczonych ... klasa cSubClass i cWndEvents sa klasami bazowymi po nalezy dziedziczyc. Stad tyle nie jasnosci - tak mysle

pozdrawiam...
p.s. pewnie o czyms zapomnialem napisac ale to sie pozniej okaze...

Olórin ma rację. Łatwiej jest jeśli odpowiednie komunikaty są przekazywane wprost do podanej metody użytkownika. Ja mam tak zrobioną klasę ListBox w kAPI. Nie rozumiem tylko o co mu chodzi z tym "zmusaniem do rzutowania". Programista i tak by musiał rzutować. W przypadku mojego listBoxa jest o tyle lepiej ze tworzac klase wiem jakie parametry beda potrzebne w metodzie i programista w ogole nie musi niczego rzutować.

Najbardziej mi się nie podoba to:

Jak to "gdzies pobieramy". Uchwyt ten nie powinien byc przekazywany do konstruktora?

Poza tym czytajać to co napisałeś nie mam pojecia co robi, do czego sluzy, w czym moze mi pomoć twoja klasa. Poza informacja ze sluzy do subklasowania.


Nie wiem czy to dobre podejscie


No i wlasnie o to chodzi by ta klasa potrafila oddzielic takie komunikaty. Ty mowisz ze chcesz odbierac ten a ten i tylko takie dostajesz. Pozniej mozesz powiedziec a nie dzieki juz nie chce byc informowany. Cos na styl tego co napisalem w temacie "Lista zyczen do nowego API"

przeciez wlasnie tak jest ... nie wiem o co chodzi ???
jesli chcesz dostawac wszystkie komunikaty do jednej metody to juz jest tak zrobione dziedziczysz po klasie cSubClass i w swojej klasie jakies tam nazywasz metode long SubWndProc() i dostajesz wszystkie
komunikaty co dane okno dostaje.




dowolnosc twoja czy bedzie przekazany do konastruktora czy nie bedzie przekazany do konstruktora
czy poprosty uchwyt poprostu sobie wpiszesz sztywno.

ja chyba zaczynam rozumiec w czym problem przejzyjcie dokladnie zrodla..
Klasy cSubClass nigdy juz nie ruszamy jest to klasa bazowa wszystko co chcesz robic rob w swojej jakies tam klasie ktora wlasnie bedzie dziedziczyla po mojej klasie... i o to w tym chodzi ze nie trzeba powielac kodu.



mysle ze nie bede powielal tego co napisalem wczesniej tylko dodam pare wskazowek co do metod i naglowka klasy.
wiec tak:

klasa cSubClass:
virtual long SubWndProc() = 0; - ta procedura zawsze dostaje komunikaty wszystkie ktore powinny trafic do okna
virtual void GetWndProc(HWND hWnd, bool NewStyle); - wywolanie tej metody rozpoczyna subclass-owanie danego okna - wiec od tej pory wszystkie komunikaty ktore trafiaja do okna mozemy wylapac w metodzie
SubWndProc
virtual void EndSubClass(); - wywolanie metody powoduje zakonczenie subclass-owania czyli juz zaden komunikat nie powinien zablakac sie w naszej metodzie SubWndProc
virtual long DefaultProc(); - wywolanie tej metody przekaze obsluge do "oryginalnego" okna. z parametrami takimi jak przyszly do procedury
virtual long DefaultProc(UINT uMsg, WPARAM wParam, LPARAM lParam); - metoda jest identyczna z ta u gory z tym ze mozna przekazac wlasne paramtry do "oryginalnego" okna

klasa cWndEvents:
wogole ta klasa juz dziedziczy po klasie cSubClass wszystko co bylo tym jest dostepne w tej klasie.

klasa cWndEvents zawiera metody np.:
virtual long OnNotifyFormat(HWND hwndFrom, uint Command);
virtual long OnPaint();
virtual long OnSize(uint resizing, uint nWidth, uint nHeight);
virtual long OnVScroll(uint sbThumb, uint CurrPos);

a ty w swojej klasie wykozystujesz tylko metody
long OnPaint();
long OnVScroll(uint sbThumb, uint CurrPos);
i tak wlasnie jest ze reszta ktorych nie uzywasz w swojej klasie zostanie obsluzona automatycznie w klasie
cWndEvents




ja inego podejscia nie znam w projektowaniu obiektowym ???'
moze ktos mi przedstawi ...



wlasnie to robi klasa cWndEvents tylko nalezy ja wzbogacic o obsluge kolejnych komunikatow
i bedzie "prawie" uniwersalna. do kazdego zastosowania. Po to ona jest.. zebys mogl tylko kozystac z
jednego komunikatu w jednej metodzie. Reszty komunikatow nie musisz dostawac bo zostana obsluzone przez
ta klase...



Wiem juz chyba o co biega chodzi o wyodrebnienie tylko odpowiednich komunikatow przekazywanych do procedury otrzymujacej komunikaty... jest do zrobienia ale nie taki zamiar byl tej klasy. ja poszedlem o krok
dalej ... czyli dziedziczysz metody ktore chcesz i juz masz gotowe paramtery w nich przekazywane
nic nie musisz robic masz gotowa metode zostanie wywolana wtedy kiedy potrzeba i z odpowiednio przygotowanymi
argumentami.
Ale to moge zrobic.. w tej klasie nie ma problemu

Chyba ci chodzi o przesłonięcie moetod a ine ich dziedziczenie

Trzeba by było się nieco zagłębić w to co ta klasa potrafi zeby moc ja ocenic. Lecz nie o tym chcialem. Pytanie mi sie takie pojawilo: "do czego bede uzywal tej klasy". Zbyt wielu okien, ktore moglbym subklasowac i rownoczesnie miec z tego jakies korzysci, nie ma w Konnekcie.

Napewno klasa bedzie pomocna dla osob ktore jednak beda chcialy subklasowac jakies okno.

W moim odczuciu takie coś byłoby równoznaczne z zrobieniem switch'a i zamiast bezpośrednio obsługiwać komunikaty, to wywoływać osobne dla nich funkcje...

Przejrzałem kod i kilka moich spostrzeżeń:
1. Dlaczego declarujesz dwie klasy w jednym pliku nagłówkowym jak rownież je definiujesz w jednym .cpp
2. Dlaczego używasz dyrektywy #pragma zamiast #ifdef, które zadziała na każdym kompilaotrze poprawnie
3. Uzycia #pragma w pliku .cpp nie rozumiem
4. Do czego jest ci naglowek "commctrl"?
5. Brak opisów metod - normalnie sie gubie co do czego sluzy
6. Osobiscie nie lubie kontstrukcji "if(_this)"
7. Klasa nie zadziała (moim zdaniem) dla wtyczek wielowątkowych

Jak to jest z tym subklasowaniem kilku okien przez jeden obiekt bo nie moge do tego dojsc.

Nie wspomne o tych obrzydliwie wielkich komentarzach

4. CommCtrl jest potrzebny do "nowszej" metody subclassowania...

Aha czyli strzelam ze nie jest on potrzebny w pliku naglowkowym.

tak na prawde to sa metody polimorficzne a nie przeslanianie sie to jest zupelnie cos innego, a dla uproszczenia podalem ze sie dziedziczy


do subclass-owania okien tylko i wylacznie.


moze bedzie pomocna


ad 1. bo tematyka tych klas jest taka sama. (wogole co za pytanie ??)
ad 2. tak mi jest wygodniej i nie znam innych kompilatorow. (co to za pytanie ??)
ad 3. pragma #once chodzi o pojedyncze wykorzystanie pliku. uzywasz dyrektyf kompilatora tam gdzie chcesz osiagnac dany cel.
ad 4. Olórin juz wyjasnil.
ad 5. ????????????? przeciez juz tutaj napisale 1000 razy co do czego sluzy ?? (nie rozumiem pytania ??)
ad 6. ja nie lubie wielu rzeczy. Zazwyczaj jak mi sie nie podoba staram sie zmienic.. (o co chodzi temu panu ??)
ad 7. trzeba sprawdzic pozniej sadzic


nalezy wiecej czytac na temat samego jezyka (C++) i wetedy wszystko bedzie jasne. projektowac wiecej systemow obiektowych i nie powinno byc problemow.


sa tylko po to aby bylo przejzyscie... i nie dla mnie ona sa


tak na marginesie to nie jest konkurs na najpiekniejszy KOD i nie taki byl moj zamiar chce pomoc jak komus sie przyda to bedzie fajnie jesli nie to tez fajnie widocznie znalazl leszpy sposob. Widze ze sa tu jakies dziwne uszczypliwe komentarze.. jesli tak pozostanie to poprosze o zlikwidowanie tego watku...
rozumiem krytyke ale tylko wtedy jesli kogos obraza to co robie....


strasznie zle strzelasz.. to nie jest strzelnica... i widze ze tym samym tokiem myslenia kierujesz sie w pozostalych pytaniach.. pomysl pozniej: pytaj, sadz, oceniaj i twierdz. ok ??


pozdro

juz dopisalem funkcje ktore to rozwiazuja o czym mowa...
UINT RcvMsg - zmienna przyjmuje sume logiczna komunikatow ktore maja byc obslugiwane przez uzytkownika (maska) - mozna pobierac wartosc jak i ustawiac - alternatywa jest: SetReceiveMsg i GetReceiveMsg.
void AddReceiveMsg(UINT uMsg); - dodaje do juz istniejacej maski komunikatow dodatkowy komunikat
void SubReceiveMsg(UINT uMsg); - odejmuje komunikat od istniejacej maski komunikatow

standardowo na starcie jest ustawione tak ze obslugujemy kazdy komunikat.

Nie watpliwie te metody sa polimorficzne i niewatpliwie przeslanianie to co innego ale nie z tego wzgledu co ty uwazasz. Funkcja moze byc (jaka?) polimorficzna i moze być (co robiona?) przesłoniona (zasłoniona). Jeśli programista chce skorzystać z twojej metody to ona musi być polimorficzna a programista musi ja przesłonić nie spolimorfizmować i nie odziedziczyć. Metod się nie dziedziczy, dziedziczy sie funkcjonalność po obiekcie. Nie możesz wybrać ze sobie odziedzicze tą metodę a tamtej nie. To tak dla "uproszczenia".


To ze ona jest do subklasowania to sie zgadzam. Tylko, że wtyczki ine potrzebują z reguły subklasować okien. To była taka luźna aluzja. W połączeniu z tym że w plikach nie ma komentarzy co dana metoda robi programiscie ciężko będzie użyć owych klas i predzej sam będzie subklasował po staremu. Chyba nie karzesz mu przegladać forum gdzie opisałęś mtody w 3 postach i to nie wszystkie.



ad 1. A co mnie obchodzi tematyka. Jak bede chcial uzyc tylko klasy bazowej to mam tez dolaczanczac drugą klasę. Jak stworzysz 10 nowych klas to tez je dolaczysz do jednego pliku bo maja te sama tematyke? Jak pozniej zmienisz jedno pole w klasie to ja bede musial rekompilowac swoja wtyczke bo ty umiesciles wszystkie klasy w jednym pika a ja nawet tej klasy nie uzywalem? A nawet jesli uzywalem beda musialy sie przekompilowac wszystkie podzespoly bo wszystkie korzystaly z jednego pliku?

ad 2. Tak ci wygodinej. To jesli te klasy robisz dla siebie to czemu je udostepniasz? Ktos uzyje ty pozniej zmienisz i programista bedzie mial klopot. Ty nie znasz a moze ktos bedzie chcial skompilowac w inym srodowisku. Poza tym w standardzie nie ma czegos takiego jak #pragma once

ad 3. No ja wiem do czego sluzy pragma. Widziales gdzies zeby ktokolwiek dolaczal plik CPP wiecej niz jeden raz? Plikow CPP sie nie dołącza (includuje).

ad 4. No i skladam podizekowania Olórinowi bo mnie to ciekawilo.

ad 5. Nie tysiac razy tylko po razie dla metody w kilku kolejnych postach. Do tego nie wszystkie metody zostaly opisane. Czlowiek nie będzie latał non stop na forum sprawdzać a jak neta nie będzie miał. Poza tym jak byś opisał to by środowisko podpowiadało do czego ona służy.

ad 6. Nie powinno sie używać takich konstrukcji bo łatwo jest popełnic w takich momentach bład, przyjelo sie ze tak sie nie zapisuje, zle sie takie cos czyta. Dlatego w nowszych jeszykach zabroniono stosowania takich konstrukcji. A jak byś chcial wstawic zaprzeczenie to piszesz "if( !_this )"? (spoko mozesz mi mowic na Ty)

ad 7. Ja jestem prawie pewien. Nie powiem pewien bo tak jak mowisz trzeba by bylo sprawdzic. Nie moge rowniez dowiesc bo jak juz mowilem troche sie gubie. Ale takie zalozenie, jesli jeden watek uzyje takiego obiektu a dokladnie metody PreSubclassProc, ktora zostanie wywlaszczona po "long ret;" i kolejny watek rowniez wywola ta metode to co sie stanie?


Dzieki za dobre rady. Z ciekawosci, ile ty systemow obiektowych zaprojektowales?


Czy ktos tu oczekuje by ten kod był piękny? Mylisz sie. Prosze mi wskazać te uszczypliwe komentarze.


Ze jak? Najpierw musisz mnie obrazic dopiero potem moge krytykowac?


Po raz kolejny dziekuje ci za dobra rade, postaram sie wiecej myslec. O tn plik naglowkowy sie pytalem bo nigdy go nie uzywalem i bylem ciekaw do czego jest potrzebny. Skoro jest potrzebny prosze, wskaz mi to miejsce. Naprawde jestem ciekaw.


To w koncu ty zapraszasz do tej dyskusji czy nie? Bo ja juz nie wiem. Chcialem tylko pomoc i wskazac kilka bledow moim zdaniem.

Jak macie sie kłocić o wyższości stylów programowania to won na pm!

P.S.
Pomysł Triala podoba mi się jak będę miał czas to może coś tam dorzucę, bo nasunęło mi się kilka pomysłów ;]

Kosiarz, czepiasz się

W Stamina.lib jest zaczątek klasy Window, w której gdzieś po drodze z pewnością przydałaby się taka funkcjonalność... Wasze doświadczenia niewątpliwie się przydadzą.

tak na wstepie krociotko.
staram sie opisywac problem tak jak potrafie i jak najprosciej, wiec jesli wynikaja jakies sprzeczki to tylko z braku zrozumienia. Zeby wszystko bylo jasne TO NIE JEST PROJEKT to jest moj kawalek kodu ktorym chce sie podzielic. Jesli ktos bedzie chcial to moze go pokroic i zrobic z nim cuda jesli tylko zechce. Wiec tu zaden statndard nie bedzie budowany. Odnosnie wszystki uzytych styli pisania wlacznie z komentarzami to poprostu mam taki styl blizej nie uzasadniony, czesto wynikajacy z przyzwyczajen, i doswiadczenia innych.


1. Klasy mozna podzielic na oddzielne pliki.
2. Dalszym rozwiazaniem jest stworzyc tyle klas ile jest "okien", poprostu zrobic klase tylko do Button-a, Static-a itd.
3. Mozna rozdzielic klase cSubClass na dwie oddzielne z nowym stylem subclassowania i starym stylem, bedzie moze nawet lepiej no i kodu mniej. pomysle nad tym.

jesli ktos ma pomysl na ROZBUDOWE klasy niech sie wypowie mi ona w takiej postaci w zupelnosci wystarcza, wiec reszte funkcjonalnosci mozna dorobic na wasze zyczenie.
w miare mozliwosci i przyplywu czasu opisze wiecej w samym kodzie wiecej komentarzy zeby bylo jasne.

na zakonczenie dla jasnosci:
SetWindowSubclass(hWnd, pfnSubclass, uIdSubclass, dwRefData);
GetWindowSubclass(hWnd, pfnSubclass, uIdSubclass, *pdwRefData);
DefSubclassProc(hWnd, uMsg, WPARAM, LPARAM);
RemoveWindowSubclass(hWnd, pfnSubclass, uIdSubclass);

sa zamieszczone w naglowku: commctrl.h