That sounds a bit odd. inside design area, i can copy & paste all i like.
Also CTRL + drag a widget will duplicate it. (on windows/linux at least)
However, you are right that dragging from hierarchical don't work. but does allow right click and use copy.
I need to return my attention to this issue. The problem at hand is this error when I run configure:
WARNING: Using OpenGL ES 2.0 on Windows without ANGLE.
The build will most likely fail.
Specify -opengl desktop to use regular OpenGL.
I I have my environment variable ANGLE_DIR set to C:\Qt\Static\src\qt-everywhere-opensource-src-5.12.3\qtbase\src\angle. assume that configure is looking for ANGLE source, correct? Or, do I need to build ANGLE libraries before invoking the configure command?
I installed v.4.8.2 alongside v.4.9.0, rebuilt my kit manually (as turned out to be necessary), and...
Exactly the same problem, still.
So maybe v.4.9.0 is a red herring - maybe there's some other problem common to all the systems that have it installed; or maybe there's something else that it breaks when it is installed.
It looks like I need to so something more systematic, uninstalling Qt altogether and then putting the components back one at a time, not using the installer so as to avoid the automatic installation of 4.9.0. That will take some time, though.
Update: The same thing happens on another PC, with the same project. Also tested another, way smaller C++ project - semantic highlighting works there! Restarting QtCreator has no effect. The highlighting worked for the problematic project with the older QtCreator version 4.8.x.
It looks like the QtCreatorDeployment.txt file is only taken into account by CMake Project or Generic Project.
So I created a Generic Project, add the Python file(s) to the .files file, removed all the steps from the Build Settings tab, and configured the Run Settings with a Custom Executable where I set python as the remote executable, and main.py as the command line arguments while enabling Forward to local display.
Thanks again, I've got it working the way I want, though I had to do some extra things.
For completeness and others:
What happens is that if I use your example, the listing.qrc file is created the first time, and not on every build. If I use a fake file as output, the custom compiler is executed everytime, however, when the listing.qrc already exists, and due to not being the output it is probably?? not seen as a pre-target for RCC so it is executed before the custom compiler.
I've tried to add a depends_command or a dependency to a custom target in which I remove the file. Removal of the file works, but now the custom compiler is stuck in a loop it seems. Not entirely sure why.
What seems to work, is to have the files for the custom command explicitly listed in the input, which even makes sense, no input file change, no need to build. But, since the files are created outside the QT project, I do not have a full/explicit listing.
Using $$files(path/*, true) works to get the listing, but now there are many warnings like:
Makefile:1379: warning: overriding commands for target `../../Project/ui/ui.web/listing.qrc'
Makefile:1376: warning: ignoring old commands for target `../../Project/ui/ui.web/listing.qrc'
To get rid of this warning I added the combine option, since there are many inputs but only one output, which again makes sense.
So now I have a setup which only executes the custom command if the input files have changes, or if the output file is missing.
Sure, I just thought that I would check here first to make sure that I wasn't missing something, not least since my experience with creating bug reports hasn't been all that great lately (read: most of them are not being acted upon, if not ignored).
True. This one looks pretty serious, though, it should get high priority. You may want to ask on Qt Creator mailing list, too, to raise bug's visibility.
Also, I compile my programs with CONFIG -= debug_and_release on Windows, which simplifies the output folders (no extra debug and release subfolders). Note that this is only safe with shadow-builds, as on Windows debug and release objects cannot be mixed (another nice source for hard-to-track errors).
That would save you from these $$OUT_PWD/(debug|release) constructs - but you'd need to adjust other build system parts probably.
I faced the same problem with QtCreator 4.9.0 (32-bit, based on Qt 5.12.2) on Windows 10 ver. 1803 (build 17134.472).
For me, switching to python 3(.7.2) made it worse: gdb failed to even start with "Unable to create a debugging engine." in the "Application output" log.
Unsetting the PYTHONPATH env.var. solved it for me (for either a py2 or a py3 main "system" install).
If you need it for some other application (as I did), launching from e.g. a batch file you can set PYTHONPATH for the other app only or, alternatively, unset it (set to empty value) for QtCreator only.
For having PYTHONHOME set (e.g. to "C:\Python27" for python 2.7) and PATH containing the "system" python path (e.g. "C:\Python27;C:\Python27\Scripts;" for python 2.7) I noticed no problem.
Explanation Possible explanation:
The debugger was able to load its python bindings and modules and work (seemingly) correctly when I uninstalled all of my "system" python.
That – together with my initial observation – tells me that my QtCreator uses python 2 with its own set of libraries/modules which got overridden by my "system" python libraries/modules by having PYTHONPATH set, and gdb did not find its own python modules.
There might actually be a problem in gdb or QtCreator, as according to the debugger log –
– gdb seems to add its module paths dynamically to sys.path, which should take place after the effect of the PYTHONPATH env.var., so its value should probably not cause a problem. Could its behavior here be intentionally different to the python docs on env.var.s ?...
@aha_1980 the output is in red, which I think means it knows it is an error.
Here is a sample:
19:31:18: Running steps for project helloworld...
19:31:18: Starting: "/usr/bin/ninja" 3>&1 1>&2 2>&3
[1/3] Generating version.h with a custom command.
[2/3] Compiling C object 'helloworld_debug@exe/src_main.c.o'.
../../src/main.c:85:5: note: each undeclared identifier is reported only once for each function it appears in
ninja: build stopped: subcommand failed.
19:31:19: The process "/usr/bin/ninja" exited with code 1.
Error while building/deploying project helloworld (kit: ARM Bare Metal)
The kit ARM Bare Metal has configuration issues which might be the root cause for this problem.
When executing step "Custom Process Step"
19:31:19: Elapsed time: 00:01.
Looking more closely at the output, I see that it clearly says "The kit ARM Bare Metal has configuration issues which might be the root cause for this problem."
I hadn't configured the compiler in the Kits section of the options.
Having set the compiler correctly, it is now parsing the output! I should have spotted that earlier.
Sorry for resurrecting an old thread.
I had exactly the same problem as @kgregory and managed to get something working by cloning https://github.com/qt-creator/qt-creator , removing the relevant 2 lines from src/plugins/texteditor/texteditor.cpp and building it with qmake -r ; make -j8.
Column editing works now for me on macOS Mojave 10.14.4, the way I was used to it on Linux with Opt+Shift+Arrow keys.
Of course this overwrites the standard functionality of these combinations on a mac, but I consider column editing far superior. If overwriting the standard combinations is the only downside of this solution, I would like to propose making it default.