windowsEnumProc

[dave2k]

i am trying to enumerate windows, but get the following error - why is this? is it because i am using a class?

#include "StdAfx.h"
#include ".\window.h"

bool Window::Findf(string wText){
windowText = wText;
EnumWindows(Finder, NULL);
return windowText.length() ? true : false;
}

// find the poker window
BOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
char title[500];
GetWindowText(hWnd, title, sizeof(title));

if(strstr(title, windowText.c_str()))
{
hwnd = hWnd;
return FALSE;
}
return TRUE;
}

error:error C2664: 'EnumWindows' : cannot convert parameter 1 from 'BOOL (HWND,LPARAM)' to 'WNDENUMPROC'


i thought about making the method static, but then i cannot set variables within the class i.e. hwnd, from within the static method.

cheers

[Marc G]

Yes, your finder function should be static.
You can do something like this:
EnumWindows(Finder, this);
...

BOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
Window* w = (Window*)lParam;
....
}
The second parameter to EnumWindows is passed as lParam to your Finder function.

[golanshahar]

follow Marc suggestion just one thing though you will need to do little cast here:

::EnumWindows(Finder, (LPARAM)this);


Cheers

[dave2k]

cheers, but i triedBOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
Window* w = (Window*)lParam;
char title[500];
GetWindowText(hWnd, title, sizeof(title));

if(strstr(title, w.windowText.c_str()))
{
w.hwnd = hWnd;
return FALSE;
}

return TRUE;
}

but it doesn't work, with errors like error C2228: left of '.c_str' must have class/struct/union type


why is this?

[NoHero]

cheers, but i triedBOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
Window* w = (Window*)lParam;
char title[500];
GetWindowText(hWnd, title, sizeof(title));

if(strstr(title, w.windowText.c_str()))
{
w.hwnd = hWnd;
return FALSE;
}

return TRUE;
}

but it doesn't work, with errors like error C2228: left of '.c_str' must have class/struct/union type


why is this?


You should show us the include and the source for the class Window. Are you including the namespace std?

[dave2k]

do i have to use -> instead of . if it's a pointer?

[golanshahar]

do i have to use -> instead of . if it's a pointer?

YES w is pointer! you must use w->windowText.

and make sure that the std::string windowText you declared is in the public section of your class.

Cheers

[NoHero]

and make sure that the std::string windowText you declared is in the public section of your class.

Any static method of a class can access the private data members of its own class through an instance.

#include <iostream>
#include <string>

class Foo
{
private:
std::string blah;

public:

static void bar ( const Foo &obj )
{
std::cout << obj.blah.c_str() << std::endl; // No problem
}

public:

Foo ( void ):blah("hello, world"){}
~Foo ( void ) {}
};

int main ( void )
{
Foo foo;
Foo::bar(foo);
return 0;
}

[golanshahar]

Any static method of a class can access the private data members of its own class through an instance.

#include <iostream>
#include <string>

class Foo
{
private:
std::string blah;

public:

static void bar ( const Foo &obj )
{
std::cout << obj.blah.c_str() << std::endl; // No problem
}

public:

Foo ( void ):blah("hello, world"){}
~Foo ( void ) {}
};

int main ( void )
{
Foo foo;
Foo::bar(foo);
return 0;
}

yes its true, but this is not the case here. look at the code OP posted:


BOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
Window* w = (Window*)lParam;
char title[500];
GetWindowText(hWnd, title, sizeof(title));

if(strstr(title, w.windowText.c_str()))
{
w.hwnd = hWnd;
return FALSE;
}

return TRUE;
}


he has a std::string member varaible and try to access it with a pointer to the class, that means if this variable will be private, it wont work for him in the way he uses it.
:wave:


Cheers

[NoHero]

BOOL CALLBACK Window::Finder(HWND hWnd, LPARAM lParam)
{
Window* w = (Window*)lParam;
char title[500];
GetWindowText(hWnd, title, sizeof(title));

if(strstr(title, w.windowText.c_str()))
{
w.hwnd = hWnd;
return FALSE;
}

return TRUE;
}


He is in the same namespace (class Window::) and is accessing a private data member of it's own class via an instance from a static method. And this works regardless of pointer or not:

#include <iostream>
#include <string>

class Foo
{
private:
std::string blah;

public:

static void bar ( const void *arg )
{
Foo *obj = (Foo*)arg;
std::cout << obj->blah.c_str() << std::endl; // No problem
}

public:

Foo ( void ):blah("hello, world"){}
~Foo ( void ) {}
};

int main ( void )
{
Foo foo;
Foo::bar(&foo);
return 0;
}

Is the same and it works fine. Try it...

[golanshahar]

He is in the same namespace (class Window::) and is accessing a private data member of it's own class via an instance from a static method. And this works regardless of pointer or not:

#include <iostream>
#include <string>

class Foo
{
private:
std::string blah;

public:

static void bar ( const void *arg )
{
Foo *obj = (Foo*)arg;
std::cout << obj->blah.c_str() << std::endl; // No problem
}

public:

Foo ( void ):blah("hello, world"){}
~Foo ( void ) {}
};

int main ( void )
{
Foo foo;
Foo::bar(&foo);
return 0;
}

Is the same and it works fine. Try it...

oh sorry, its not what i wanted to quote :blush:

what i meant was if he will using the function ( finder ) as global like Marc suggested then the variable should be public. :)

if its a member function then of course you are right there is not an arrgue here.

Cheers

[NoHero]

what i meant was if he will using the function ( finder ) as global like Marc suggested then the variable should be public. :)

Making data members public (variables on public scope are always public - so I assume you are talking of a class' data member) is a such a thing... basically it hurts the encapsulate idiom of OOP. Just my two cents on this. ;)

[golanshahar]

Making data members public (variables on public scope are always public - so I assume you are talking of a class' data member)

Yes :)


basically it hurts the encapsulate idiom of OOP.


you are right i am not saying its the way it should be done i just pointed it out since i saw how OP wrote his code.

Cheers

[NoHero]

you are right i am not saying its the way it should be done i just pointed it out since i saw how OP wrote his code.

Yes... Although I believe its our duty not to answer the questions, also to encourage the OP's to use and follow better patterns and designs... ;)