It''s not so much a problem with the code, but with what''s happening when I try to compile. Whenever I compile I recieve a linker error which says: WinInit.obj : error LNK2005: "unsigned char * D3DRM_XTEMPLATES" (?D3DRM_XTEMPLATES@@3PAEA) already defined in Main.obj. This problem goes away when I take out the #include <rmxftmpl.h> statement, but another one arises; it says: c:\program files\microsoft visual studio\myprojects\visual c++\directx\main.cpp(166) : error C2065: ''D3DRM_XTEMPLATES'' : undeclared identifier. I''m not sure how to go about fixing the problems. Any suggestions?

at the beginning of every header file I suggest you fo the following
#ifndef __FILENAME_H__
#define __FILENAME_H__
all code, even #includes go here
#endif
This will prevent multiple includes. Do this for every project you work on, it saves headaches, and is generally considered good form. AppWizard does this automatically using GUID''s but as long as you don''t duplicate any filenames, you should be fine.

I just had the exact same problem. Corry''s answer may work for you, I suggest trying it, but it didn''t work for me. This problem also existst if you have multiple declarations of structs and templates too. You''re on the right track in thinking that it had to do with the #include <rmxftmpl.h>. What I did was take out of the header file and add it right to the cpp file where you are trying to use it. It seemed that one of the other includes was also trying to create a D3DRM_XTEMPLATES structure. Maybe someone elses can clarify what this works better than I can. All I know is that my code works now after battling with this problem all day.

Hope it helps!
and GL

well, the problem shows up at link time, so header guards aren''t really going to help since they''re meant to solve duplicates at compile time. the problem is that two or more independent sources are including the rmxftmpl header, and in that header is the global array D3DRM_XTEMPLATES. so you end up with two or more object files trying to allocate space for the same named global variable.

what i did was to separate all of the .x file template related stuff and put that into a class of its own with its own source and header files. then everything else refers to that class and doesn''t muck with the template stuff at all.

Actually, depending on the structure of your app, you can get those messages at link time but not having the #ifndef. Even if it does not solve this particular problem, it is still good form, and a good idea. Personally I wouldn''t ever use .x files, so I have no experience with them or their headers. The way I have grown accustomed to blocking all such errors, compile or link time is to create one header which contains ALL my includes, class prototypes, global function definitions, Macros, etc. All other .h files and .cpp files include that one header. The "header guards" prevent the include loops from forming. Now all classes have access to other class definitions, all SDK and windows headers are available in all my class declarations and implementations, and I have no multiply defined symbols anywhere.
It is only a suggestion, but one that has worked for me repeatedly. It''s really nice since I am making "workspaces" with multiple "projects" in them, like 2 dlls, 1 exe...where the exe is linked to the 2 aforementioned dlls. I include 1 header file, and I have everything. Not too bad if you ask me, nice neat, and organized.
Well, I''ll step down off my soapbox here, and just say have fun. Although multiple includes should be fairly easy to find, they can be tricky when 1 file you include is included in a file you included....etc.

Thanks, guys! With your help, I figured out how to go around my problem. BadFinger, I went with your idea of putting the code directly into my main cpp and it worked. Oh, and Corry, I do put #ifndef _MAIN_H #define _MAIN_H at the top of my header, as well as put in all my includes and prototypes. I agree, it's good form. But on a side note, I noticed that if I put #include <rmxftmpl.h> as the very first thing (even before #include "main.h") in my main cpp it also seems to work.

[edited by - iykxcy on April 28, 2003 4:38:01 PM]