I have a very strange problem with my MFC application. Details:
Built with Microsoft Visual Studio 2008 (Version 9.0.30729.1 SP) under Windows Vista SP1 Ultimate.
This app. is about 15 years old and has seen most VS versions.
I have a separate test-pc with: Windows XP Pro SP3, Vista Home Premium, 7 Ultimate.
Of course I installed the VC++ redistributable on all Windows.
Now I will try to describe the problem:
The program uses MFC classes for working with CArchive objects. A user can create a new project that contains one or more sheets that contain cells that may contain text, pictures, or both. e.g. a sheet with an 8x8 grid. This project can be saved to disk: MySheet.K01, MySheet.K02, etc. The sheets are viewed with a CMultiDocTemplate.
I created a branch of this project for creating a program that can convert these files to another format. I made it a console application using AllocConsole().
When I test the program, the results are that it works fine on Windows 7, partially under Windows Vista and nothing but crashes on Windows XP.
I have ruled out the possibility that it matters if the program is compiled under Windows XP.
Here is what I think is what is going wrong:
CFile myFile;
CMyDoc *pDoc = (CMyDoc *)m_pDocViewTemplate->CreateNewDocument(); // Get a CDocument and cast it
CFileException myError;
TCHAR *arcFileName = new TCHAR[MAX_PATH];
BOOL bTmp = myFile.Open(arcFileName, CFile::modeRead, &myError);
char lpszError[1024];
myError.GetErrorMessage(lpszError, 1024, 0);
_cprintf(lpszError);
_cprintf("\n");
if(!bTmp)
{
_cprintf("ERROR: Unable to open the file!\n");
return;
}
myFile.SeekToBegin();
CArchive myArc(&myFile, CArchive::load, 8192, 0);
myArc.m_bForceFlat = TRUE;
myArc.m_pDocument = pDoc;
pDoc->Serialize(myArc);
I am really at a loss here. I can provide more details if needed.
Thanks in advance.
arcFileName will contain something like: "C:\MyProject\MySheet.K01"
Obviously...
It crashes when run from the IDE on XP? What crash do you get? Does it crash in Debug and Release versions?
Related
I have a large Win API C++ Application that i recently moved from Visual Studio 2010 to 2017. Application compiles, links and runs now, but i find that the window borders are about 2 pixels larger than before.
This is a problem as we implemented docking windows long time ago with 100% own code. Although all sizes are retrieved from the OS using GetSystemMetrics etc. this turned out to need some more specific alignment. It took a lot of development time when developing (for Windows 2000) and retargeting later for Windows 7. Furthermore we have some small windows and the thicker frames just waste space.
So i installed the Windows SDK 7.1 and was able after some tweaks to install that. But i am not able to choose 7.1 in the project settings. Typing in that in the project settings results in
error MSB8036: The Windows SDK version 7.1 was not found.
Although I find a directory named:
C:\Program Files\Microsoft SDKs\Windows\v7.1
Also when trying to re-target the Project, the SDK 7.1 is not listed.
I did a lot of googling and found this and that but no substantial answer. msdn is horrible.
Questions (obsolet, see below):
Is it possible to use VC 2017 with Windows 7 SDK? How?
Is there possibly a different way to keep the geometry used with VC2010?
EDIT:
I don't think that this is a duplicate of Dialog border different after porting code from Visual Studio 6 to Visual Studio 2013 although the link is quite helpful. It turned out, that different values are returned for GetSystemMetrics(SM_CYFRAME). So far I do not see a substantial explanation for that. Please see my own answer and comments.
So let me update the question:
Why does the value returned from GetSystemMetrics(SM_CYFRAME) change when upgrading from VC2010 to VC2017?
What is the root cause?
Is it possible to use VC 2017 with Windows 7 SDK? How?
Yes, but I doubt this is the solution to your main problem.
Is there possibly a different way to keep the geometry used with VC2010?
Yes, just change the minimum subsystem version to pre-Vista value, like 5.01 (for Windows XP 32-bit). For some reason, 5.1 will yield the same result too; the resulting EXE would be the same.
When Win32 Subsystem Version is 6.0 or above, there is a behavior change regarding the window border size. Though I am not aware of where Microsoft has documented about this.
If you still have Windows 7, the difference is also obvious when you are using Windows Basic theme, as shown in this screenshot:
Screenshot added by RED SOFT ADAIR:
It turned out that the problem was as described here:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/eaae1445-264d-487f-aba1-52dfc8abdfe4/getsystemmetrics-difference-in-return-value-for-the-same-input?forum=windowssdk
The value returned for GetSystemMetrics(SM_CXFRAME) changed with VS 2013.
In VS2010 (Window 8.1)
GetSystemMetrics(SM_CXFRAME); // 8 pixels
In VS2013 (Window 8.1, same PC)
GetSystemMetrics(SM_CYFRAME); // 4 pixels
In VC2013 and later the same result will be returned using
GetSystemMetrics(SM_CXFRAME) + GetSystemMetrics(SM_CXPADDEDBORDER);
My windows still had the same frame size. I miss interpreted the root cause.
Still i do not understand how this can happen. By my understanding GetSystemMetrics is a function of the Windows OS. How can this function behave different when changing the compiler? I guess this IS part of the Windows SDK?
By the way, i found, that i can select "Windows 7.1" as the Platform Toolset, but not for the SDK (as i was thinking).
All this is confusing. Can anybody point out the differences and the junctions between SDK and Toolset?
EDIT:
I made a little sample program to prove this:
#include <windows.h>
#include <stdio.h>
int main(int argc, char *argv)
{
printf("GetSystemMetrics(SM_CXFRAME) returns: %d\n", GetSystemMetrics(SM_CXFRAME));
return 0;
}
Compiling with VC2010 results in "8".
Compiling with VC2017 results in "4".
Even if i choose "dont upgrade" for the SDK when migrating to VC2017.
If you dont believe it - try yourself.
If you have any more insights to that - you're welcome. I give you a 500 points bounty!
I'm working in a project building an application with Computer Vision using C++, OpenCV and Visual Studio. I'm no expert in deploying programs to use them on other PCs.
I've made a program which I need to distribute to a certain amount of people and I can't make it work on all the computers I'd like to. The program was written using Visual Studio 2015, it's an MFC Project and the code is written in C++ since I'm using OpenCV.
When it was finished, I tried to run it on another computer and I realized that it won't open. I looked on the Internet and found out that I needed to statically link the libraries, so I did it. Also, when I was looking for information, I found that Visual Studio 2015 builds its projects so you can run the programs on machines with Win7 to Win10. When I learnt that, I tried to open it on PCs running Windows 7, 8, 8.1 and 10. I tested my program in like 20 computers, give or take.
The results? I couldn't make it work for Windows 7, the error ucrtbase.terminate api-ms-win-crt-runtime-l1-1-0.dll showed every time I tried to open it. It also didn't open in one machine with Windows 8 without showing any error message, but it DID open on most of the machines with Win 8.1 and Win 10. The thing is that "most"; there were some PCs (with Win 8.1 and 10) that I couldn't open my program on. I found that sometimes it would show up in the Task Manager for less than a second and then disappear. The most stressful thing is that it doesn't tell me what the problem is, it doesn't show any error message. It just won't open.
I tried using Dependency Walker (both on my PC and one of those that I couldn't run my program on) to see if there's something missing and I got a reeaaally long list of files that the system couldn't find, here's an example:
List 1/11. Something curious is that my program executes just well on my computer and on those I could open it, even though Dependency Walker (DW) tells me that there might be a problem with it. This indicates me that DW is not finding the exact error I'm having.
Another thing I've tried is to compare the things I have installed on my computer and install them on the one I want to execute my program on. I tried installing .NET Framework 4.6.1 just because VS 2015 says that my project was built using it (and I have it installed in my PC and that other one doesn't. Also I tried with .NET 4.6.1 SDK). Nothing changed.
Just look here:
https://msdn.microsoft.com/de-de/library/ms235299.aspx
The quick-and-dirty way would be to copy the DLLs from your redist directory. For my MS VS 2013 it is hidden under the VS installation directory in:
VC\redist\x86
or
VC\redist\x64
...
which depends on your application.
Disclaimer: I'm quite new to the MSFT tech world and only started Windows Phone development a month or so ago.
I am unable to figure out how to log information to the Visual Studio Output window from within a C# and C++ (Direct3D) Windows Phone 8 App. Is this possible?
I am building in debug mode, targeting Windows Phone 8, running in the XDE emulator and my development machine is a Windows 8 box with VS2012 Ultimate installed. My App runs fine, my Direct3D scene renders normally, but I can't log anything! This makes tracing code execution difficult and forces me to use breakpoints (which can be overkill in many situations).
I've been searching far and wide and have tried many methods (OutputDebugString being one of them). I can't see anything on MSDN about this - why is this not documented anywhere?
Yep, it's possible to write debug strings from WP8 C++ to the output window in VS2012. I actually have an example of that here.
1) Invoke OutputDebugString from C++.
void Direct3DInterop::MyButtonWasClicked()
{
OutputDebugString(L"Button was clicked!");
}
2) Before running the app make sure to change to the native debugger from the managed debugger in the project's properties.
I believe the methods in System.Diagnostics.Debug (specifically the overloads of WriteLine()) work...although I haven't tried them with C++ apps.
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!
We've just recently switched our C++ MFC Application from VS2005 to VS2008. Unfortunately in doing so our UI has appearance problems, with things like group boxes appearing blue rather than black, properties dialogs having a white background etc. I presume that in VS2008, MFC has been changed to respect the OS theme (in my case XP default theme). Unfortunately, changing all our controls and our custom toolbars to make the app look decent again is going to require a lot of work.
So, does anyone know if there is a way in code to put the app back in VS2005 mode? I found the following code
typedef void (WINAPI *tSetThemeAppProperties)( DWORD );
tSetThemeAppProperties pSetThemeAppProperties=0;
HINSTANCE handle = ::LoadLibrary("UxTheme.dll");
if (handle)
pSetThemeAppProperties = (tSetThemeAppProperties) ::GetProcAddress(handle,"SetThemeAppProperties");
if ( pSetThemeAppProperties)
{
// call function
pSetThemeAppProperties(0/*dwFlags*/);
}
::FreeLibrary(handle);
Which does stop the XP theme being picked up, but turns off ALL themes and leaves the application looking more dated than it did in VS2005.
thanks
It may be that VS2008 is including a Manifest file in the project that loads the version 6.0 comctl32.dll rather than the 5.82 comctl32.dll... both ship with Windows XP and newer.
Under "Properties->Configuration Properties->Linker->Manifest File", set the "Generate Manifest" option to "No".
Then add your own manifest file if you like, and set it under "Properties->Configuration Properties->Manifest Tool->Input and Output", "Input Resource Manifest".
Just make sure that if you add your own manifest file that it doesn't contain the reference to commctl32 v6.