Qt designer does not update the gui - qt

Someone wrote out a GUI in Qt designer earlier and now I have to modify some small parts (i.e. add a button/functionality).
Premise:
I add the new feature/make any modification to the .ui file in Designer.
I can go to edit mode and see that this makes changes to the xml format of the .ui file
Problem:
When I build and run Qt, the old version of the .ui is what is shown (without my feature upgrades).
I tried cleaning everything and running qmake, but to no avail.
Any ideas for why this could be happening?

I had the same problem and it was solved when I disabled "Shadow Build" in "Projects" mode.
UPD:
Still receiving upvotes for this answer makes me sad for 2 reasons
it is trivial
the issue is still there after almost 5 years

I could solve this problem wihtout change Shadow Build configuration.
In my project I want to build with output files into build-ProjectName-Debug
But the QtCreator is not smart to check if are not files moc_FileName.cpp and ui_FileName.h into build directory.
This problem occur because if these files moc_FileName.cpp and ui_FileName.h are into project directory the QtCreator uses them and does not recognize any modification on .ui files.
The solution to this problem was easy to me:
Remove all moc_FileName.cpp and ui_FileName.h from project directory and Rebuild.
These files will be created into build-ProjectName-Debug and all modifications will be there.

When you change a .ui file, someone needs to run uic.exe on the file to generate a header file. For example, for a window called MyWindow.ui, this will generate a file called ui_MyWindow.h.
This is then what is used when the application is rebuilt.
You don't specify how you are building or on what OS, so it is hard to help you on that end. If you are using Visual Studios it is possible to integrate your .ui files into your projects so that when you change any .ui file, all the generated files will be recreated automatically. The same is possible if you are using .pri files.
In any case, I would run:
uic.exe -o ui_yourfile.h yourfile.ui
Please change the names of the files to the ones you are using.
uic.exe can be found in your Qt bin directory.
Then once you have the generated header file, try to find where it goes in the build directory. Then rebuild.

This is what helped me personally, add to qmake file:
UI_DIR = $$PWD

I solve this problem by cleanthenbuild.I find that ,if I checked Shadow Build,qtCreator will use the old .obj,other than generate new .obj even if the ui_xxx.h had been changed,to generate .exe when debug agin.My enviroment is qt5.5 + msvc2013.

I had the same problem and was able to solve it by deleting all the Makefiles in the build directory, then rebuilding from scratch. For some reason, these files are not deleted when you run Clean Project from Qt Creator.

Same problem for me.
Nothing works until I changed the installation from Qt 5.0.2 (MSVC 2010) to Qt 5.0.2 (mingw).
Now it is working again...wired

I experienced the same problem: no ui changes appeared after building.
The problem as mentioned above is that the ui files are not getting remade.
Unchecking shadow build solved the problem for me but only once. After that I could not see subsequent ui changes again. So I rechecked shadow build and deleted the existing shadow build folder. This works consistently now, as long as I delete all the build files. But that's lame. It should be able to detect ui changes and remake the files.
I think this should be logged as a bug in Qt Creator/Designer.

I deleted all auto gen file in source folder. when I unchecked shadow build, auto gen file was created in source folder. after when I checked shadow build, compiler only use source folder's gen file. So I deleted all auto gen file(ui_, moc_) and then ui was updated always.

In my case, the problem was caused by a rename of the .ui file. Qt Creator didn't update the #include for the header file "ui_[name_of_ui_file].h" in the .cpp file corresponding to the form. Anyway, cleaning up all the "ui_*.h" files in the shadow build folder solved the issue (I guess unchecking "shadow build" in the Project tab would produce the same effect).

Have you been playing with the system date or time or they were different from those of your fellow's computer? I was changing the time to some hours later for testing purposes (and compiling the project in the meantime) and after restoring it to current time, the compiled files were not updated because they were newer than the compilation time. Running Clean did not delete those files. Unchecking the Shadow build option only gave me crashes and an untraceable 0xc0000135 error. Deleting manually the moc_*.o and *.cpp files with future date/time from the building directory and compiling the whole project again was the solution for me.

Add the following line into .pro file
UI_DIR = $$PWD

As mentioned above, the ui files are not getting recreated. For me, the easiest solution is just hitting Rebuild instead of Build. No need to go into project submenues each time.
As long as your project is not too big, this is OK (apart from this is an anoying bug that qt has for long years now)

I had the same problem and then realized that I have modified the .pro file manually: that is I made "illegal" thing - moved mainwindow.ui under DISTFILES (by default all ui files are grouped under FORMS).
Returned back to FORMS and now everything works fine

This happened to me when I deleted elements from my form in the designer, but still had those elements referenced in the .cpp file. After I deleted those references in .cpp I was able to rebuild and the compiler stopped complaining.

Related

Qt : no rule to make target after deleting picture

I accidentally permanently deleted one of my picture files today (it was added to the Qt resource file earlier) through File Explorer (not deleting it via Qt Creator). Now whenever I try to build my project, I keep getting a message that says:
No rule to make target "mypic.png" needed by "qrcfile.cpp". Stop
What can I do to fix this problem ?
So I think I found the solution to this. All I did was clicking Clean all, then Build All, then Run qmake. After those steps, I tried running the project and it worked!

Why do I need to remove build directory after changing something in a Qt .pro file?

Every single time I change something in a Qt .pro file (add a new source file, change compile flags, etc...), my changes do not take effect. I am using Qt Creator. The same thing happens on windows (MSVC compiler) and Mac. If i remove build directory, it's ok then. (not counting wasted time for full rebuild)
Could be a bug but as it sounds so trivial it rather feels like I am missing something.
Thanks!
When you change somethng in a *.pro file, you have to re-run qmake on the project, to refresh the files in Qt Creator. You don't need to delete your build folder every time.
But when you delete the build folder, Qt automatically run qmake on the project before running the compilation. Your solution works, but it's a bit overkill ;)
This menu is also available when right-clicking on the project

QtCreator Build doesn't update UI changes in design form

My Qt project uses shadow build.
When I change in MainWindow form ( .ui file), I build the project but my program doesn't update GUI.
If I rebuild all, GUI will be updated. But rebuild is very very slow.
I try creating a new project (an empty QMainWindow with some labels), I modify some texts. I build and GUI is updated.
How can I use shadow build correctly, without a rebuild of all my project?
The same issue occurs if the *.ui file name is changed.
For example, Changing yourUi.ui to myUi.ui.
If that is the scenario, then the ui_*.h should also be changed, that is, yourUi.ui to ui_myUi.h.
close Qt creator, go to your project directory and delete the .pro.user file, open the project again and this time Qt creator will ask you to configure your project by choosing the kit you use to build your project. Select the appropriate kit and press the "configure project" button. Apply your shadow build. I hope it will work.
Have you tried to just run qmake (Build -> Run qmake) ?
Edit
As suggested by a comment, I copied the comment to preserve it.
It seems that QtCreator correctly rebuild the .h file of the ui in the shadow build directory, and then include the ones in the source directory, which is not regenerated. I don't know if this is a bug or an intended behaviour, but a quick workaround can be to build the project in the shadow build directory, copy the generated .h files back in the source directory and rebuild again. This work with my simple project, don't know if can be workable also for bigger and more complex project. Or do not use shadow builds

Getting an all-white screen on deploying Qt Quick demo app Minehunt

To test the deployment process I am trying to deploy the included demo app Minehunt. I am able to get it to run, no crashing or errors, but the screen is all white.
I believe this generally means that I am missing plugins. Dependency walker reports no problems, and I even tried including ALL the plugins from the Qt MingW plugins directory, but no such luck.
Here is what I am including so far; Can anyone advise what else I need to add to get it to run?
Your dlls don't look bad at all. I think, too, that it's your plugins. Even if they are there, there is a good chance, that your program don't find them. Qt is a bit picky where to look by default. You might try qt.conf. This is a small textfile you must create in the folder where your executable lies. It contains the path to your Qt plugins.
For instance, in one of my projects I have the followin folder layout:
Appfolder
plugin
qt
plugins
imageformats
sqldrivers
myapp.exe
qt.conf
...many dlls...
Then I added a qt.conf file to the Appfolder, which has the following content:
[Paths]
Plugins = plugins/qt/plugins
My program is Qt 4, but I don't think this aspect of plugin deployment changed in Qt5.
All my qt dlls are in qt. And I add the following PATH: SET PATH=.\plugins;.\plugins\qt;%PATH%. Works like a charm on any Windows I ever tried.
Edit:
I then created a .bat file, which does:
SET PATH=.\plugins;.\plugins\qt;%PATH%
cd Appfolder
start myapp
This was an ugly quick fix, which I did not have the time to replace with something better, yet.
If application runs and shows blank screen then that usually indicates two things :
All the dependencies (dlls) are probably present and detected properly.
Most probably whats missing is the presence of qml files at the correct location.
In your main.cpp check the path of qml file which you would have given, and see if relatively that folder is present at the same location corresponding to your executable.
Also, instead of running the executable by double clicking, run it through the command line. It might print some messages if it is not able to locate some images/files/other dependencies etc according to the specified paths.
Edit 1 :
Add this flag in the .pro file :
CONFIG += console
It will give the exact debug message in a console once you run the application.

OpenGL Widget works in creator but black when launched from .exe

I have been working on a Qt OpenGL project for a bit now for some school work. I had to re-build Qt 5.0.1 for my windows machine so I could use OpenGL proper. At the end of this project I need to turn over the files and any executables, so I figured I could take the release .exe and stick it in a .zip for use.
I followed instructions online of making sure I place any needed .dll's into the .exe's dir. For my project there are 10:
icudt49, icuin49, icuuc49, libEGL, libGLESv2, Qt5Core, Qt5Gui, Qt5OpenGL and Qt5Widgets
I took these files all from:
C:\Qt\Qt5.0.1\5.0.1\msvc2010\bin
on my system.
Issue is the .exe will run and I get the UI and all. But the OpenGL scene is just black. I can still click objects in the scene, evidently zoom in and out and all that. I assume thats just the Qt translating the commands still. But nothing is visible. I'm unsure what the problem can be because it all works fine when launched from the creator.
EDIT: So, with all the dlls in the release folder, running the project from within creator will also have a black screen, when I remove them, it runs well. So perhaps one of the dll's is just wrong?
Also:
I looked online about publishing with Qt Creator and found not too much aid, said I should start from completely rebuilding Qt Creator staticly, but I'm sure the guide I had followed did this, however I still can't publish from the build menu, so I stuck with the above method.
I suggest, that you open every of the DDLs in your Zip file with Dependency Walker (http://www.dependencywalker.com/). It should display information about dependencies from one of your QtXXX.dll files to other files. If one of the dependencies is missing, you know where to look next. You can also try to open your executable with Dependency Walker. I haven't used the program for a long time so I don't remember if opening an executable is the only way it works. Anyway, here are the reasons why you might want to use the tool: http://www.dependencywalker.com/help/html/overview_1.htm
This question might also be helpful:
At least one module has an unresolved import due to a missing export function in an implicitly dependent module
Good luck!
So the ultimate issue was the use of the correct DLLs. Using something like DependenyWalker can help you to note which DLLs may be missing, however it did nothing in my case.
I had installed Qt once, and also rebuilt, uninstalled and re-installed it. However all the libraries it was calling from as no longer in C:\Qt\Qt5.0.1\5.0.1\msvc2010\bin as expected, it was calling from the github repository where I built it C:\Users\User\Documents\GitHub\qt5. Once this is sorted out, it still required a framework folder and then it works as expected.
1) Copy the correct DLL files to the release folder of the build.
2) Create a folder in the same dir as the .exe named "platforms". (Note: elsewhere has said create plugins>platforms, but this will not work with newer Qt versions)
3) From the same source you got the other DLLs, copy qwindows.dll to the platforms folder you created.
4) Run the executable and enjoy.
As long as the system you're running on is capable of your OpenGL structure, it should be fine.

Resources