• Advertisement
Sign in to follow this  

Stupid windows... or stupid me?

This topic is 4553 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi Usually this isn't the kind of question i'd ask on here - but I have done my homework on this and its still causing me grief: I have my engine as a static lib, and my game built on top as another project linking to the lib creating the exe. The problem I have is creating the actual window (im using CWindow). Now for the first few months I had no problem whatsoever with creating a window for my app. Then suddenly the window creation routine failed returning ERROR_INVALID_HANDLE - and I mean suddenly without changing any code in that area. Nothing I did would fix the problem, and getting desperate I moved the window creation code into another area of the program - and bingo with no apparent reason it worked fine... for about 2 weeks. Here's the crazy part: I next moved it back to the original section and it worked again. After moving it back and forth over a couple of months it finally stopped working anywhere. Has anyone else come across an issue like this - or is it something obvious? I'd really like to know why this might be happening - or even any of the reasons for CWindow.create() returning ERROR_INVALID_HANDLE (CreateWindow does the same thing). Any help greatly appreciated thanks for reading =)

Share this post


Link to post
Share on other sites
Advertisement
Show us some code - your window creation routine and the code that seems to mess it all up...

Yeah - Windows programming is hell and everyone who can program in Win32 knows it. [rolleyes]

Oxyd

Share this post


Link to post
Share on other sites
Well i've been programming win32 for quite a while now - but this has never happened to me before =(

anyway - for reference:

class registration...

WNDCLASSEX newClass;
newClass.cbSize = sizeof(WNDCLASSEX);
newClass.style = CS_VREDRAW | CS_HREDRAW;
newClass.hCursor = LoadCursor(0,IDC_ARROW);
newClass.hIcon = LoadIcon( app->instance(),MAKEINTRESOURCE(102));
newClass.hIconSm = NULL;
newClass.lpszMenuName = NULL;
char nClassName[128];
strcpy(nClassName,app->name().c_str());
newClass.lpszClassName = nClassName;
newClass.hbrBackground = NULL;
newClass.hInstance = app->instance();
newClass.lpfnWndProc = app->windowMessageHandler();
newClass.cbClsExtra = 0;
newClass.cbWndExtra = 0;

app->_winClass = RegisterClassEx(&newClass);
if (!app->_winClass)
{
fatalError("_registerClass - window-class not registered");
}



and window creation...

_window.Create( (LPCSTR)_winClass, NULL, CRect(0,0,100,100), app->name().c_str() );

if (!_window.m_hWnd)
{
cprintf("%d", (int)GetLastError());
seriousError("createWindow - window creation/attachment failed");
}



Anyway is there any way its something to do with the fact that the window creation is in a seperate linked-library?

Share this post


Link to post
Share on other sites
a) Scope: Well I would think that the data stored in the structure is copied to some internal memory structure within the API after the call to RegisterClassEx() - but I'm not ruling it out. I would think that I would be getting errors constantly if that were the case - and at the moment its functioning perfectly again.

b) Well I would agree except for the fact that right now its working again. I'm sure it'll stop though in a couple of weeks =(

One thing I didn't make clear: The compiled app either works every time without fail, or the window creation function never succeeds. Usually errors due to corrupt/invalid memory are intermittent - this type of error situation is extremely odd.

Please keep your ideas coming though I'll take any input at the moment, thanks =)

Share this post


Link to post
Share on other sites
Quote:
Original post by Source
Well I would think that the data stored in the structure is copied to some internal memory structure within the API after the call to RegisterClassEx()

Sorry, you're right. I checked.

Share this post


Link to post
Share on other sites
Quote:
Original post by Source
Anyway is there any way its something to do with the fact that the window creation is in a seperate linked-library?


Probably not, although maybe if the library is out of date (However I don't think Visual C++ is that stupid). In other words, make[1] sure you have your dependencies set up. Delete the temporary files (.lib,.obj or .a,.o) and rebuild them.

There's nothing wrong with the actual class creation code. Are you sure the function that registers the class is actually called? In any case, try using the class name instead of the ATOM as the first parameter when calling CWindow::Create.

Quote:
Original post by Konfusius
You're passing a member function to the WNDCLASS. I don't believe that's possible.


No he isn't - all we can see from the source is that he's passing app->windowMessageHandler(), which could return any type of function, probably a static member function which is allowed. As he says, it does work some of the time.

Footnotes


[1][lol] har har funny joke.

Share this post


Link to post
Share on other sites
Yer the first thing I did when the problem arose is to do a complete rebuild for all libraries and the main app (and they are in correct dependancy order).

Yes its a static member function:



WNDPROC windowMessageHandler(void) { return (WNDPROC) _processMessage; }

//and...

static LONG CALLBACK _processMessage( HWND,UINT,WPARAM,LPARAM,bool );





Like I said, it works fine for a while, then stops working until I rearrange it, then it works again for a while - until it stops working - then I put it back to the original place and it works again. Very, very odd. Not sure if this one is going to get solved.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Are you using pre compiled header files?

Sometimes they can be very picky like this and you have to order your headers just right.

Also if you use static member data in an object it can be picky of where it is actually initialized. Either in the header or in the cpp file. If you are initializing in the cpp file if you dont place it inside a:

#ifndef _somename_
//code here
#define _somename_
#endif

then you might get errors like this.
I remeber getting weird errors like this myself. Mind you they wernt ones that swapped two weeks apart.( now THAT is werid )

Have a close look at where you define your code and test test test differnt builds, even if the change is only moving an include or define down two lines or something. It can make a diffreence sometimes.

Share this post


Link to post
Share on other sites
Code doesn't just mysteriously break when you copy&paste it - Something else breaks it. He probably has different includes in one spot than another. Also, that underscore-lowercaseletter identifier is bad. It would not surprise me if _processMessage is a name used in the win32 implementation. Like most of the API, it is probably a define that transforms it to _processMessageA. In a file that includes windows.h, it would be translated to this other function. In one that didn't, it wouldn't. Get rid of the underscore anyway, and change the name of the function. If it works, then what I said is right. If it doesn't, your code is better anyway.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement