[WIN32>C++] Vraagje ivm static member functies

[Verwijderd]

Ik ben bezig aan een kleine class die het MSN Popup venstertje (idd, dat ranzig blauw ding) nabootst (in C++ met de plain Win32 api)
Nu heb ik een class genaamd CPopupWindow, met daarin een aantal intialisatiefuncties en een Windowproc.

Omdat die windowproc een CALLBACK functie is, moest ik deze static declaren. In de windowproc heb ik echter ook een member variabele nodig, die opslaat welke bitmap als achtergrond te gebruiken. Dit is geen static variabele.
de class is dus dit:

code:

class CPopupNote  
{
public:
    CPopupNote( HINSTANCE hInstance, LPCTSTR szResID );
    virtual ~CPopupNote();

    static BOOL CreateNoteWndClass( HINSTANCE hInstance );
    DWORD WINAPI ShowNote( LPCTSTR lpszMessage );

protected:
    static LRESULT CALLBACK NoteWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
    HWND CreateNoteWindow( LPVOID lpData );


protected:
    HINSTANCE m_hInstance;
    LPCTSTR  m_szNoteBackground;

};

Het probleem is nu echter, dat ik een compile error krijg dat m_hInstance en m_szNoteBackground niet toegankelijk zijn vanuit een static functie. Niks abnormaals. Maar als ik ze dan ook static maak, krijg ik een 'unresolved extrernal symbol' link error.
Dus mijn vraag: Hoe kan ik deze variabelen aanspreken vanuit een static functie? MSDN hielp niet echt veel...

[Orphix]

Nou de member variabelen static maken helpt natuurlijk niet omdat je dan slechts 1 achtergrond kan gebruiken voor alle popups.
Ik heb niet zoveel verstand van de Win32 API. Maar ergens in je class maak je als het goed is een window aan en krijg je een handle voor terug. Deze handle moet je opslaan. Vervolgens zoek je in NoteWndProc door je lijst van pop-ups naar een pop-up die als handle de als parameter meegegeven handle heeft (HWND hWnd).

[Verwijderd]

Op maandag 03 december 2001 20:25 schreef Orphix het volgende:
Nou de member variabelen static maken helpt natuurlijk niet omdat je dan slechts 1 achtergrond kan gebruiken voor alle popups.

Dat maakt niet zoveel uit. Bovendien heb ik de hInstance ook nodig, en die is wel altijd hetzelfde.

Maar ergens in je class maak je als het goed is een window aan en krijg je een handle voor terug. Deze handle moet je opslaan. Vervolgens zoek je in NoteWndProc door je lijst van pop-ups naar een pop-up die als handle de als parameter meegegeven handle heeft (HWND hWnd).


Uhm.. ja.. de code werkte al voorheen, maar nu ben ik hem in classes aan het gieten.
Probleem is dus toegang krijgen tot die (static) variabelen vanuit de static functie.

maar toch bedankt

[farlane]

Een helper functie maken waarbij je je objecten registreert en die de callback functie bevat, en forward naar je objecten?

[Verwijderd]

hmm heb het opgelost op een ietswat vuile manier vind ik.

in de classfile:

code:

extern HINSTANCE hInstance
extern LPCTSTR szNoteback

in de main file:

code:

HINSTANCE hInstance;
LPCTSTR szNoteback;

void Init()
{
 hInstance = .. ;
 szNoteback = MAKEINTRESOURCE( .. );
}

Dit kan ongetwijfeld mooier denk ik toch ?
Iemand nog suggesties ?

[Verwijderd]

Heb dus betere oplossing gevonden
Heb de "this" pointer in de GWL_USERDATA van de window gestopt. Vervolgens deze weer opgevraagd in de WindowProc, en heb op die manier toegang tot de member vars gekregen.
Dit draadje mag dicht voor mij

[Orphix]

Op maandag 03 december 2001 21:18 schreef SpHeaRe het volgende:
Heb dus betere oplossing gevonden
Heb de "this" pointer in de GWL_USERDATA van de window gestopt. Vervolgens deze weer opgevraagd in de WindowProc, en heb op die manier toegang tot de member vars gekregen.
Dit draadje mag dicht voor mij

Dat is dus ongeveer wat ik probeerde duidelijk te maken

[Verwijderd]

Op maandag 03 december 2001 21:48 schreef Orphix het volgende:

[..]

Dat is dus ongeveer wat ik probeerde duidelijk te maken

argh sorry.
Je omschrijving was me niet echt duidelijk

[MSalters]

Op maandag 03 december 2001 21:18 schreef SpHeaRe het volgende:
Heb dus betere oplossing gevonden
Heb de "this" pointer in de GWL_USERDATA van de window gestopt. Vervolgens deze weer opgevraagd in de WindowProc, en heb op die manier toegang tot de member vars gekregen.
Dit draadje mag dicht voor mij

Waarom stop je de member niet gewoon in de GWL_USERDATA?
Scheelt je een dereference.

[Verwijderd]

Op dinsdag 04 december 2001 16:53 schreef MSalters het volgende:

[..]

Waarom stop je de member niet gewoon in de GWL_USERDATA?
Scheelt je een dereference.

Dan kan ik de andere members ook aanspreken.

[The - DDD]

Op maandag 03 december 2001 21:18 schreef SpHeaRe het volgende:
Heb dus betere oplossing gevonden
Heb de "this" pointer in de GWL_USERDATA van de window gestopt. Vervolgens deze weer opgevraagd in de WindowProc, en heb op die manier toegang tot de member vars gekregen.
Dit draadje mag dicht voor mij

Wat in dit geval netter is, is om de windows procedure, geheel los van de class te definiëren.

In de create functie maak je je object aan, dit sla je op met SetWindowLong.

Waarom? Nu kun je alleen nog maar bij de public interface komen van de class. Message handling is iets wat buiten het object valt. Op basis van de messages wordt je object aangestuurd, dat wel.

[farlane]

The - DDD schreef het volgende:
Wat in dit geval netter is, is om de windows procedure, geheel los van de class te definiëren.

In de create functie maak je je object aan, dit sla je op met SetWindowLong.

Een helper functie maken waarbij je je objecten registreert en die de callback functie bevat, en forward naar je objecten?

Hmmm...lijkt dit niet erg veel op elkaar ?

[Verwijderd]

Op dinsdag 04 december 2001 23:08 schreef The - DDD het volgende:
Wat in dit geval netter is, is om de windows procedure, geheel los van de class te definiëren.

In de create functie maak je je object aan, dit sla je op met SetWindowLong.

Zoiets als ditdus (Schaamteloos uit de platform sdk gehaalt, maar altijd handig stukje code om te hebben)

Zelfde truc is ook uit te halen met Threadfuncties waar je de this pointer in de lParam kan dumpen overigens.

[Verwijderd]

Hmm erg interessant allemaal.
Ga ik zeker eens proberen

.edit

Die code (uit het linkje) ziet er idd veel netter uit.
tnx