Memory problem...

It sounds like you're missing a semicolon at the end of a class declaration, a closing brace, or something similar.
Have a look at the header you include before dxerr9, and see if there's anything missing near the end of the file.
Does it work if you just comment out the #include ?

It didn't work, but when I tried it, it revealed other errors that didn't come up before I did. Thanks. BTW, it was a bad function declaration.

I do have another problem, albeit not with my linker.


An unhandled exception of type 'System.NullReferenceException' occurred in Chat Client.exe

Why does this normally appear in a program?

In mine, it appears here:



I have a feeling it's because the Client isn't initialized. If that's the case, how can I see if it is initialized or not (I tried checking if it's not NULL)?

You're doing it the wrong way round [smile]. You want to call Release() if the object is not NULL. You're only releasing it if it is NULL. Try this:


Edit: It would be a good idea to check for NULL pointers when you release the device and D3D interface too. Even if you're "sure" they won't be NULL, you might change part of your code, and end up with a problem later on.
Also, it's generally good practice (although not nessecary) to release objects in the reverse order you created them in, which means you should release your device before the D3D interface.

Thanks! Now.. I think I'm nearing the final errors (At least the ones that are stopping me from closing the program). Now I'm getting something with memory:

Direct3D9: (INFO) :MemFini!
Direct3D9: (ERROR) :Memory still allocated! Alloc count = 100
Direct3D9: (ERROR) :Current Process (pid) = 00000850
Unhandled exception at 0x7c901230 (ntdll.dll) in Chat Client.exe: User breakpoint.

It comes up even if I don't release the objects, so I don't know where to look.

You're still not releasing something. This is the fun part [smile]
You should check the return value of Release() for all your objects, and if it returns > 0, you know that some object is still referencing that object. For example, if you're not releasing a texture, your device's reference count will still be 1 after calling Release(), since the texture is referencing it. And your D3D interface will have a refcount of 1 as well, since the device is referencing it, and hasn't been destroyed yet (because it's refcount is > 0).

Check that anywhere you call Get*() functions that return interfaces, you release the interface returned after using it. Also, remember that if you use QueryInterface() to get a newer version of an interface that you need to Release() the old version once you have the new one.
Also check that any manual AddRef() calls you make are matched by a Release() call.

BTW: Whatever you do, don't spin on release, i.e.

while(pxObject->Release());

That is very bad code-fu and you will be flogged for it. [grin]

You can track the non-released interface by using the debug runtime of D3D and set "break on alloc" to the AllocID-value provided by the debug trace.

Quote:

Original post by darookie You can track the non-released interface by using the debug runtime of D3D and set "break on alloc" to the AllocID-value provided by the debug trace.

Not nessecarily. There's 100 allocations in his code, and there's no way (that I know of anyway) to tell which one hasn't been released.

Quote:

Original post by Evil Steve Quote: Original post by darookie You can track the non-released interface by using the debug runtime of D3D and set "break on alloc" to the AllocID-value provided by the debug trace. Not nessecarily. There's 100 allocations in his code, and there's no way (that I know of anyway) to tell which one hasn't been released.

That's no problem at all.
You track down the first leak and deduce, which resource group is affected (e.g. failed to release any textures).
The result of not releasing a single resource that references the device is that device->relase() will not actually release the device but simply decrements the refcount.

Quote:

Original post by darookie That's no problem at all. You track down the first leak and deduce, which resource group is affected (e.g. failed to release any textures). The result of not releasing a single resource that references the device is that device->relase() will not actually release the device but simply decrements the refcount.

Oh, good point [smile]

Releasing the Texture did not help the situation at all. I checked all of the Alloc Id's that came up on the debugger, and they were just about the direct3d stuff that will NOT release. Is there something that wouldn't show up as allocated memory that I need to change so I can release the D3D Device and Interface?