yay! new thread about classes

the other thread was getting off track and old, and i solved the problem anyway, so now im posting a new problem.

this is really weird, because it seems to work perfectly in another project i have, and the code is basically the same, but it suddenly doesn't work here. observe:

Code:

---

class cBen
{
public:
    int left,top,width,height;
   
    HWND hApp; 
    void MoveLeft();
};

void cBen::MoveLeft()
{
    if (left>=50)
        left-=50;

    SetWindowPos(hApp,NULL,left,top,width,height,SWP_NOOWNERZORDER);
}

---

in the MoveLeft() function, none of the data members seem to be in scope. why is this so? here is the other code, where it works.

Code:

---

class tagMap
{
public:
        BYTE *datMap;
        BYTE get(int x,int y);
        void set(int x,int y,BYTE value);
        int width;
        int height;
};

BYTE tagMap::get(int x,int y)
{
        return datMap[(y*width)+x];
}

void tagMap::set(int x,int y,BYTE value)
{
        datMap[(y*width)+x]=value;
}

---

basically, the two classes are the same in the way they access data members. how come one works and the other doesn't?

For a start in your cBen class, I see no point where you initally set the variables....

thats because i haven't included all the code. trust me, they're all initialized.

i think i have the answer to all my problems. what is happening is, an instance of cBen is being made in a different file. that means that the class definition file is out of scope. if i can work out how to counteract this problem, then i can declare that bastard window procedure non-static, and have an end to this misery.

please tell me im right

I cant see what relevance a window procedure has here?....you create an object.....then memory is set asside for each member variable of that object (as defined by the class for that object)...set the values of those variables.......and the member functions have access to those variables.....file scope is of little importance when you have created the object as its variable reside in memory (as long as the destructor is not called)

Digressing to window procedures....your func has to be a normal global function, or a static member function.....the reason is that a non-static class function needs the object to be created before being called, and requires a copy of the "this" pointer to operate.....as the WindowProc is a callback, it doesnt care about such matters...therefore the compiler wont allow it

i dont understand why a window procedure that is a member function of a class has to be static. i mean, isn't a copy made when a instance of the class is created? why should there need to be one static window procedure for every instance of that class?

Quote:

---

Originally posted by bennyandthejets
i dont understand why a window procedure that is a member function of a class has to be static. i mean, isn't a copy made when a instance of the class is created? why should there need to be one static window procedure for every instance of that class?

---

That's the thing...the system calls the WndProc...not you...and the system doesnt care if you have or havent got around to creating an instance of an object...also, the system has no idea of the this pointer for a class....so cannot provide it when it need to call the WndProc

A static member function is callable from before WinMain is called and stays in a usable state right to the point where WinMain ends....Only 1 static member function exists in code at 1 time....so that function is not duplicated in the code - just what the system needs for a callback

okay, so that explains why you can only call static data members from a static member function, because the this pointer isn't there, so there's no way to access the class. but static data members are always there, so it is easy to call them.

well, what a letdown.

now, back to the original problem, why aren't those variables in scope in one project, but they are in another? look to the very first post for the code.