|
1. You need to have latest platform SDK.
2. Your IDE should be configured to include files from latest SDK. VC 6 doesn't includes latest SDK files by default. You need to set those paths using Tools-->options-->Directories.
|
|
|
|
|
Manasi D wrote: # define _WIN32_WINNT 0x500 is done.
It's not enough to assign _WIN32_WINNT the correct value. It also has to be done in the right spot. I find that it's best to place it before any #include statements in the project's stdafx.h file.
Other than that, ensure that the function's prototype exists in your winbase.h file.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I already had SDK installed...
Adding _WIN32_WINNT before #include statements in stafx.h worked!
Thank you all for your help!
|
|
|
|
|
Whats your compiler?it doesnt any problem on VS2005
|
|
|
|
|
Im working on to Create a Tree control having three state checkbox in VC++,
i have completed coding for Tree control with check box but im stucked over
to create Three state check box. If anybody from the forum have any idea about it, then please help me.
Sagar Mahewar
Software Engineer
Cell - 91-9890144989
Email id - sagar_mahewar@yahoo.com
|
|
|
|
|
Hi
I am writting a dll using MFC and ATL component.i.e ATL component implimented on dialog, but it is not working.
If i use the same thing in simple application, it is working fine.Can any body help me regarding this. so that i can use ATL component in DLL.
Thanx in Advance
Niru
|
|
|
|
|
Can you explain in detail, what you have tried ?
aaaan wrote: i.e ATL component implimented on dialog, but it is not working
|
|
|
|
|
I have created a project. I have taken the EXE from Release and tried to run in a system that doesn't have Visual Studio. Its running in some systems and in some systems it's not.
Do I need to install anything? Please help me.
Thanks in advance.
|
|
|
|
|
it is complaining at some dlls missing, isn't it ?
then either provide those DLLs with your exe, or compile with statically linked MFC.
|
|
|
|
|
Nothing happens, when I click on the exe.
It does not give any error message.
Even its not there in Processes in Task Manager.
|
|
|
|
|
how the different system differ ?
also, maybe this[^] article may be worthing it to be read 
|
|
|
|
|
It depends which dlls your exe needs. For exe with VS 2005 you need to install the VS 2005 Runtime. There is a vcredist_x86.exe in the VS directory. This exe installs the runtime.
Greetings from Germany
|
|
|
|
|
You're assuming he's writing in C++/CLR... He hasn't actually said that.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
vcredist_x86.exe installs the c/c++ runtime + mfc dll's.
This is needed for apps written with VS2005 and VC8.
It has nothing to do with managed (.NET) or not!
Simon
|
|
|
|
|
Well duh...
I was pointing out that the original poster didn't say which he was using...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: You're assuming he's writing in C++/CLR... He hasn't actually said that.
I don't think he assumed that, John. vcredist_x86.exe is not about the CLR. It installs the latest MFC, ATL, and CRT DLLs.
|
|
|
|
|
Use dependency walker to identify dpendent dlls, and make sure , they are shipped on target machine.
|
|
|
|
|
I used "depends.exe". I came to know that msvcp71d.dll and msvcr71d.dll are missing. Its working now.
Thanks everyone.
|
|
|
|
|
MaHeSG wrote: msvcp71d.dll and msvcr71d.dll
These are debug versions of dlls, run dependecy walker on release version of your exe and find appropriate version of dlls.
|
|
|
|
|
MaHeSG wrote: I came to know that msvcp71d.dll and msvcr71d.dll are missing. Its working now.
You cannot distribute these "debug" files. In your initial post you said that, "I have taken the EXE from Release..." Is this not the case?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Make sure the libraries you've linked with, both explicitly and implicitly, are present on the target machine.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
You may have other problems, but you definitely need static linking.
Go to project->settings
Click on the general tab
Select "use MFC in a static library"
press OK
Select build->rebuild all
|
|
|
|
|
malaugh wrote: but you definitely need static linking.
Why would you suggest this, when it's obvious that he has built a 'debug' version of the application? The problem is the 'debug' DLLs are not present, nor should they be, on the target machine.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Exactly my point. If you use static linking, then you can run the program on the other machine without the other machine needing the DLLs, just copy across the exe.
|
|
|
|
|
malaugh wrote: If you use static linking, then you can run the program on the other machine without the other machine needing the DLLs, just copy across the exe.
One of the most common problems with statically linked DLLs is that the version of MFC they linked with assumed a latest-version of some other DLL, and when that DLL is not installed, either their program can't load, or if it does, it ends up with the wrong version of the other DLL and crashes or otherwise malfuctions. Common controls, Common Dialogs, and OLE are the most common points of mismatch. And there's nothing that can be done other than doing a proper install.
There are about a dozen versions of MFC42.DLL, and while most of them are backward compatible, you cannot link something with a modern MFC42.DLL and expect it to work with an older one. MFC is rarely the key problem; a new version of MFC42.LIB assumes contemporary versions of a lot of other DLLs, such as common controls, OLE, COM, etc. and therefore static linking has done nothing other than increase the DLL size but not solve any problems; and you cannot use such a DLL with any MFC executable anyway, so it doesn't do any good for distributing DLLs.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
