I'm new to Qt and I want to change to braces coding style in Qt creator on Mac OS from
void foo()
{
....
}
To
void foo() {
}
see https://doc.qt.io/qtcreator/creator-beautifier.html
In short, you have to install beautifier plugin. Each available plugin has it's own settings.
Related
I try to get started with Qt pyside with QML and JS using Qt-Creator IDE. Since the documentation remains vague about debugging capabilities of Qt-Creator I would like to have confirmed, that my debugging experience is expected behaviour.
in .py breakpoints work, but print("some string") doesn't print to application output.
in .qml breakpoint's don't work, neither does console.debug("some string") print anything
in .js breakpoint's don't work, neither does console.debug("some string") print
Is this: Qt Creator does not support mixed mode debugging ? Is PyCharm more suitable?
System: Python 3.8.2,Pyside2 (installed via pip),Qt Creator 4.13.3 Based on Qt 5.15.2
yes, it need mixed mode debug.I use PyCharm and Qt Creator.
You can use PyCharm to show the python log and debug .py , use qt creator to show the js log and debug .qml at the sometime.
First you need Enable QML , see
Next run .py on PyCharm and connect qml port on Qt Creator, see
Final , you can debug .py and .qml
My System: Python 3.9.7,Pyside6,Qt Creator 7.0.1 Based on Qt 6.2.3
I a Qt project, which build perfectly on Windows, but on Mac I'm getting a really confusing error message saying there's a "Redefinition of QObject" in QSSLConfiguration class. I added this line in my .pro file:
macx {
QMAKE_MAC_SDK = macosx
}
but it didn't help. How do I fix that?
Sounds like you are mixing up shared libraries (e.g. debug/release or files with differing compiler settings) in your deployment. Do you manually deploy libraries? Use macdeployqt. From the information you give, we probably cannot solve this here.
I want to write SystemC code using the Xcode IDE. I have set it all up and the code I use for testing my Installation builds just fine, but it runs always into Thread 1: EXC_BAD_ACCESS exception, no matter what I do.
I tried to comment everything out, until only the systemc header include and the sc_main was left. When I tried normal c++ code in a different project, to see if it was a general Xcode problem, it work fine and ran into no exception.
I use this generic Hello World-code to test my Installation:
#include <systemc>
//Hello_world is module name
SC_MODULE (hello_world) {
SC_CTOR (hello_world) {
// Nothing in constructor
}
void say_hello() {
//Print "Hello World" to the console.
std::cout << "Hello World.\n";
}
};
// sc_main in top level function like in C++ main
int sc_main(int argc, char* argv[]) {
hello_world hello("HELLO");
//Print the hello world
hello.say_hello();
return(0);
}
After the code ran for a few seconds, it always crashes with: Thread 1: EXC_BAD_ACCESS (code=2, address=0x7ffeef3ffff8).
EDIT:
My Config:
- SystemC: v2.3.3
- Xcode: v10.2.1 (10E1001)
- Compiler: (I ran gcc --version)
- LLV: v10.0.1 (clang-1001.0.46.4)
- c++: v4.2.1
Im using std=gnu++98 (Compiler Default) as c++language Dialect, everything else ran into build errors.
EXC_BAD_ACCESS happens when system can not return from an execution block, such as infinite loop or recursion.
you should take a look at stack trace in the Debugger navigator and see which function is getting called and never returns OR which function(s) are calling over and over.
Don't forget to run project in DEBUG mode. (NOT release)
If you're using SystemC 2.3.2, you might be running into the following issue (on macOS 10.13 or later): http://forums.accellera.org/topic/6079-make-check-return-fail/. This issue is assumed to be fixed in SystemC 2.3.3.
You can avoid it by compiling SystemC 2.3.2 with ../configure --disable-async-updates ... or by moving to SystemC 2.3.3 and enabling C++11 (might be the default on a recent Xcode version, you can check the value of the SC_CPLUSPLUS macro in your model).
I did it! I built SystemC with Cmake following the steps provided in this answer: Setting up a SystemC project with CMake: undefined reference to sc_core
. In the CMakeLists.txt I set CMAKE_CXX_STANDARD explicitly to 11 and built the project via the command line and cmake.
Thanks for the help:)
On Mac OS X the debug outputs go to the system logger that can be read with the Console Application. But when you are developing outside of Xcode (using QtCreator or just the terminal for example), it's not very practical to check the system logs for debugging.
Is there any way to force MacOS to print the backtrace to the terminal (similar to Linux behavior) without any trick on the application side ??
I'm developing a new feature for Clang so it's a C++ program. And I'm using MacOS 10.13.3.
If you are using qt, then include QDebug and then use qDebug() as follows:
qDebug() << debug_qstring;
And if you are using XCode and ObjC, look for NSLog.
void NSLog(NSString *format, ...);
Also printf in case of C and std::out in case of cpp are always your friends!
I can not change the current directory with QFileDialog with Qt 4.8. The same code works fine on Windows and Mac OS 10.6 Snow Leopard. It also works fine if I don't use the native Mac OS X dialog.
This works:
fn=QFileDialog::getOpenFileName(this,"Select File","/Users/myuser/Desktop",QString(),0,QFileDialog::DontUseNativeDialog);
This doesn't work:
fn=QFileDialog::getOpenFileName(this,"Select File","/Users/myuser/Desktop");
It looks like if most of the time it opens the last path of the last call to getOpenFileName.
Got the same issue with Qt5.2.0 on Mavericks...
I found a work around: append a dummy file name to the directory you want to select.
However, be sure not to do this on Windows because the user will see it.
QString dir = "/Users/myuser/Desktop";
#if defined(__APPLE__)
dir += "/MyFile.txt";
#endif
fn = QFileDialog::getOpenFileName(this, "Select File", dir);
Also, for those like me that instantiate a file dialog because they need more options you can also do:
QFileDialog fileDialog(this, "Select File");
#if defined(__APPLE__)
fileDialog.selectFile(dir + "/MyFile.txt");
#else
fileDialog.setDirectory(dir);
#endif
...
This is a bug in Qt that is reportedly fixed in Qt 5.0.1 and Qt 4.8.4 (though it seems that it still reproducible in 4.8.4 by people (myself included)).
This bug has been reported in JIRA as QTBUG-20771, QTBUG-28161 and finally QTBUG-35779 (which appears to have finally fully resolved the issue in Qt 5.2.1). Here is a link to the patch in Gerrit.