General and Desktop

@Khamza
First to answer your question. Your new code delays the update till after the text edit has been shown. In that sense it is similar to the QTimer approach. For unknown reason you are claiming the code does not work correctly until after the text edit has been shown.

There are cases in Qt which this is necessary. In particular sizes of widgets are not calculated till they are actually shown, so code which requires to know a size is often delayed in one of the above two fashions.

HOWEVER I was never convinced by your assertion "The function itself is called but neither text is inserted nor block format changed:". While I could believe that possibly an operation on textCursor() might require the text edit to be shown I never thought that insertPlainText() for sure would depend on that. It should be callable any time, including e.g. during construction.

I have now had time to create a minimal repro. Here are the 3 files:

#include "passwordshowarea.h" #include <QApplication> int main(int argc, char *argv[]) { QApplication a(argc, argv); PasswordShowArea w; w.show(); return a.exec(); } #ifndef PASSWORDSHOWAREA_H #define PASSWORDSHOWAREA_H #include <QTextEdit> class PasswordShowArea : public QTextEdit { Q_OBJECT public: PasswordShowArea(QWidget *parent = nullptr); private: void init(); void updateBlockFormat(); }; #endif // PASSWORDSHOWAREA_H #include <QAbstractTextDocumentLayout> #include <QTimer> #include "passwordshowarea.h" PasswordShowArea::PasswordShowArea(QWidget *parent) : QTextEdit(parent) { init(); //doesn't work updateBlockFormat(); // works - gpt4 suggest // QTimer::singleShot(0, this, &PasswordShowArea::updateBlockFormat); } void PasswordShowArea::init() { // QObject::connect(document()->documentLayout(), &QAbstractTextDocumentLayout::update, // this, &PasswordShowArea::updatePasswordShowArea); setTextColor(palette().color(QPalette::Text)); } void PasswordShowArea::updateBlockFormat() { insertPlainText("Some text"); QTextBlockFormat fmt = textCursor().blockFormat(); fmt.setTextIndent(20); fmt.setLineHeight(fontMetrics().height() * 2, QTextBlockFormat::LineDistanceHeight); fmt.setBackground(Qt::red); textCursor().mergeBlockFormat(fmt); }

I have made couple of tiny tweaks where I did not have all of your code. I added fmt.setBackground(Qt::red); so that we had something to see. And here is what I get:

Screenshot 2024-12-21 093554.png

You can see that not only do I get the inserted text but I do also get the QTextBlockFormat changes. Identical if I change it to only call updateBlockFormat() on the delayed timer. Ubuntu 24.04, Qt 6.4.2.

Sooo.... I suggest you try just this code.

@Pl45m4 Thanks for your reply!

I get this part, until now I took it for granted, but I want to have a better understanding of the under the hood mechanisms.

Eg from the docs:

When an event occurs, Qt creates an event object to represent it by constructing an instance of the appropriate QEvent subclass, and delivers it to a particular instance of QObject (or one of its subclasses) by calling its event() function.

So if I have let's say 3 buttons, how does Qt know for which of them the os/native event is intended?
Does it query child widgets via childAt(some coords) on the active window?

And similarly for key press events, does it go from top level window and finds the child widget that currently has focus?

This delivery of the event is the thing that puzzles me, how does it pick the exact widget to call event() on.

... and please properly format your code with the code tags so others can read it.

@Christian-Ehrlicher I incorrectly assumed that QByteArray would always create a deep copy of the data which was not true for QByteArray::fromRawData (documented behaviour, that I didn't read). So just wanted to confirm if this would behave as intended.

@Christian-Ehrlicher said in QChronoTimer doesn't work as expected:

/edit: Looks like it's a windows only issue which will be fixed in the near future.

Good, so I am not going mad then :)

@fokhagyma said in How to make a child widget be transparent for mouse events?:

But if I set Qt::WA_TransparentForMouseEvents only for widget Y, then it doesn't work

"Doesn't work" is not a helpful description of the issue. What happens exactly?
Ideally you create a minimal example which reproduces your situation below.

@JonB
Oops! My Bad :)
The solution worked. Thank you for your patience.

@hskoglund -DCMAKE_OSX_ARCHITECTURES="arm64" did not work; the additional command in your post fixed the issue. Thank you.

@Asperamanca I have set that flag in QML. But even if that was the only problem in my case, I don't understand why Qt based apps don't even register taps as clicks by default like GTK does.

Here's the code for my simple app.

import QtQuick import QtQuick.Window import QtQuick.Controls import QtQuick.Dialogs Window { width: 640 height: 480 visible: true title: qsTr("Hello World") flags: Qt.WA_AcceptTouchEvents Rectangle { id: button signal clicked property alias text: buttonLabel.text height: 50 width: 150 radius: 3 color: "gray" TapHandler { id: tapHandler onTapped: console.log("clicked2") } MouseArea { anchors.fill: parent onClicked: console.log("clicked") } Text { id: buttonLabel text: "Click Me" color: palette.buttonText anchors.centerIn: parent } } }

You really should check that your various QFile open calls succeeded. QSslKey may be the one complaining, but your certificates may be null.

Hi,

For the palette case, the style used can ignore it to ensure the application follows the OS standard.

As for the stylesheet, one issue is that the second call replaces what you set with the first one.
You need to set one stylesheet that contains all the changes you want to apply to that widget.

One million rows is nothing, but the trick is of course to have a data model that is well suited for it.

In my system where I'm throwing hundreds of thousands to millions rows of data at a QTableView I have:

Data that has been organized for quick loading ahead of time System that provides quick access to data without creating objects or having allocate stuff with new.

Basically the data is split into chunks that are stored on disk. Each chunk is then memory mapped and each chunk contains "records". Since the records can have variable size each data chunk has a header and and offset table which stores a starting offset for reach record in the data part of the chunk. (You can think of this as a jump table)

So when a QTableView needs to display any particular row it all essentially boils down to taking a base pointer to a chunk of data and then reading data at offsets relative to the base pointer.

The system is extremely fast.

@jennif56 said in Qt6 upload multiple files:

is always the last one in the loop ("C:\notice_lego\4656079.pdf")

What do you expect? Since QNetworkManager is async your loop is already done when the download of the first item finished.

QNetworkAccessManager* man = new QNetworkAccessManager( this );

You create a new QNetworkManager here in every call ...

connect(man, SIGNAL(finished(QNetworkReply*)), this, SLOT(reply(QNetworkReply*)));

Please use the pmf style syntax for connects as shown in the documentation.

And while you're at it you can pass the filename in a lambda

void MainWindow::getPdf(const QUrl &url, const QString &filename) { auto rpl = man->get(QNetworkRequest(url)); connect(reply , &QNetworkReply::finished, this, [this, rpl, filename]() { reply(rpl, filename); }); }