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++.
Related
Here's my problem.
I have written a class in VB.NET under Visual Studio 2015 (MyLibrary).
I compile it as a DLL with 'Make assembly COM-Visible' checked, so it generates a .tlb file in addition to the DLL file.
Then I try to instanciate this class in C++ code, under Visual Studio 2013, using the COM mechanism.
For that, I make the .tlh file generated by :
#import "MyLibrary.tlb" raw_interfaces_only
Then I do :
// Initialize COM.
HRESULT hr = CoInitialize(NULL);
// Create the interface pointer.
cMyLibraryPtr l_pclMyLibrary(__uuidof(MyLibrary));
// Use it
l_pclMyLibrary->DoThings();
When I do it from the computer where both versions of Visual Studio are installed, it works well, either in debug or release mode.
But when I launch it from another computer where I "installed" my software, I get the REGDB_E_CLASSNOTREG when the constructor of my class calls "CreateInstance".
I've checked or tried those things to make it work :
Everythings is compiled in x86 (VB.NET and C++) and I'm on two 32bits targets
I tried to register my library by calling "regasm.exe MyLibrary.dll". I checked in regedit that the registration worked.
I don't know what I can do more... So any help would be welcome!
Thanks
Alex.
I've had better luck using:
regasm /tlb /codebase MyLibrary.dll
Note the /tlb and /codebase parameters...
I'd also want to make sure you run it from an elevated command line that has administrator privileges.
In addition, you need to be sure that the version of regasm.exe that you are using is
1) the same version of .NET that you build your DLL
2) In your case, that it is the 32-bit version of regasm.exe and not the 64-bit version
The other thing, is if you are going to distribute these in the same install directory, you could use Isolated COM so that registration is not even necessary.
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.
I am developing a C/C++ application using Visual Studio Community 2015.
I used to build my application the system library: OneCoreUAP.lib. I am using Windows 8.1.
I used the function if_nametoindex defined in https://msdn.microsoft.com/en-us/library/windows/hardware/ff553788%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
In the link they specifies that you require ONeCOreUAP.lib
but I found Another links that indicates another library: Iphlpapi.lib: https://msdn.microsoft.com/en-us/library/windows/desktop/bb408409%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
When launching my app I getting the following error:
The program can't start because api-ms-win-core-synch-l1-2-1.dll is missing from your computer.
Try reinstalling the program to fix this problem.
This is the message image:
When searching the dll, I know from the this link:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt657574(v=vs.85).aspx
that:
Introduced into api-ms-win-core-synch-l1-2-1.dll in Windows 10.0.10240.0
I tried to update the Windows 10 SDK, But this did not solve the problem.
How to solve the problem? Should I upgrade my windows 8.1 to windows 10 to solve it?
The page you found appears to have to do with Windows drivers that link against the Universal App Platform runtime, which is only available in Windows 10 and up. OneCoreUAP.lib is the .lib file that represents the UAP runtime. If someone who knows more about this could enlighten me on the specifics of this, that would be helpful; I don't fully understand what's going on or how and hwy it works.
You are not writing one of these; instead, you are writing a desktop program. So instead, you want to look at the desktop program documentation. Usually this is the first thing that Googling for the function name in question will get you. In your case, this is that page, and at the bottom of the page it says the function can be found in Iphlpapi.lib, so you must link aganst that .lib file instead.
The bottom of that page also says the function was introduced no later than Windows Vista, so you are able to use it on 8.1.
I'm building a cross-platform application using Qt. Developed on Linux but want to build on Windows, using MinGW-w64. But this compile error happened:
For example, I have a function named func. If adopt the default compile option -municode provided by qmake, gcc says undefined reference to funcW. If manually remove this option, gcc says undefined reference to funcA.
This error only happened for one function, others are fine. That's weird to me though.
Code can be successfully built and compiled on Linux.
Any idea how it happens and how to fix it?
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!