I have a problem with SHGetFolderPathA in Visual Studio 2010 (Windows Forms).
I included to project ShlObj.h and added for button this code:
char SciezkaCookies[MAX_PATH];
HRESULT hr = ::SHGetFolderPathA(0, CSIDL_APPDATA, 0, SHGFP_TYPE_DEFAULT, SciezkaCookies);
But when i try compile my project, Visual return errors:
error LNK2028: unresolved token (0A000012) "extern "C" long stdcall
SHGetFolderPathA(struct HWND *,int,void *,unsigned long,char *)"
(?SHGetFolderPathA##$$J220YGJPAUHWND__##HPAXKPAD#Z) referenced in
function "private: void __clrcall VoxPopuli::Form1::start_Click(class
System::Object ^,class System::EventArgs ^)"
(?start_Click#Form1#VoxPopuli##$$FA$AAMXP$AAVObject#System##P$AAVEventArgs#4##Z)
and
1>VoxPopuli.obj : error LNK2019: unresolved external symbol "extern
"C" long stdcall SHGetFolderPathA(struct HWND *,int,void
*,unsigned long,char *)" (?SHGetFolderPathA##$$J220YGJPAUHWND__##HPAXKPAD#Z) referenced in
function "private: void __clrcall VoxPopuli::Form1::start_Click(class
System::Object ^,class System::EventArgs ^)"
(?start_Click#Form1#VoxPopuli##$$FA$AAMXP$AAVObject#System##P$AAVEventArgs#4##Z)
I'm looking for solutions in google, but all examples is not working ;/
Thanks for help!
Calling native winapi functions like SHGetFolderPath() is fine from C++/CLI, that's what the language is good at, but you do have to keep the linker happy yourself. Use the MSDN Library article for the function (not today, site has been down all week). At the bottom of the article it lists "Header", that's how you found out that you needed to tell the compiler about shlobj.h. It also lists "Import library", that's what you need to tell the linker. The import library tells the linker what DLL needs to be loaded at runtime to call the function.
Project + Properties, Linker, Input, Additional Dependencies. Add "shell32.lib"
Or you do it in your source code with a #pragma, a way to pass link instructions to the linker:
#include <shlobj.h>
#pragma comment(lib, "shell32.lib")
It should be said, this is definitely one api function that you really want somebody else to have to deal with. Note how the MSDN Library article also says that the function is deprecated. There's been a lot of flux in standard folder paths across Windows versions. You have the "someone else" readily available in a .NET app, Environment::GetFolderPath() does this for you. Also saves you from the hassle of having to deal with different string types.
You must have declared it yourself to avoid including the Windows headers- not that I blame you for doing that- but you have mangled the name, so the linker cannot resolve it from the native library.
Oh, you're in C++/CLI? Maybe the compiler flat out won't like the native call into managed code, then.
I'd avoided using native functions if .NET solution is possible. Try to use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData));
Both native and .NET approaches are discussed here:
http://bytes.com/topic/c-sharp/answers/269259-my-documents-path-c
Related
I have an old project that I need to revisit. It was built in some version of Visual C++ (prolly 2005) looking at the .sln file. The sln file wont get converted to a VS 2008 solution due to some corruption (dubug point -1). I imported the folder in VS as a new project and tried compiling.
It gave compilation errors for "lang/Typedefs.h/Assertions.h" not there. Removing the declarations I had errors for Uint8/16/32/64 not declared. So I added the typedefs and other macros (TOOLS_UNUSED_PARAMETERS(x) / TOOLS_FORBID_COPY()).
That being ironed out, I got errors for Gui/FileDlg.h and Gui/FolderDlg.h(debug point - 2).
I didnt find any of those header files from any resources online or in my current VS installation and so I am assuming that code is missing and I will have to redo it.
Even these could probably have been custom implemented by the earlier programmer. The current MFC uses CFileDialog and the code uses Gui::FileDlg.
I commented out the code for the time being to see where can I get to since gui is not that big a part of the application. Later I see linker errors corresponding to RegKeyOpenEx calls and outputstream calls(dubug point -3). Winreg.h was not included but windows.h was.
sample :
Error 2 error LNK2019: unresolved external symbol __imp__MessageBoxA#16
referenced in function "public: class std::basic_ostream<char,struct
std::char_traits<char> > * __thiscall FileManager::getOutputStream(class Interface
*,class LogPoint *)" (?getOutputStream#FileManager##QAEPAV?$basic_ostream#DU?
$char_traits#D#std###std##PAVInterface##PAVLogPoint###Z) filemanager.obj
PCAPGenerator
I am not a .Net programmer so can you please suggest what would be the right course of action here ?
which debug points should i be focussing on.
RegKeyOpenEx is a Winapi function defined in Advapi32.dll. To link that into a Visual C++ project:
If your project is a static library (right-click project->Properties->Configuration Properties->Configuration Type->Static Library (.lib), go to Configuration Properties->Librarian->General->Additional Dependencies and add Advapi32.lib.
If your project is a dll (same place, says Dynamic Library (.dll) instead), you'll have the Linker section instead of Librarian. Go to its Input subsection, and add Advapi32.lib to Additional Dependencies.
For your remaining linker errors, proceed in the same way: go to the MSDN doc for the function, check which dll/lib it belongs to and have your project link it in as described above.
I have been stuck with a MFC-related problem for quite some time now. I have read through many forums, VTK-Users posts, etc. without any luck.
My basic problem is that vtkMFC.lib is not getting built; no matter how I build my project or configure it.
These are the steps I have followed:
Generate VTK.sln using CMake 2.8.9 with VTK_USE_GUISUPPORT, BUILD_SHARED_LIBS, VTK_USE_MFC, BUILD_EXAMPLES turned ON and VTK_USE_VIDEO_FOR_WINDOWS turned OFF.
Open VTK.sln on VS-2008 and build ONLY vtkMFC.sln.
Build entire solution.
{I have also tried with points 2 and 3 inter-changed with no result}
There are 6 erros; of which 3 are to do with the fact that vtkMFC.lib isn't there (for the examples. obviously). The rest are regarding a couple of resolved external symbols,
error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class vtkDataSetReader * _cdecl vtkDataSetReader::New(void)" (_imp_?New#vtkDataSetReader##SAPAV1#XZ) referenced in function "protected: __thiscall CSampleDoc::CSampleDoc(void)" (??0CSampleDoc##IAE#XZ) in SampleDoc.obj
error LNK2019: unresolved external symbol "__declspec(dllimport) public: class vtkDataSet * _thiscall vtkDataSetReader::GetOutput(void)" (_imp_?GetOutput#vtkDataSetReader##QAEPAVvtkDataSet##XZ) referenced in function "public: virtual int __thiscall CSampleDoc::OnOpenDocument(char const *)" (?OnOpenDocument#CSampleDoc##UAEHPBD#Z) in SampleDoc.obj
The files generated in Debug/bin for vtkMFC solution are vtkMFC.dll, vtkMFC.idb, vtkMFC.ilk, vtkMFC.pdb.
I have also added vtkIO.lib to the projects that generated the error and the same erros continue along with another which says that vtkIO.lib isn't found.
Any help in this regard would be much appreciated.
Best,
Sarthak
Answer as of February 2013:
Turns out, there is some issue with VTK 5.10.1. Using 5.8.0 solved the problem.
Certain things to be kept in mind while building VTK from CMake:
If BUILD_SHARED_LIBS is selected (i.e., you want DLLs to be generated), then make sure all flags are set to /MD. If BUILD_SHARED_LIBS is unselected (i.e., you don't want DLLs to be generated and are linking via static libs), then make sure all flags are set to /MT.
I'm currently trying to learn WinSock coding from http://johnnie.jerrata.com/winsocktutorial/ however when I compile my listening socket, I get 9 error LNK2019: unresolved external symbol errors. They all look to be the same function names that are used in the code prefixed with an underscore after the function name it says referenced in function _WinMain#16
This also happens when I run the code example that is available for download, so I don't think I've made a mistake.
What is an unresolved external and how do I go about fixing one? I can post the code if needed but it's all visibile on that link. I'm using Visual Studios 2010, Win32 project.
Unresolved external is linker error, telling you that you didn't link symbols you are getting those unresolved externals to into the binary.
Quoting from the site you linked:
Feel free to download the entire tutorial code listing. Remember that any code presented in this tutorial should be linked with the Winsock library, usually wsock32.lib or something similarly named. Also, when using code exactly as presented in the tutorial in your own IDE (Dev-C++, Microsoft VC++, C++ Builder, etc.), choose to build a Windows project with a WinMain() to avoid errors.
One of ways to link it is:
#pragma comment(lib, "wsock32.lib")
Also, consider using Boost.Asio instead of raw WinSock.
I need to use RawInput api calls from under the old compiler
which is pre xp (it is borland 5.5 specifically - and do not tell
me to use other compiler it is out of question, I need to use it)
Ist headers winuser.h and user32.lib do not contain the raw input
calls, never header and user32.lib from other compilers do.
So it is achieveable to use such external rawinput .h definitions
and link it against newest user32.lib?
I am not so much experienced in linker stuff. Definitions compile
but I do have unresolved externals at link
Error: Unresolved external '__stdcall GetRawInputDeviceList (tagRAWINPUTDEVICELIST *, unsigned int *, unsigned int)' referenced from C \CODE2\PROGRAM\MAIN.OBJ
Error: Unresolved external '__stdcall RegisterRawInputDevices(const tagRAWINPUTDEVICE *, unsigned int, unsigned int)' referenced from C:\CODE2\PROGRAM\MAIN.OBJ
substitution of old user32.lib with new user32.lib seem to give no effect (even
renaming it out seem to has no effect, and it seems like compiler do not touch user32.lib at all (?)
How to make it work, much tnx for advice how to resolve this (and to not tell me
i need newer compiler, i need to do it with this old)
(fire)
// edit : fixed my mistake typo winuser.lib to user32.lib (i meant user32.lib)
When you need to call APIs which do exist on some Windows platforms and not on other ones, then you must NOT bind to the associated LIB statically but dynamically (using LoadLibrary and GetProcAddress). Another mechanism would be to use Delay-loaded Libraries.
GetRawInputDeviceList and RegisterRawInputDevices are both in user32.lib not in winuser.lib
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645598(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645600(v=vs.85).aspx
those pages also state that you only need to include windows.h (and not winuser.h)
I want to build a DLL to use it as an IIS/ISAPI application. So far so good. It works. However, I have to drag arround the runtime dll and other dependencies (like some boost libraries).
I would like to make a single DLL (in order to ease the deployment on multiple servers).
So I changed the switch from /MD to /MT. However, now I get errors of duplicate symbols during link. For example :
msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: void __thiscall std::basic_ostream<char,struct std::char_traits<char> >::`vbase destructor'(void)" (??_D?$basic_ostream#DU?$char_traits#D#std###std##QAEXXZ) already defined in gateway.obj
I'm puzzled that /MD or /MT are compiler flags and not linkers flags. And it could in some way explain why I get duplicated symbols (as the will be included in each .obj).
So the question is: how do I configure visual studio 10 in order to get a dll that includes all its dependencies.
The /MD and /MT switches only apply to the Microsoft C runtime library and not 3rd party libraries. This documentation gives some information on why it is a compiler switch (they cause different defines to be created during the compilation).
Pulling 3rd party DLLs directly into your own DLL as static libraries is probably not a simple process unless static libraries already exist. I don't know of any standard method for turning a DLL into a static library. A quick Internet search indicates that there exist tools that claim to do that process (my quick search did not turn up any free ones). But I think the most robust solution would be to use existing static libraries if you can. I believe you can build static versions of the Bools libraries, which you could then specify in your link statement in Visual Studio (as opposed to naming the libraries for the DLLs).