I have one project whose .SLN file is there and we are able to run the project on Visual Studio 2008 and In which we have qt extension added that we are using In our project.
I have tried to create .pro and pri using following link:
Converting .Sln Project to .pro Project
I have able see related lib and manage to add required file. But the Code is too specific to VS.
I am getting Issue Like :
1) Cannot Convert from TCHAR to Const Char*
2)cc1plus.exe: error: one or more PCH files were found, but they were invalid
3)cc1plus.exe: error: use -Winvalid-pch for more information
4)cc1plus.exe: fatal error: release\StdAfx.h: No such file or directory
5) error: conflicting declaration of C function 'int WinMain(HINSTANCE, HINSTANCE, LPTSTR, int)'
int _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
From these I came to conclusion that the code is more specific to Visual Studio.
I am using following tools pls correct me If I am not using correct version:
1)Qt Creator 3.6.1
Based on Qt 5.6.0 (MSVC 2013, 32 bit)
Is there any specific way to port code from VS2008 to Qt 5.6 or 5.7.
What you already did - I guess - is to migrate the visual studio project file to a Qt one. However, if you want to fully migrate to Qt and write a cross-platform application, you should replace all MFC-specific code to Qt, which is very different. For instance WinMain is (as expected) specific to windows: you should have a simple main. In there, you would need to define a QApplication, and so on...
My advice would probably be to start with some small Qt samples before tackling a full-fledged migration. You can then come back with more specific questions to stackoverflow if you get stuck.
Using MSVC compiler Could solved the Problem !!!!
It's just trivia.
Microsoft tried to introduce international characters to Windows too early, before the Unicode consortium had done its work, and got everything in a twist. So the Windows functions can be passing string about as various things, plain ascii, w_chars, TCHARS and so on. You need to make everything consistent. Every Windows function that takes a string has two forms, A for ascii or W for wide.
You need to make everything consistent and make sure the the functions are getting the right forms. Which might involve inserting a few glue functions to convert strings from wide to ascii and back.
There's nothing deeply wrong, but it is a bit of a job.
Related
So I'm trying to run and compile this piece of sample code from MSDN (opening a dialig box):
http://msdn.microsoft.com/en-us/library/ff485843(v=vs.85).aspx
My compiler gives an error:
main.cpp: In function 'int wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)':
main.cpp:19:9: error: 'IFileOpenDialog' was not declared in this scope
What I get from the documentation is that CoInitializeEx function should link against the necessary COM libraries and import the needed functions. Though I am totally new to C++ and Windows and for sure I'm getting something wrong.
I use Netbeans, MinGW and MSYS.
Can somebody help me out what is happening here and how to solve?
MinGW g++ as of version 4.8.2 (the one I have) does not yet support Windows API functions or interfaces that were introduced in Windows Vista or later.
As a workaround you can use the old GetOpenFileName or GetSaveFileName dialog.
Alternatively download and install Visual Studio Express for Windows Desktop, and use Visual C++.
I have a project that uses MFC and standard C++. I dont know in which VS it was originally made. When opened on the machine with only VS2012 installed and on the machine with only VS2010 installed - it doesn't build, showing errors, mostly regarding type mismatch. For example:
CListBox <bx
CString s;
ltbx.AddString(s);
This shows error, saying that AddString doesn't take argument of a type CString. The same goes for
CListBox <bx
std::string str;
ltbx.AddString(str.c_str());
This code as well shows an error:
string str;
CString CInputID;
str = static_cast<string> (CInputID);
It says that there is no user defined conversion from CString to std::string.
No doubt, I should be using different types for strings and all, but the exact same project opened on the machine which has installed both VS2010 and VS2008 works just fine, all types are matched. So my question is how does this work? I am thinking, maybe VS2008 has some libraries that define all necessary conversions and VS2010 is just making use of them. If so, what are those libraries and how can i make this project work on machines with no 2008 studio installed?
AddString takes a LPCTSTR which is a const char* or const wchar_t* depending on whether _UNICODE is defined.
The difference is probably that _UNICODE is defined in your VS2012 project.
I am using Visual Studio 2005 and Windows Mobile 6 Professional Device SDK to debug a Windows CE project (copied from a Windows project ). I use active sync to connect PC and Win CE device. Then I create a new Windows CE project (copied from Windows project, but create using windows mobile 6 professional device SDK as platform. vc++, smart device, console app ).
When I build the windows CE project, there are some errors:
Error 1 error C2664: 'GetProcAddressW' : cannot convert parameter 2 from 'const char [21]' to 'LPCWSTR' xxxxx.cpp 42
It occurred after I used LoadLibrary(_T(xx.dll)); then I used GetProcAddress(handle,"functionName");
If I change it to use GetProcAddress(handle, _T("functionName") ); this error dispears. But
new error
LINK: error LNK2019: unresolved external symbol __imp_Function2
referenced in function wmain xxxx.obj
occured, Function2 is from another DLL project(both for windows and windows CE).
I don't know if I describe the problem clear, but I want to ask are there any way to make the source code that is both for Windows and windows CE when in the source code some functions are from different DLLs ?
Any answers are appriciated!
The first compiler error is somewhat self explanatory. get "W" at the end of GetProcAddressW means that the method is the wide character API (as opposed to GetProcAddressA, which is the ASCII version). Windows CE only exports the wide character versions of APIs. That means that you have to pass in a wide-character string. You used a TCHAR macro when you used _T, which makes the enclosed string a wide character literal, and the error goes away.
The same code should work fine on big Windows (for any recent version anyway), provided that you #define UNICODE (which is probably already on) and #include "tchar.h" which I think you since _T compiles. You could explicitly call GetProcAddressW instead of just GetProcAddress (which should be #defined to the wide version if UNICODE is defined).
The source linker error you see isn't clear. I'm guessing __imp_Function2 is a function pointer that you're trying to assign with the GetProcAddress call? Basically the linker isn't finding it, but the root cause isn't clear with the info you've provided.
I've been using the CppShellExtContextMenuHandler sample project from Microsoft's All-In-One framework to add a custom menu item + icon to windows's context menu.
However, it seems that I can't register the DLL provided by this sample on other computers than mine. The DLL, compiled on a Windows 7 x86 machine from unmodified code, doesn't run on:
Another Windows 7 x86
A fresh Windows XP SP3 x86 install on VirtualBox
I get:
LoadLibrary(CppShellExtContextMenuHandler.dll) Failed to find
specified procedure
(translated) on the XP machine
The module "CppShellExtContextMenuHandler.dll"
failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The specified module could not be found
on the other Windows 7 machine
I use Regsvr32 CppShellExtContextMenuHandler.dll in the commandline to register the DLL.
Did anyone encounter this problem? Did I miss something (dependencies/project config)?
I'm not sure how to debug this one.
Thank you for your help!
PS1: Code is available here: http://1code.codeplex.com/releases/view/71395, under ./Visual Studio 2010/CppShellExtContextMenuHandler in the package.
PS2: Compiled version of the sample is here: https://fgt.bo/GmQ
Finally found the answer, thanks to Choosing a Deployment Method on MSDN.
To make the DLL file compiled from the CppShellExtContextMenuHandler sample work on non-dev computers, you need to accompany it with the VC++ Runtime DLLs it depends on.
I used the wonderful tool on a client's (non-dev) machine to get the name of the DLLs my context menu handler depended on (the tool indicates which of them are missing on the arget computer!).
It turned out I had to redistribute the msvcr100.dll and msvcp100.dll files from [Program Files\Microsoft Visual Studio 10.0\VC\Redist] along with the CppShellExtContextMenuHandler.dll file to make it work.
To make the handler work on Windows XP, I also had to replace the two occurences of
hr = HRESULT_FROM_WIN32(RegDeleteTree(...
by:
hr = SHDeleteKey(...
...in the Reg.cpp file. In fact, according to C++ Windows Shell context menu handler Sample, the RegDeleteTree function isn't available on XP.
The SHDeleteKey is equivalent and can be found in Shlwapi.h, on all versions of windows I tested.
Thank you for your time reading and trying to solve this!
Guys that is code copied from a book (Programming Windows 5th edition):
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0) ;
return 0 ;
}
Link to the topic in which this book is recommended.
Can't compile it with VS2010. What am I doing wrong?
Error 1 error LNK2001: unresolved external symbol _WinMainCRTStartup
Thanks.
It will depend on how you set up the project. In VS2010, if I create a new project via File->New->Project, Visual C++, Empty Project, then add a new C++ file, and copy your code in, it compiles and runs just fine.
If you've created a different type of project, it may be using different link libraries. Try right-clicking on your project in Solution Explorer, going to Properties->Linker->System, and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)
The Win32 APIs are old, but for the most part are perfectly usable if you want to do native Windows programming. Windows has done a great deal of work to ensure that as long as you've followed the documentation, old APIs will not change. You can still compile 16-bit Windows 3.1 code from 1992 and run it on 32-bit Windows 7.
Edit:
It could also be that in Properties->C/C++->Advanced, you have Omit Default Library Name set to "Yes", you probably want it set to "No"
Or also Properties->Linker->Input->Ignore Default Libs should be set to No.
You need to set the project's linker settings to create a Windows GUI program rather than a console program:
"Linker/System/SubSystem" should be set to "Windows (/SUBSYSTEM:WINDOWS)"
Usually this setting gets set properly when you create the project and choose a Windows GUI Application template. Unfortunately, if the project is set to the incorrect application type, the setting is a bit buried (it took me bit of digging to find it).
Make sure you have actually added the source file to the project. This worked for me.