the Set_WNDCLASSEX(wndclassex* oClass) function just sends the object into the class which then makes the internal class wndclassex object = what is sent over, so the class sets up 99% of the window creation it just relies upon an external wndproc, as i dont want my window implementation in winmain, i want it in a class.
The pointer to the wndproc seems ok when i debug, i mean its not 0x00000 or 0xc5c5c5c5c, it seems fine and the class registering doesnt give any errors as i said earlier...
The basic window creation goes:
>> Make dummy wndclass and assign it the wndproc function pointer
>> Check what type of renderer is being used (OpenGL/Direct3D)
>> Create a Renderer object or a base window object if no renderer is set (renderers are derived from a base window class)
>> Send dummy &wndclass over to renderer/window object
>> Create the window then display the window, and then any other additional renderering setups...
This final point is where it calls the register class and create window functions and screws up...
Window Message Pump... within a class...??
Quote:Original post by Grofit
...The pointer to the wndproc seems ok when i debug, i mean its not 0x00000 or 0xc5c5c5c5c, it seems fine and the class registering doesnt give any errors as i said earlier...
The pointer to the wndproc may be fine. The problem may be that when you call CreateWindow, your message pump is not ready to forward Windows messages to the appropriate handlers, as it hasn't yet mapped the hwnd to the appropriate class.
When is it failing? During RegisterClass or CreateWindow? If it is CreateWindow, the reason is probably the above. Remember, before the call to CreateWindow is finsihed, Windows will call your WndProc with several messages that your window MUST handle appropriately before CreateWindow gives you the hwnd it HAS ALREADY USED.
ah, so how come the wndproc isnt ready then? i mean normally if it was all within 1 winmain.cpp file you would just declare all the functions and then run through the window creation code, which is what im doing here although they are in 2 different files... so im not sure why its not ready...
Thanks for your help though its appreciated :D
Thanks for your help though its appreciated :D
Use your debugger. It'll point out which line is failing, as well as the state of variables and memory at that execution point.
Thats the thing... i am using the debugger, its failing on the CREATWINDOW(...) line and all the arg fields seem fine, nothing out of the ordinary.. obviously something is wrong or it would work, but nothing that i deem out of the ordinary is visible... all passed args that are needed are pointing to what they are meant to as far as i know..
hWindowInstance, 0x0012fe90
*hWindowInstance, 0x00400000 {unused=9460301}
My hInstance has the above address, thats the only thing that i can think of being out of the ordinary... as it points to something has an "unused" section...
hWindowInstance, 0x0012fe90
*hWindowInstance, 0x00400000 {unused=9460301}
My hInstance has the above address, thats the only thing that i can think of being out of the ordinary... as it points to something has an "unused" section...
Quote:Original post by Grofit
My hInstance has the above address, thats the only thing that i can think of being out of the ordinary... as it points to something has an "unused" section...
That simply means it hasn't been modified over the lifespan of your program.
It's time to post the source. And please, use the ]source] tag.
oh i thought it was the
tag lol<br><br>Well if thats not a problem then i honestly dont know what is the problem, i guess you guys have helpped me as much as you can, i would post the source but its spread out over lots of classes/files and im sure you really cant be arsed reading through it all...
Put a breakpoint at the 'CreateWindow' call line. Execute the program until that breakpoint triggers. Then place a breakpoint at the beginning of your message handler pump / Window procedure. THEN hit F8 (or whatever the equivalent to 'run to next line' is), and THE SECOND BREAKPOINT SHOULD BE TRIGGERED. Then you can find out much more information on exactly what is failing, and you will learn a lot.
(If you are using Dev-C++, you are basically screwed as far as having a good debugging experience, though, as I can't figure out how to reliably make that environment break on breakpoints, unless you step through from 'main'. And the Windows callbacks probably won't trigger the debugger.)
David
(If you are using Dev-C++, you are basically screwed as far as having a good debugging experience, though, as I can't figure out how to reliably make that environment break on breakpoints, unless you step through from 'main'. And the Windows callbacks probably won't trigger the debugger.)
David
hahaha i think ive fixed the problem, i think it was due to the HWND object not being set to *hWindowHandle = new HWND; before being assigned a value...
Quote:Original post by Grofit
hahaha i think ive fixed the problem, i think it was due to the HWND object not being set to *hWindowHandle = new HWND; before being assigned a value...
Why are you dynamically allocating handles?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement