General and Desktop

@RobertSommer My answer is for when you use Q_ENUM() for your enum, which I thought was what you were doing. The code you show has no Q_ENUM(). If you expect something about being able to convert a plain C++ enum with no Q_ENUM() then it has nothing to do with Qt. For that you can search c++ enum to string to discover (C++ does not offer it natively). Other than that I don't know about your compiler error. Did you try the single statement code I quoted? Note how the comment there did say: // MyEnum needs to be declared with Q_ENUM macro

Hi, maybe it's a bit too late for a solution, but I had the same problem with Qt 6.9.0. I couldn't start my application in debug mode anymore. It finally helped me to disable the 'Break On' for 'C++ exception' in Preferences -> Debugger -> CDB.

@casina When your QOpcUaClient emits endpointsRequestFinished you can do following in the slot to change the endpoint. void UaClient::endpointsRequestFinished( QList<QOpcUaEndpointDescription> endpoints, QOpcUa::UaStatusCode statusCode, QUrl requestUrl) { for (QOpcUaEndpointDescription& epd : endpoints) { // Connect to unsecure node if (epd.securityMode() == QOpcUaEndpointDescription::MessageSecurityMode::None && epd.securityPolicy().contains("None")) { m_client->connectToEndpoint(epd); } } Maybe your opcua server does not allow a connection to the unsecured endpoint as you try to do. With the above mentioned approach you can select a different endpoint. To me it looks like during building the opcua module cmake was not able to find openssl on your pc. This is required to be able to use secure endpoints. All secure endpoints from your server are annotated with "not supported". https://doc.qt.io/qt-6/qtopcua-build-openssl.html

So, if I read that correctly, then I would normally only call QWindow::setIcon() on Linux? Is that right?

@RobertSommer If you want a model to copy, Python's RotatingFileHandler and more specifically TimedRotatingFileHandler seem to provide what you are speaking about. As you can see it requires a library and a bunch of code to implement, you could write similar using C++ and some Qt calls.

Please see my post on stack overflow and provide a reasonable explanation. I believe this will help in a unsavory way. https://stackoverflow.com/a/79607899/13585636 Respectfully, Joe F.

Hi I didn't have that particular issue but had one related to WA_TranslucentBackground recently : so it has to be cumulated with FrameLessWindowHint, and for my case I also need the permenent stay on top property. If I add the stay on top hint to translucent and frameless, the window becomes fully opaque. If you need opaque components on a transparent window (which is what I was looking for), you might be screwed. Otherwise, you might want to try QWidget::windowOpacity, which is simplier to handle and doesn't suffer flags incompatibilities. I haven't tested it on QtWidgets, but in a QtQuick Window it works without flags (and on top of that a frameless window is more problematic in my case). There seems to be some incompatibility among window flags and attributes, at least for windows but I didn't find any doc from windows about that. I didn't insist.

@SimonSchroeder Well, I mean you can use a QPixmap to code each pixel individually to display an image, but why do that when you can just use .png :D

@Axel-Spoerl said in Invoking a slot from a non-Qt thread: I'd probably go for an interface class, living inside the std::thread, inheriting from QObject and running its own QEventLoop. From what I understand only the calling thread does not have anything Qt-based. In order to emit a signals there is no need to start an event loop inside that non-Qt thread. Only a receiving slot would require an event loop. Or am I wrong about this? The quickest way would certainly be using invokeMethod. However, if you can (and are willing to) using signals is always better. If you don't want to introduce any Qt into that thread (yet) you can have a regular C++ function inside some existing Qt code and call that. This function can either use invokeMethod or even emit a signal for your. If it is inevitable to keep Qt out of your thread (in the long run) it makes sense to create something derived from QObject to be used inside your non-Qt thread. Then you can emit a signal using this object. I don't think you need anything special in the calling thread. emit is just a Qt keyword that gets removed by the preprocessor. From the compiler's point of view emitting a signal is just calling a regular member function. (The member function for the signal is generated by moc.) You need to be careful about object lifetimes. The calling object needs to live long enough for the slot to be executed. If the calling or receiving object in a connect statement is deleted, all queued slot invocations are also removed. Also, as your non-Qt thread does not have an event loop you cannot use deleteLater() to delete the object. If you cannot guarantee that your non-Qt thread runs long enough for the slot to be executed (or rather at least started) inside the Qt thread (and thus cannot guarantee a long lifetime for the QObject-derived object) using invokeMethod is the safest way. Maybe it even makes the most sense to use invokeMethod if you don't rely on member variables of the calling object, but instead hand over all data necessary for the slot as function arguments. It certainly avoid thinking about object lifetimes (and thread lifetimes).

@Saviz dataChanged() signal is the primary reason your GUI knows data has been changed within your model and updates it accordingly.

@aiyolo Merge both transformation (scaling by factor 3 and translation to 5/5) and apply the resulting transformation to your item/point.

@SGaist @Pl45m4 Excellent thanks guys. Now to read up on hash tables.

@RobertSommer said in Socket notifiers cannot send from another thread: Can a signal be set by an inherited receive function, event? Set?! You can emit a signal wherever you can also call a function. But depends on your logic if that makes sense.

@SGaist The header file with all its content: #pragma once #include <QStringList> inline const QStringList paths = { "..." }; inline const QStringList registryKeys = { "..." }; I know that the window is fixed in size, it is my temporal solution to this lag problem.

@Pl45m4 said in Connect , SendMessage, Emit - When should I take what?: @RobertSommer You connect Ink to Controller and Laser the same way. I assume these are printers (or printer software)?! Ink Jet + Laser printers, right?! That is correct.

@Axel-Spoerl said in Timer configuration, the possibilities: Something like that? OK, thanks for the sample.

It was reported to me as a problem. I'll ask if it was an external device and what filesystem it was using. This is on Sequioa 15.4.1 David

Were you able to figure this out?

Thanks for the support. Question answered, connection is made via connect. [image: 015b582f-cd3a-4da0-9740-97292664fb94.png]