I have a problem with launching application after deploy.
Build project, did copy all necesary files in release folder, the move it on another machine (if is important, I built it with MinGW 4.8 32 bits on Windows 8 64 bits and tried to run it on Windows XP 32 bits). However, when I tried to run it, it just shows a small white square.I tried to use Qt Resource System. Created a .qrc file, here it is:
<RCC>
<qresource prefix="/">
<file>qml/Rename_Files/Button.qml</file>
<file>qml/Rename_Files/main.qml</file>
<file>images/file_browser_icon_32x32.png</file>
<file>images/file_renamer_icon_32x32.png</file>
</qresource>
and used resources accordingly:
viewer.setSource(QUrl("qrc:/qml//Rename_Files/main.qml"));
"qrc:/images/file_browser_icon_32x32.png" & "qrc:/images/file_renamer_icon_32x32.png"
On build machine everything works.Now copy again everything on the other machine and try again. No change at all!
Any idea how to solve it?
Not being able to load an image at runtime in a deployment machine is usually a runtime plugin error. If it can't find the appropriate imageformat dll, it won't load the image.
Create a folder called "imageformats" next to your exe and put the appropriate dll's in there to use all the image formats you are using in your program.
Find the dll's on your development machine in
<Qt Install Dir>\<Compiler>\plugins\imageformats
http://qt-project.org/doc/qt-5.0/qtcore/qcoreapplication.html#libraryPaths
http://qt-project.org/doc/qt-4.8/deployment-windows.html#qt-plugins
So you probably need qico.dll.
If the above doesn't solve your problem, you may need to run "depends.exe" on your development machine to see if there are other dlls you need. Also you can do some additional debugging on your development machine to do runtime checks to make sure it can find the image:
Qt Label::setPixmap not working
Hope that helps.
I solve my problem. This thread http://www.qtcentre.org/threads/56250-Empty-window-when-running-application-on-Windows-XP-32-bits?highlight=empty+window contains what I found through my research and Chris' help.
I apologise for very late response.
Related
I am trying to create a UWP app (for Desktop) in Visual Studio 2017 on Windows 10. Everything works fine, I added some UI elements and I can start the app without problems.
I want to incorporate OpenCV (3.4.9) into my app, which I built using CMake and Visual Studio 2017 (following the steps from https://medium.com/#rabbi.cse.sust.bd/how-to-build-opencv-for-universal-windows-platform-uwp-1a642ec09955)
I have checked the library path for each config (I built one for each x64/Debug, x64/Release, x86/Debug, x86/Release).
The problem starts when I start using OpenCV, eg by including "opencv2/opencv.hpp".
I can still build without errors, but when I try to run the app (Run without Debugging in VS), I get the error:
Unable to activate Windows Store app. The activation request failed with the error: The app didnt start
When running the .exe directly, nothing happens (I had to add some DLLs to the folder first).
I have tried the suggestions from the similar questions here on SO, but without luck.
Rebuilding or changing configuration doesn´t help.
I can start the app when including "opencv2/core.hpp", and do
cv::Mat img;
But if I write
cv::Mat img(200, 200, CV_8UC3);
The same error occurs. Writing
cv::Point pt(10, 10);
on the other hand works fine.
I am running out of ideas for things to try..
Ok, so I found the problem. Actually similar to what others with the same issue found:
Visual Studio was unable to find the DLL files for OpenCV. I did suspect that, so I added the bin folder to my path, and copied the DLL files into the project root as well as "ProjectRoot/x64/Release/ProjectName".
But apparently, the DLL files need to be in
"ProjectRoot/x64/Release/ProjectName/AppX"
for a x64 Release build.
If someone has any idea on why it can´t find them through the PATH or in the project root, please let me know.
I guess the reason is related to the fact that the binaries are dependent on the configuration?
Anyway, I can load an image through OpenCV in my UWP app now, so I´m happy.
Hope this saves someone a headache.
I've recently bought a new tower and used third-party software to port across all my development tools (another story in itself), including VB 6.0, all my third-party tools, and Btrieve. The only problem I have with Btrieve is more an annoyance than anything. On this new tower, I have to remember to run my compiled application once before attempting to run it from inside the IDE or else it will not load, and subsequently return a corresponding error when it attempts to open the first file.
If anyone else has encountered this and knows how to fix it, I'd much appreciate it.
After checking this page on Wikipedia I realized that I needed to focus on two files: w32mkde.exe and wbtrv32.dll
By manually running the exe file, it would load the engine and my application would then run in the IDE, but I still had to manually start the exe. The desired and original behavior on my older machine was that running my program in the IDE would automatically launch the sever exe. From the Wiki page, I learned that it was wbtrv32.dll that was actually called by the program, which in turn would call the exe if needed.
I had recentl ported over my old machine to a new tower, and many of the ocx and dll files in \windows\syswow64 did not make it. There seems to be no pattern to which ones, but I had to re-register those as I found them. There must be some link there, because when I copied-over the W*.exe and W*.dll files from my production backup folder to the syswow64 folder, it suddenly worked again. Likely just a corrupt copy of the dll file. I believe the reason that the compiled version ran correctly is because those dll and exe files were installed to the application folder, and were apparently okay, but not being invoked when run from the IDE.
Hope this might help someone else some day.
One of the vb6 project which worked fine in XP machine is not working on Windows 7 64 bit.
When I tried compiling the vb6 project on win7 machine it compiles forever and generates enormous .tmp files.
Update #1: When I tried building the exe using command prompt it worked.Not sure why it happens when I build from VB6 IDE
Update #2: Tried all the alternates like running application in administrator privileges,registered dlls in SYSWOW, etc.
Update #3: When I started with a fresh copy of the application I get mscomctl.ocx could not be loaded error.
Screenshots:
I suspect permission issues. Download the excellent SysInternals NTFILMON utility to see where exactly it fails to process files. Set the filter to only show the processes that belong to VB6.
I found the issue,
There appears to be conflict in DSR files on the project.After removing the dsr files in the project I can able to compile the project.
I am new in programming and I want to install Qt-Jambi in Eclipse in windows 7.
Can you explain it to me with a step-be-step procedure?
I have searched but I didn't find a easy explaining procedure or tutorial.
Thanks in advance
As a QtJambi maintainer, I provide this answer so as to help close off this issue for someone else searching.
There is no official way to install QtJambi system-wide, which might be the reason this answer has remained unanswered for so long. Since there is no answer to the question that was put.
There is an official way to install the Java JRE or JDK that is a well trodden path using the EXE Sun/Oracle release. But largely for Java application space and Java development space there are no official way of doing these things and the matter is largely left upto the application program and package things up and get the "ClassPath" correct for use with the application when that application is deployed.
So all I can advise to you are some ideas/tips on how you might do-it-yourself for development and application deployment.
...
Decide if you are developing for Windows 7 as 32bit or 64bit. If you want your application to work on all windows computers (WinXP/WinVista) then 32bit maybe your choice (as there are not many desktop application that need to use more than ~1.5Gb of memory, which is about the effective usdable memory you will get, if you need this or more then use 64bit).
Once you have decide which environment you are working you need to ensure you have that Java JDK installed. On a Windows 64bit system you can install both 32bit and 64bit JDk/JRE side-by-side. They end up in different directories C:\Program Files\Java and C:\Program Files (x86)\Java.
If you choose to go 32bit then maybe you will also use 32bit Eclipse (and see Trouble installing QT Jambi on a Windows 64 bit system for help with that). This may allow oyu to use the QtJambi GUI designer that was released (some years ago now) for Eclipse IDE.
Now you can select which QtJambi to download from sourceforge (or other download site). This maybe just a ZIP file which you unzip where you want on your system, then setup your development enviroment to point to the JARs provided inside it. It should not hurt to include all JARs in your classpath.
It can be useful to unzip the native JAR (that is the JAR that contains DLL/DSO inside it). Then use the unzipped directory as a -classpath entry to java.exe. The reason for this is that QtJambi will unpack these files since DLL/DSOs can only be loaded by the operating system when they are unpacked as regular files. QtJambi will attempt to unpack everytime you start the EXE which will slow down development.
Other than this take a look at the source of the examples and Launcher provided in the project GIT tree on gitorious (or maybe *-src.jar in the ZIP download).
...
To deploy QtJambi as an application (to give to a 3rd party to use your application) you simply need to ensure the -classpath is setup to include the QtJambi JARs you need.
It is also recommended to deploy the Native JAR unzipped for the same reasons as above during development. The JAR format of this data is more a convienience format to throw it around but an installed should unzip it.
I've got an MSI based install that I've wrapped in an EXE file as per my installation packaging software (which is Wise Package Studio 7.0 SP2).
I've made many changes to the install, and every time I've tested them, they've worked just fine... up until now.
I changed some text on a dialog box for when the installation finishes and now it seems that no matter how/where I run the installation from, it won't take my "new" version. It continues to "think" it's already installed and even shows an older iteration of my dialog text at then end of the removal/repair/modify.
It's almost like it's cached that MSI/EXE somewhere and instead of running the one I've recompiled (and fixed the message/made changes) it continues to run the "old" one from somewhere.
Any idea what to check for/what could be going on here? Is there windows folder I need to go check? I'm on XP SP2.
Try running on a different machine, this will definitely rule out any local caching.
Check that the changes you have made are actually in the MSI. (use Orca to do this.)
Okay, so I tried this using an XP VM and taking a snapshot before installing. Looks like somehow the previous install was corrupt and was somehow caching itself on the original test computer I was working with.
By going to a clean and fresh PC, my changes were there and the script worked as expected. Now, I don't know what happened to cause the installation to cache like that somewhere on the PC, but at least I found a resolution.
I'll update this question with the location of the cached files if I can track them down...
To remove any cached Windows Installer information, you can use MSIZAP. My guess is that you haven't changed the package code so windows sees it as the same version of the installer (I'm not sure about WISE, but InstallShield is usually configured to automatically change the package code each time you rebuild.)
As far as the location of the cached files, this is configurable so have a hunt around in WISE and you should find it.