I've just installed Qt Creator 4.6.2 on Windows 10 and when I tried to build the first project I've also experienced a similar problem.
Here's Qt Creator's output:
C:\Program Files\CMake\share\cmake-3.12\Modules\CMakeTestCCompiler.cmake:52: error: The C compiler "C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.14.26428/bin/HostX86/x64/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/rmam/AppData/Local/Temp/QtCreator-WwNhAr/qtc-cmake-cZffZkom/CMakeFiles/CMakeTmp Run Build Command:"jom" "/nologo" "cmTC_2b1c8\fast" The system cannot find the file specified Generator: execution of make failed. Make command was: "jom" "/nologo" "cmTC_2b1c8\fast"
Qt Creator enables users to add entries to the PATH environment variable that are specific to each cmake project through the "Projects" menu -> "Build", and in the bottom part of the form in the "Build Environment" section click on "Details" and add entries to the PATH environment variable.
Having said that, how exactly can Qt Creator fail to include Qt Creator's bin folder in Qt Creator's PATH environment variable?
Just so you know, all debuggers on all platforms (have to) work like this when debugging a UI-event-driven application. When stepping/running to next breakpoint, it executes only the instructions it comes across, and while they do not allow the UI to process events/repaint the visuals will remain "frozen". It actually shows you what what is really going on in your app!
Like @J-Hilk says, only way is temporarily to insert necessary event processing lines into the code you happen to be stepping through. Not ideal for debugging, but a standard issue.
One more thing: this should have been one of my first things I tried, but I ran the debugger and got the following message - "The inferior stopped because it received a signal from the operating system
Signal name: SIGSEGV
Signal meaning: Segmentation fault",
and it pointed directly at my destructor for DataPiece, which simply calls "delete this" (even though I never actually call the destructor in my code, it must be an implicit call).
After briefly looking up this error, I primitively discovered that this generally occurs when attempting to illegally access a register in memory. So then I looked at how I initialized my DataPiece, realizing that I actually wasn't calling any of my constructors. So, I passed it a parameter 'this' to act as the QObject * parent, but this still didn't resolve my SIGSEGV issue.
I understood if I compiled Qt in debug mode the debugger will show the Qt source code that would be unuseful.
As I said, if it is the case that the fault is coming as a result of Qt code executed internally as an indirect consequence of something your code did earlier, what else do you expect to get out of a debugger? Yes, it will show the Qt code. Then in the debugger you can try to understand which list of yours is being accessed.
I don't do cross-compilation, but I presume the way it works is that you are running a native debugger on the target machine (RPi). Are you sure that the source file paths are available to & valid paths from the target's POV?
do you see empty area between QLabels? There are the text which are snipped.
If don't use RichText and use Fixed size policy , then all are good. But I nevertheless can't understand how are work this magic.
Thank you for helping me and sorry to answer you so late. I tried everything but I can not do it. I have not abandonded but I will try when I have all the necessary knowledge. Thanks a lot for your help .