I've just used Desktop Bridge to package three MFC applications for uploading to the Windows Store.
They all work fine but for some reason one of them is unable to open the help file. (Help works fine in the other two applications.)
The problem application works perfectly when run from Visual Studio or by double clicking the executable. But accessing help gives me the following error after being installed from the test AppX package.
Failed to launch help.
I'm able to use Task Manager to locate the installed application location and confirmed that it does contain my help file. In addition, I added code to display the path of the help file on start up, and it displays the correct help path! But no matter what I do, my application cannot bring up help.
Does anyone know if there is anything about the limited privileges of being installed as a Windows 10 app that could somehow limit access to the help file? Or can anyone suggest how to get past the completely useless error message above to get a hint about why it is failing?
You get this error because the .chm file that contains your help content is located in your applications install folder. In the modern Windows app model that folder is locked down so that only processes that are part of your app package can access it. With the MFC framework, however, the help viewer that gets invoked is not part of your package - therefore it can't access the .chm file.
Solution is for your app at runtime (e.g. right after launch) to make a copy of the .chm file in an accessible location (e.g. %TEMP%) and update m_pszHelpFilePath to point to that location. Now the help viewer process should be able to load the help successfully.
Related
After suffer with a lot of problems trying to deploy a Qt/Qml app to Windows 8, as I described in this question: Deploying Qt Qml app to Windows 8 shows me a blank window
I could make it work copying the Qt5Widgets.dll... but it was only working in my own development machine (installing it there, but yet my own machine).
Then I tried to install it in another machine (a VM running Windows 7).. and at first I got error of missing platform plugin... ok, I copied qwindows.dll to appDir/platforms, and it seems to resolved this problem.
But then I got another missing dlls errors (the ones related to VS2010), then I installed the Visual Studio 2010 redistributable package... ok, now the app starts, but with a blank window :(
The qml files and everything are in a resources file, so it should be in the binary.
And I've no idea where to go from there to find this issue.
Any idea what can I do? The weird thing is that it was installed fine in my own development machine.
And my conclusion is that deployment of Qt in OS X is much easier.
I've solved the problem with these steps:
check your qml files path. For example default generated code is the following:
QtQuick2ApplicationViewer viewer;
viewer.setMainQmlFile(QStringLiteral("qml/test/main.qml"));
So qmls should be in "qml/test" folder
check the missing dlls:
download VmMap tool from Windows Sysinternals suite (http://technet.microsoft.com/en-us/sysinternals/dd535533)
compile and run your app in qt creator to get it working like it should
run VmMap and open your running app's process.
sort the lower window by 'Details' - so you'll see all loaded DLLs sorted by path.
copy the missing dlls. It should work now!
I've had also a lot of trouble deploying Qml apps with a blank window too.
In general this site gives useful hints:
https://qt-project.org/doc/qt-5.1/qtdoc/deployment-windows.html
The blank window issue was caused be two different things in my case:
The relative path to the qml files were not correct. I've solved this by storing the qml files in a resource file and then calling them from there.
It seems to be a problem if the application is located on a network drive. I haven't found a solution for that except copying the application to a local folder.
In general I think deploying is a big big pain :-/
I'm trying to deploy my ActiveX Control DLL developed in ATL project in VS2008 (I'm new to this kind of deployment).
Follow some tutorials, I'm trying to create msi file for my control using Setup Project in VS2008. I've set the Register property of Primary Output to vsdrpCOM. It built with no errors, but I got the warning: Unable to create registration information for file named. Although I can install the control in IE, it doesn't work but displayed with a red X icon. I've also tried other Register options but it's no use.
I think my control is still not registered during installation because of the warning.
Could anyone please give me some instruction to solve this? I've spent hours on google :-(
Thank you!
Use the property vsdrfCOMSelfReg.
See http://msdn.microsoft.com/en-us/library/h793hc1y%28v=vs.90%29.aspx.
I have wrote a program which tries to write a file in C:\windows\ directory. I have tested the program in several PCs with winXP, win7 (64 & 32 bit).But when i install it in my client's PC it crashed with the message : TODO ( file description ) has stopped working
Please if anybudy knows any solution then reply me.
The solution is not to write to the C:\Windows folder. You're not working for the Microsoft Windows team.
It is quite awesome that you gave your client a "TODO:..." product? Please edit the version info to reflect your product name~
As for crash scenario:
Check if your application really needs Admin rights, if yes, start with "run as admin" and see it it solves the problem.
View the problem details in either "Stopped working dialog box", or in Windows event viewer. In both, you can see the exception code (like 0xC0000005) and the DLL name. For this you should enable PDB file generation by enabling /DEBUG flag in linker setting (this is not same as _DEBUG macro in compiler settings!).
Put some file-logging or message-boxing (temporary) and see till where program goes properly. Yes, you need to make few changes, build and give again to your client (and please no "TODO" as product name - be professional!).
There are a few possible causes, among them no write access(perhaps the user running the program does not have write access to C:\Windows folder. Try to manually create a file in that location.) or faulty programming.
In any case, you have a few things to try to figure out the problem. If debug is impossible you should put the sensible parts of the code in try catch blocks (for example the part where you write the file). And if error is caught you can output a message about the part where the error is. You should also include a logging solution and add logs in various places of the code. After you install the updated application, when you get an error, look up in the log file to see where the code stopped.
Is it possible you have UAC turned off, but your client doesn't? Or, would the client's user not have administrative rights? A user process would not be allowed to write to the c:\Windows folder. If that's the case, trying to create a file would throw an exception.
The proper place to create a data file would be:
Application Data under the user's folder, if the file is per user.
ProgramData (Win7) or Application Data under All Users (XP), if the file is per application (log or so).
Apart from the issue of permissions the first thing that will cause your application to crash like that is the runtimes not being installed on your client's PC. Does your install package install the MSVC runtimes? If not, have you installed the MSVC redistributable runtimes on that PC?
"I have wrote a program which tries to write a file in C:\windows\ directory. "
That's your problem right there. Don't do that.
Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.
I'm using WMI's CreateProcess() to run an installation bootstrapper process (setup.exe) on a remote machine. The setup.exe is happily able to run .msi packages but for some reason it is not able to run the vcredist.exe packages that are used to redistribute the MS VS 2008 SP1 C++ Runtimes.
What I'm seeing is that the redist package is able to extract itself into a temp folder in the root of the C:\ drive, e.g. C:\a26f91763649ecad76a09d or some such, but after that the process hangs around.
I don't know what to do to debug further - I suspect that there is a modal dialog in the hidden windows station awaiting dismissal, but I can't see what the text is. Process Explorer isn't yielding much either.
Anyone got any suggestion? The problem applies equally in Windows 2000 as in Windows 2008. We used to use a DCOM-based method to launch setup.exe remotely and this did not exhibit the problem.
Can anyone shed any light on what might be going on, or how to diagnose further.
Many thanks,
Stephen
User error! My suspicion about the modal dialog was correct. It seems that invoking the setup.exe files with a relative path somehow caused the command line arguments to get stripped when passed to the nested exe, so they ran in full UI mode! Invoking with a fully-qualified path resolved the problem.