[GH-ISSUE #147] How to get access to raw textDocument? #91

New issue

Open

opened 2026-05-05 11:04:15 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 11:04:15 -06:00

Owner

Originally created by @vadi2 on GitHub (Jun 28, 2019).
Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/147

Pretty specific question, but I need to implement syntax highlighting in my application which requires access to both the rich text and plain text contents of a TextField. The way to retrieve it is via textDocument() - but as discovered here (https://github.com/qmlnet/qmlnet/issues/138), not all QML methods are actually invokable, which is a roadblock.

I'd like to still stick with managed hosting for the time being. What's the way forward to make it work? Is it possible to add a custom binding to Qml.Net for this textDocument() function?

Originally created by @vadi2 on GitHub (Jun 28, 2019). Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/147 Pretty specific question, but I need to implement syntax highlighting in my application which requires access to both the rich text and plain text contents of a TextField. The way to retrieve it is via [textDocument()](https://doc.qt.io/qt-5/qml-qtquick-textedit.html#textDocument-prop) - but as discovered here (https://github.com/qmlnet/qmlnet/issues/138), not all QML methods are actually invokable, which is a roadblock. I'd like to still stick with managed hosting for the time being. What's the way forward to make it work? Is it possible to add a custom binding to Qml.Net for this textDocument() function?

gitea-mirror commented

2026-05-05 11:04:17 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Jul 9, 2019):

Doing this would require bindings for QQuickTextDocument, QTextDocument, QTextBlock, QTextCursor, etc.

We do support interacting with QObjects now (with INetQObject), but some types don't derive from QObject (such as QTextCursor).

Considering this and the effort, I think it might be a better approach to create a native derived QML component that exposes the methods needed in a way that is friendly to the .NET interop layer.

@pauldotknopf commented on GitHub (Jul 9, 2019): Doing this would require bindings for ```QQuickTextDocument```, ```QTextDocument```, ```QTextBlock```, ```QTextCursor```, etc. We do support interacting with QObjects now (with INetQObject), but some types don't derive from QObject (such as QTextCursor). Considering this and the effort, I think it might be a better approach to create a native derived QML component that exposes the methods needed in a way that is friendly to the .NET interop layer.

gitea-mirror commented

2026-05-05 11:04:18 -06:00

Author

Owner

@vadi2 commented on GitHub (Jul 9, 2019):

What do you mean by a native derived QML component?

@vadi2 commented on GitHub (Jul 9, 2019): What do you mean by a native derived QML component?