Qt Creator and other tools

@kshegunov said in Funny bug in clang model indication in creator 4.7.0: Probably some bug in the clang parsing. Btw bool myComp (const Vector3d &lhs, const Vector3d & rhs ) bool myComp (const Vector3dddd &lhs, const Vector3dddd & rhs ) should give you ambiguous overload errors. Exactly. That was the reason of my "BTW". I was getting lazy in this heat to redo all the pasting ;) @kshegunov said in Funny bug in clang model indication in creator 4.7.0: @koahnig said in Funny bug in clang model indication in creator 4.7.0: Yes, the example does not compile directly, because some representations are duplicated, but that is not the origin of the problem. OT: That's a very odd way of comparing vectors ... I wouldn't expect it to really work properly. The myComp name stems from the reducing to minimal case activity. The original naming is in the top post and it represents better what is done. For sure the comparison for standard vectors would be really odd. However, the routines are implemented locally with a specific application where exactly this case is repeatibly required respectively sufficient. ;)

So, I managed to do this like that: Tabbed::Tabbed(TabbedBar *tabbedBar) : QWidget(nullptr, Qt::FramelessWindowHint) { QPalette palette; TabbedView *tabbedBarGhost = createTabGhost(tabbedBar); palette.setBrush(this->backgroundRole(), QBrush(tabbedBarGhost->tab->grab())); this->setPalette(palette); this->setGeometry(tabbedBarGhost->tab->geometry()); this->setWindowOpacity(0.5); delete tabbedBarGhost; } TabbedView *TabbedGhost::createTabGhost(TabbedBar *tabbedBar) { TabbedView *tabbedBarGhost = new TabbedView(nullptr); int index = tabbedBar->currentIndex(); QString text = tabbedBar->tabbedView->tabText(index); QWidget *widget = new QWidget; tabbedBarGhost->addTab(widget, text); tabbedBarGhost->setWindowOpacity(0); tabbedBarGhost->show(); return tabbedBarGhost; } A TabbedBar is inherit of a QTabBar A TabbedView is inherit of a QTabWidget

Yea, the 3.3.8 qmake doesn't generate the pro file dependencies for windows makefiles. I took a look at what Qt5 outputs and it's just like the a, ab, abc style. The dependencies I have go to a depth of 5 not 3. Maybe that's the issue. Otherwise there must be some subtlety I'm missing. Maybe it's because I have an extra layer of targets or something. EDIT: Looks like the extra layer of targets was the issue. If I just use the generated sub-* targets and for each sub- add it's dependencies in before it's existing "makefile dependent" it seems to build via jom fine.

Bump. I cannot debug Qt on Mac, and the answers from here also don't work, not even symlink to /Users/qt/work/qt/ : https://stackoverflow.com/a/46269571/634821 Qt 5.11.1, Qt Creator 4.7.0.

Thanks - disabling the plugin works like a charm.

@hskoglund hi That was also my feeling with uic failing but i was not sure how to go about debugging it. and i recalled the .sh file and though it might set something in there but turns out normally it was not used but kinda sounded like expected to be used with LD_LIBRARY_PATH conflicts but it was unclear to me what it actually did but i assumed it to be safe to try :)

@TheTobruk you may want to take a look at this document.

@Robert-Hairgrove I had a Déjà-vu when I read the bugreport :)

I still have the issue with QtCreator 4.7.0. This is boring when the assert comes from Qt. At least using qInstallMessageHandler works fine. Windows 10, with Mingw and Qt 5.10.1

@TheTobruk said in How do SIGNAL or SLOT know which object I am referring to in a connect function?: connect(ui->horizontalSlider, SIGNAL(valueChanged(int)), ui->progressBar, SLOT(setValue(int))); SIGNAL() / SLOT() are macros which return a char*, which is then used by Qt (MOC) for static lookup in a list. So the (cleaned up) method name is searched in the meta-object of the object you passed in the parameter before. You may also checkout the new signa/slot syntax (introduced with Qt5), which also accepts function pointers. The old syntax is basically the same, but the "dereferencing" of the function is done each time during runtime and also string based. connect(ui->horizontalSlider, SIGNAL(ui->horizontalSlider->valueChanged(int)), ui->progressBar, SLOT(ui->progressBar->setValue(int))); following your thinking this would actually call the method, which isn't intented.

In general as for all applications it would be through QSettings on windows. For addElevatedOperation you would need to write your application or to use a command line based regedit

I am so dumb :D

@kkoehne Ah, OK you are right. It is limited to release mode. When switching to debug and rerun qmake it is gone. The only solution would be to have different diagnostic configurations per kit. At the moment I have added "-Wno-zero-as-null-pointer-constant" to a copy of the built-in settings. This solves the problem with the warning at the time being.

Ok thanks :)

@PbvS said in Clang Code Model - QtCreator 4.6.1 vs 4.7.0: I'm using cmake. Ok, I'm out here... Tried using add_definitions("-std=c++14") as well as set(CMAKE_CXX_FLAGS "-std=c++14"). Found on the internet also another approach using add_compile_options(-std=c++14) but also no luck. The flags needs to be passed to the Code Model - no idea how this works for Cmake. You might also ask this question on the Creator mailing list... Regards