If you're getting an exception on a member function call from an interface pointer, there's a good change your pointer doesn't actually point to anything. The easiest way to check this is use the debugger to have a peek at what the value of your interface pointer is. In Visual C++, this means just breaking into the debugger when the exception is caught (click retry) and the putting your mouse over the pointer to see its value. In debug builds, uninitialized variables are typically given a value of 0xcccccccc.

And as for destroying your window, use DestroyWindow instead. It does a bit more than just posting a WM_DESTROY message.

EDIT: one more thing...if you're posting long bits of code you can use the "source" tags to make it come out pretty

0x00000000 means that its null. I don't know DirectX so I could be missing something but you have a d3d variable and a d3d_device variable. Is there a difference?

As Stormtrooper mentioned, in Windows 0x00000000 == 0 == NULL. Pointers are never initialized to NULL on their own in C++, so this means you've initialized d3d_device to NULL and then tried to use it. And as you probably already know, you can never call a method on a NULL pointer or dereference in any other way. The most likely cause of this would be that you're somehow calling "DX_GFX_FRAME" before you call "DX_GFX_INI". Are you calling these in response to Win32 messages?

As for what you're seeing with the debugger, let me explain a bit for you. When you've broken into the debugger, you can peek at at your variables in two ways: you can look at the list of local, automatic, or watched variables in the bottom left window (local variables are variables local to the function, automatic variables are variables referenced or changed recently, watched variables are variables you've manually tagged as such), or you can hover your mouse over a variable. What you see when you either look at the variable in the window or when you hover over it depends on what kind of variable it is. If it's a regular primitive type (int, short, float, etc.) you just see the value. If it's a struct or class, you get a little plus icon and you get a little tree that shows the values of all of the members of a class or struct. Here, let's take a simple example and I'll show you a picture of what happens in the debugger: try making a simple console program and declare a struct with a few members. Then in the main function create a few primitive types and assign them, then declare a variable whose type is your new struct and set its members to some arbitrary values. I'm going to use code that looks like this:




After this, put a breakpoint on the last "return 0" statement. You do this by clicking in the margin to the left of all of your code, you should see a red circle appear there. A breakpoint tells the debugger to break in as soon as it reaches that line, so you can have a look around. Now run your program, and either mouse over num1 or look down in the "autos" or "locals" tab of your debugger watch window. The debugger should show you that the int's value is 47, and should show you the char's numerical value as well as the corresponding ASCII glpyh. Now do the same for structInstance. You should get that little plus icon you saw before, except this time if you click on it you should get a list of structInstance's members and their values. Neat, right? Now at this point you hit F5 to resume execution and have your program wrap itself up, or you can hit F10 or F11 to step forward one line and see all of the stuff that the CRT does (the difference between F10 and F11 is that F11 will enter functions, while F10 will skip over them and go to the next line).

Okay now, moving right along. You can see how the debugger treats normal primitive types as well as structs and classes. But how about pointers? When the debugger hits a pointer, it will show you two things since both are probably relevant: the actual value assigned to the pointer, and the value of whatever the pointer is pointing to. Let's try it with both a primitive type and our struct. Change your code to this:



Now set your breakpoint again (if you removed it) and run your program. First check out numPtr: you should get a plus icon and then a value that's in hex. That hex value is the value currently assigned to your pointer, for me it's 0x0012ff60. The reason it's in hex is because pointers *generally* contain virtual addresses, with that address belonging to whatever they're pointing to. So in this case it's pointing to a local integer, so it's pointing to an address on the stack (if you don't know how the stack works don't worry about it right now). Now, click on the plus icon: lo and behold, we have a magic value "47" which is the value of the original integer. This means the debugger followed (derefrenced) the pointer and looked at the value in the memory address contained in the pointer. Now, have a look at string1: notice the debugger automatically interprets char* pointers as strings, and shows you the corresponding ASCII text. And finally, look at the struct. As expected, you get the value of the pointer in hex and then a full listing of the members when you click on the plus.

At this point, you should be able to start piecing together the behavior you were experiencing when you ran the debugger on your D3D app. You said you got a value of 0x00000000 when you moused over your d3d_device variable (which is a pointer of type IDirect3DDevice9*). Like I said earlier this meant the pointer was pointing to NULL, which basically means the pointer wasn't pointing to anything. Therefore when you clicked the plus the debugger followed this bogus pointer, found nothing, and then complained to you for making it do that. As for the HWND...that's a bit trickier. First it helps to see what an HWND actually is. For this we take a trip over to the MSDN library, which has a list of all of the types defined in the Windows API. There we find this:

typedef HANDLE HWND;

Okay...so what's a HANDLE? That's on the same page:

typedef PVOID HANDLE;

Ah hah, now we're getting somewhere (PVOID is just another typedef to void*). So what does this mean? To the debugger, an HWND is just a pointer. But in reality, an HWND is not a pointer at all: it's a handle to a window. It's value isn't a memory address we can just go to and find something relevant, it's a value that only has meaning for the OS window manager in user32. Which is why when the debugger tries to follow the pointer it finds garbage, and subsequently gets irritated.

Okay, so you're now a debugging master! Or, something like that. [smile]
You may notice I haven't really explained what's going on with that IUnknown that popped up, and also didn't mention what happens if you click the plus on actual valid IDirect3DDevice9 pointer. That's because the answers to these questions involve COM, and COM tends to be somewhat scary for beginner programmers. So I'll spare you for now, and instead suggest that you read the introduction to COM that's found a the beginning of the SDK documentation. It does a decent job of explaining COM in a way that's relevant to D3D. Don't worry if you don't understand all of it, just try to grasp the basics and come back to it as you become more experienced.

[Edited by - MJP on March 27, 2008 7:09:39 AM]

Quote:Original post by Stormtrooper
0x00000000 means that its null. I don't know DirectX so I could be missing something but you have a d3d variable and a d3d_device variable. Is there a difference?

Don't worry about that. With D3D you get a pointer to an IDirect3D9 interface that represents the general D3D9 SDK, and also a pointer to an IDirect3DDevice9 that represents the actual graphics device you're using.

What I would do if I were you is simply step through your app with your debugger and see how your program executes. Set a break point at your first line of code in WinMain, then see what functions your program runs and it what order. Or if you don't want to go through the whole program, just set breakpoints at the start of your DX_GFX_INI and DX_GFX_FRAME functions and make sure DX_GFX_INI is getting called first (I suspect your problem is that DX_GFX_FRAME is actually getting called first, hence the NULL pointer).