General and Desktop

@PaulHuber Yes, as per the answer there. The Application Output pane is only for output. I believe current Creator has an alternative "terminal setting" these days, which allows a genuine terminal with input as well as output allowed if you want to use it that way.

@jsulm I have found a way but I don't know if it will be safe and not degrade the performance of the library. DEFINES += FTD2XX_STATIC win32: LIBS += -L$$PWD/Static/amd64/ -lftd2xx INCLUDEPATH += $$PWD/. DEPENDPATH += $$PWD/. win32:!win32-g++: PRE_TARGETDEPS += $$PWD/Static/amd64/ftd2xx.lib else:win32-g++: PRE_TARGETDEPS += $$PWD/Static/amd64/libftd2xx.a I added “DEFINES += FTD2XX_STATIC” before the library file is included.

@Damian7546 said in Convert function to qt notation: qToLittleEndian(val, &le); qToLittleEndian writes the result into the memory block the second parameter points to. And you're passing pointer to QByteArray! It should be: qToLittleEndian(val, le.data());

@wylun If it's a First Chance Exception then as I wrote two posts above.

@IgKh That was it! I forgot I was hacking around and that did it! Thank you!

@sneha_chavan_07 Then please provide more information. Did you install PyQt5 and how? On which OS?

@SimonSchroeder Well, I am doing it (Qt for games) but seems like I am alone, yes ;-)

There are dozens, if not hundreds, of Ubuntu Forums. Let's be bold: millions, if not billions! However, I found no more than three at https://ubuntu.com/#community Ubuntu Forum that can confirm the bug Forums may reference bugs, but the bug tracker is probably more interesting wrt confirmation: https://bugs.launchpad.net This bug currently is a road block for Ubuntu 24.04 on x86_64 in our CI. Not sure if it relates to your issue as well.

I want to hide the default "window title" bar that's on top of the dockwidget. @lansing, stackoverflow.com/revisions/21701604/1 should work: dockWidget->setTitleBarWidget(new QWidget()); Otherwise, maybe follow stackoverflow.com/q/18918496.

It turns out I was simply using a different MinGW version than the one Qt was compiled with, for anyone wondering. Anyway, thanks for the replies.

@RokeJulianLockhart not gonna lie, this was over 12 years ago and I can’t even remember which project this question related to, sorry 😔

It's nice to find out after a few years. My understanding of this error is that qt does not allow qgraphicseffect in parent-child controls to work at the same time. Therefore, a good practice is to turn qgraphicseffect on when you need to use it, using effect->setEnabled(ture), and turn it off when you don't need it. In addition, because my English is not good, the above content is translated from the translation software. Please forgive me.

Running a new instance of an exe from the terminal should not cause some existing instance to close, whatever it does. Do you mean you are running from Creator? I think it might have a setting for "terminate another instance if starting a new one", maybe?

@RokeJulianLockhart if you take the original situation from almost ten years ago, it was for desktop and the dock widget contained an alien widget which did not provide any useful size information. Hard coded size are rarely a good option but you have to make a decision at some point. In between, there has been alternative implementations to the QMainWindow layout system that have been created that might handle that case better. You can also check the implementation of splitDockWidgets to see how the size are computed and how you might (or not) influence it to do a 50/50 split.

QTreeView::resizeColumnToContents(int column) If of interest to anyone in the future, iterating over the columns and applying this is quite trivial: #!/usr/bin/env python3.13 import \ builtins, \ PyQt6.QtWidgets self.tree_widget = PyQt6.QtWidgets.QTreeWidget() tree_widget_header_labels: builtins.list = ["Name", "Location"] self.tree_widget.setHeaderLabels(tree_widget_header_labels) # Iteration: for i in builtins.range(builtins.len(tree_widget_header_labels)): self.tree_widget.resizeColumnToContents(i)

@SGaist Thank you, I get it.

@GrecKo said in QSignalSpy verify emission order: You don't have to use QSignalSpy, you could store the received signals in an ordered list: QStringList receivedSignals; QObject::connect(&inst, &MyClass::started, &inst, [&] { receivedSignals.append("started"); }); QObject::connect(&inst, &MyClass::finished, &inst, [&] { receivedSignals.append("finished"); }); inst.doSomething(); QStringList expectedSignals = {"started", "finished"}; QCOMPARE(receivedSignals, expectedSignals); That makes sense. I figured that using an external mechanism would do the trick, though your idea with a lambda populating a QStringList is far simpler than what I was cooking up. I was hoping for a simple solution, and this looks like it'll be the simplest way of achieving my goal. Thanks!

I entered the following code and it didn't do anything. soReport->setResizeMode(QListWidget::Adjust);

Oh yes, thank you. That was a total thinking failure. What I actually wanted to test was something like that: { Nix nix4(4, "Hello, I'm four"); *nix1 = nix4; } qWarning() << "nix1: " << nix1->display(4); And that works. *nix2 = *nix1; delete nix1 works too Thanks, solved!