MFC and irrlicht

munin · Post by **munin** » Wed Aug 12, 2009 4:45 pm

Hello guys,

at first: yes i tried the search function and yes I got some examples that work with MFC (kinda)

but:
I dont want to dive in to deep for now because irrlicht is new to me and I just want to try arround for now (so the thread example is nice but its quiet spreaded for a irrlicht rookie like me lol)

so whats the plan?

I got like a step by step workin by seting up a dialog based MFC project
I did the usal thing like including die headers and well I thought lets created the device

I try both : copying the irrlicht.lib in my project dirs and setting a path to the lib in the install dir of irrlight but Im lost here now

I can create the pointer to irrlichtdevice but if I try to call the createDeviceEX fuction my VS2005 tells me it cant find irrlicht.lib

its pretty anoying not to get to the source of the problem because I just added maybe five lines at all to the project

so maybe someone has some expirience with MFC could give me a hint on that would be nice.

regards

Munin

CuteAlien · Post by **CuteAlien** » Wed Aug 12, 2009 5:50 pm

That's a linker problem and has nothing to do with MFC.
I just described that yesterday, so you can look here: http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

munin · Post by **munin** » Wed Aug 12, 2009 8:01 pm

well I dont get a linker error because I can compile it as long as I dont want to use createDeviceEx

if its a linker error and irrlicht.lib is missed it should run at all ..should it ?

dont want to sound like a smartass but thats what I though

I dont get the prob with noprmal win32 projekts at all

CuteAlien · Post by **CuteAlien** » Thu Aug 13, 2009 2:51 am

2 steps - 1. compiling, 2. linking. You can compile when it finds the headers. You can link when it finds the library. You wrote it does not find the library so it is a linker problem and not a compiler problem. But if that's not the case please post the exact error message (just copy&paste it).

munin · Post by **munin** » Fri Aug 14, 2009 9:03 am

well like I said wen I just do the include and the pragma comment

and tells the app that I want a pointer to irrlicht device everything works

like the app shows up withhout error

when I try to create de device with createDevice or createdeviceex

I geht a messagebox
that the app cant run because irrlicht.dll wasnt found and a new istallation of the app could solve the problem.

for me its kinda strange that this should be a linker problem because I always thought when the irrlicht.lib couldnt be found it should complain always not just when I use a function.

but well maybe I think wrong

regards

CuteAlien · Post by **CuteAlien** » Fri Aug 14, 2009 4:29 pm

"DLL not found" is a runtime error, so your application is already linked (there are 3 stages: 1. compiling, 2. linking and 3. runtime). And well, it simply means as it says - that it's not finding your irrlicht.dll :-)

And if you check the msdn documentation you will find that you have to copy dll's in the right place: http://msdn.microsoft.com/en-us/library/7d83bc18.aspx

munin · Post by **munin** » Fri Aug 14, 2009 4:43 pm

well it seem we talk about diffrent things here

thx anyway

regards

Munin

CuteAlien · Post by **CuteAlien** » Fri Aug 14, 2009 5:01 pm

Always answering based on your error-descriptions. If you would start simply copy&pasting the actual errors instead of trying to describe them things would be easier.

If you get a linker error it's because of linker paths. If you get a runtime error it's because the dll is not in on of the paths described in the link in my last post. And you don't get the error unless you use createDevice in your application because there is no need to access the library unless you use a function from it (and createDevice and createDeviceEx are the only exported functions for Irrlicht).

munin · Post by **munin** » Fri Aug 14, 2009 5:42 pm

its a msg box not a error in the VS environement

but like I said thx anyway

regards

munin

CuteAlien · Post by **CuteAlien** » Fri Aug 14, 2009 5:51 pm

munin wrote:its a msg box not a error in the VS environement

Yes, since you told me that part I know it's a runtime error - so it has to do with the dll.

Well, nevermind.

VPB_Enge · Post by **VPB_Enge** » Fri Aug 14, 2009 9:38 pm

I have the solution for you.
Take CuteAlien serious. He is right.

munin · Post by **munin** » Tue Aug 18, 2009 1:04 am

VPB_Enge wrote:I have the solution for you.
Take CuteAlien serious. He is right.

extrem helpful post

but well I said befor I have tried also copying lib files in every possible directory

it doesnt help and well I just stoped trying it at all

regards

munin

CuteAlien · Post by **CuteAlien** » Tue Aug 18, 2009 3:55 am

munin wrote: but well I said befor I have tried also copying lib files in every possible directory

The lib files are for linking, but you say you get a runtime error. Copying the lib files around can only help to save linking errors, at runtime .lib files are simply not used. Please read again what I wrote - you have to understand the 3 stages of compiling, linking and runtime when you do c++ programming or it will bite you all the time. To prevent runtime errors you have to copy the .dll file to one of the paths mentioned in the msdn link - not the .lib file because at runtime the dll is accessed.

Just once more:

Compiling: Each .cpp file is compiled on it's own and results in one object file (called .obj with VS and .o with gcc). If you get an error at that stage about wrong paths then it is a compile error and most likely complains that it does not find header files.

Linking: The object files and library files (.lib) are put together (linked) into one file. The resulting file is either a library or an executable. On static linking the code in the libraries is really added (copied) to the resulting file. On shared linking only enough information is put into the resulting file to find the functions later from a dynamic library while the real code is not put into it. Also there are default c-libraries which are always linked into the resulting files unless you suppress that explicitly. Errors at that stage are linking errors and they can complain that they don't find a .lib file (which you said in your first post, but not in later posts). To solve that you have to set linker paths to the path where you have .lib files (and I never said anything about any copying around). Other typical errors you get at that stage are unresolved externals - which means that you don't have linked some code which you had said that it would exist (via headers) in the compiling stage.

Runtime: At runtime (when the .exe is really started) the application searches for all code that was linked dynamically in the dynamic libraries (also called shared libraries). So if you have used a function in your code and told the linker that it should be linked dynamically the application will now look for it in a dll (or a .so on linux). And if it does not find it then it will tell that it's not finding the dll and give you a runtime error (typically a message-box). There are many more runtime errors (like all the protection faults), but right now it seems that you haven't put the Irrlicht.dll yet in the right place.

edit: Also - maybe there is another problem - but unless you copy us the *real* and *exact* error-message which you get we will never now. Simply never ever try to summarize error-messages, but always copy them exactly as you have them on screen. If you can't copy&paste them and you are too lazy to trancribe them then simply do a screenshot and post that.