General and Desktop

qmake simply don't know these options and issues a warning. Nothing more.

Hi, one thing that comes to mind is to trigger the fit in view with showEvent as well Do you mean the QFrame that contains your QGraphicsView ? Modify the margin/spacing of the layout

Could be. We are currently trying to fix it with cppcheck --project=compile_commands.json ... . Lets see if it works.

@SGaist By hardware 3d graphics I mean code that uses GPU instead of CPU, and if possible not only for 3d but also for 2d as my project uses lots of triangles that it needs to move/link/rotate/scale and also check for collision. For the moment I'm using my own classes for Vector 3d and 4x4 Matrix, I tried to use Qt classes equivalents but without success (mainly because the code I'm using needs a vector 3d with a fourth member). And I also have a 2d Triangle class, those three classes could maybe be replaced by code using the GPU. I will first try to do like Pl45m4 said, use a Vulkan rendering backend or a Rhi, things that are absolutely new for me, so that I could keep my existing widget code, but if needed or simpler I'll start using Qt Quick. For sure I'm looking at all available examples projects.

@nicker-player You can set an application icon as explained here. But do you really want to change it when the window is minimized so you have another icon than normal?! The topic title sounds like it

sigh. i guess these are the last of the good ole' days

@Pl45m4 said in QSqldatabase "correct" usage: Check the Qt Examples for related stuff. Yep, I'm looking at qsqlbrowser from Qt5 Examples' tree (I still have this old one around) and I think I'm beginning to understand the whole thing! We simply use the QSqlDatabase::addDatabase( driver, conn_name ) wherever we need to start the connection and keep using QSqlDatabase::database(conn_name) whenever we need to access the database! To close the database we do db = QSqlDatabase::database(conn_name) followed by db.close() and to destry the whole thing we do a QSqlDatabase::removeDatabase(conn_name). I think I'll close the thread and mark it as solved.

I have opened a ticket on the Qt bugtracking site. I would like to understand definitively if I am missing something or if I have run into a bug. In the mean time I worked around my problem changing a little the layout and using a combination of QFormLayout, QHBoxLayout, and QVBoxLayout, which seem to respond correctly to the expansion directives. Each row of the QFormLayout has the following structure: +------------+---------------------------+ |label |+-HBoxLayout-+------------+| | || |+VBoxLayout+|| | || ||<-button->||| | || label |+----------+|| | || accommo- ||<-button->||| | || dating |+----------+|| | || a || ^ ||| | || pixmap ||SpacerItem||| | || || v ||| | || |+----------+|| | |+------------+------------+| +------------+---------------------------+ I just set the fieldGrowthPolicy of the QformLayout to ExpandingFieldsGrow and the sizePolicy of each widget to QSizePolicy::Policy::Ignored for both the directions.

I was able to fix it (at least on the systems we use for testing) by setting the QVTKOpenGLNativeWidget::defaultFormat() format profile to QSurfaceFormat::CoreProfile instead of QSurfaceFormat::CompatibilityProfile. This seems a bit counter intuitive, since it appears to be more compatible, but I'm happy nevertheless... auto format = QVTKOpenGLNativeWidget::defaultFormat(); format.setProfile(QSurfaceFormat::CoreProfile); QSurfaceFormat::setDefaultFormat(format);

That's a very interesting question, thanks! @Christian-Ehrlicher said in Including qfutureinterface.h cause compile error "Error C7683 you cannot create a reference to 'void'": a more recent version of this header to see if it was fixed No dice on that, the void specialization is there even up to Qt 6.9 - https://github.com/qt/qtbase/blob/dev/src/corelib/thread/qfutureinterface.h#L510 @Christian-Ehrlicher said in Including qfutureinterface.h cause compile error "Error C7683 you cannot create a reference to 'void'": a c++ construct which is no longer accepted with a recent compiler The thing is, that void references are not, and never were, valid in C++. However they are not an error in any compiler I checked if they only come up in an uninstantiated template, including in explicit specialization as long as it doesn't actually get used. Including in MSVC in regular C++ mode: https://godbolt.org/z/rroMY86zb But the moment MSVC gets put into C++/CLI mode, it becomes an error - https://godbolt.org/z/eWeEvPqK9 I don't know nearly anything about C++/CLI but it appears that it has some different rules regarding template instantiation (though it shouldn't be that surprising, hybrid languages like C++/CLI and Objective-C++ are not C++, they are different languages). Some template trickery that C++ uses appears to be incompatible with those rules. @LJN_leaper I'm not sure where that leaves you. Maybe you can file a bug report, but direct use of QFutureInterface is already a quite advanced use case. Your best bet is probably to try and isolate its' use into a pure C++ file of your project.

okay the real culprit seems to be that when debugging my app, sometimes i kill the app to keep editing the code, but the killed app turns into a zombie instead of getting killed. so it's lurking in the background, keeping the DB open. I'm still not sure why the new run of the app will hang when attempting to open the DB, i'd'a thought it would return immediately with an error. solution is to try to force kill the zombine, or sometimes quitting and re-running Qt Creator helps, or as a last resort, duplicate the DB, trash the original DB, and rename the dupe to be the original name

Here is the solution: https://github.com/libxcc/QWidget-Admin-Drag Obviously, Qt does have some problems under administrator privileges. The drag-and-drop method used by Qt can display some icons on the interface, but it cannot respond when the administrator is in the administrator's role. So we can only use alternative methods to bypass it and send events ourselves. The disadvantage is that the icon cannot be displayed. Alternatively, we can use Qt's method to add an icon, but I did not deal with it.

That's the reason we request a mre 🙂

@mzimmers said in How to increase object file section capacity: and is this the preferred syntax Yes

You should use a debugger to see where it really crashes and if you can reproduce it, create a minimal, compilable example so we can also take a look on it.

@SGaist Thank you very much. I read https://doc.qt.io/qt-6/qdbusdeclaringslots.html#delayed-replies before asking this question, but that wasn't what I was looking for. The D-Bus adaptors in my project are automatically generated with CMake, and the behavior isn't correct when I directly use the extra QDBusMessage parameter at the end of the search() parameters. And I figured out how to do it after a few tries. The nitty-gritty of solving the problem is using Q_EMIT to send an async completion signal to the client, with the results passed along at that point. Here is a simple example to demonstrate the solution: public slots: // Asynchronously search Q_NOREPLY void async_search(QString keywords) { ... // Pass the results and notify the client once the time-consuming logic is finished Q_EMIT asyncSearchCompleted("test result"); } Q_SIGNALS: void asyncSearchCompleted(const QString& result); To handle the results on the client side, we connect the signal to a slot: QDBusInterface *iface = ...; connect(iface, SIGNAL(asyncSearchCompleted(QString)), this, SLOT(handleSearchResult(QString))); public slots: void handleSearchResult(const QString &result) { qDebug() << "Received async search result:" << result; }

Maybe this bug: https://answers.microsoft.com/en-us/windows/forum/all/bluescreen-error-code-d1-bsod-windows-11/2f50a875-290d-44c5-85dd-e0c2db4b0a1d