[GH-ISSUE #101] Added interfaces to get notifications when a component is created/destroyed. #57

New issue

Closed

opened 2026-05-05 11:02:45 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 11:02:45 -06:00

Owner

Originally created by @pauldotknopf on GitHub (Dec 27, 2018).
Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/101

public interface IQmlComponentCreated
{
    void QmlComponentCreated();
}
public interface IQmlComponentDestroyed
{
    void QmlComponentDestroyed();
}
public class MyType : IQmlComponentCreated, IQmlComponentDestroyed
{
    public void QmlComponentCreated()
    {
        // Called when a QML component is created.
    }
    public void QmlComponentDestroyed()
    {
        // Called when the QML component is destroyed.
    }
}

Item {
    MyType {
        Component.onCompleted {
            // Internally, QmlComponentCreated will be called
        }
        Component.onDestroyed {
            // Internally, QmlComponentDestroyed will be called
        }
    }
}

This will allow people to perform initialization, attach/deattach event handlers, etc.

Originally created by @pauldotknopf on GitHub (Dec 27, 2018). Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/101 ```c# public interface IQmlComponentCreated { void QmlComponentCreated(); } public interface IQmlComponentDestroyed { void QmlComponentDestroyed(); } public class MyType : IQmlComponentCreated, IQmlComponentDestroyed { public void QmlComponentCreated() { // Called when a QML component is created. } public void QmlComponentDestroyed() { // Called when the QML component is destroyed. } } ``` ```qml Item { MyType { Component.onCompleted { // Internally, QmlComponentCreated will be called } Component.onDestroyed { // Internally, QmlComponentDestroyed will be called } } } ``` This will allow people to perform initialization, attach/deattach event handlers, etc.

gitea-mirror

2026-05-05 11:02:45 -06:00

closed this issue
added the
todo

help wanted
labels

gitea-mirror commented

2026-05-05 11:02:50 -06:00

Author

Owner

@MaxMommersteeg commented on GitHub (Dec 27, 2018):

Would be of great value when added to Qml.Net. For my projects I currently add an Initialize function for all .NET types so I can call it manually from QML. Which feels a bit hacky.

Currently scanning the code and am really curious on how you would add functionality like this.
One way might be leveraging QML's inheritance functionality. We could wrap every custom .NET object in a base QML type that does the following part:

Component.onCompleted {
    // Internally, QmlComponentCreated will be called
}
Component.onDestroyed {
    // Internally, QmlComponentDestroyed will be called
}

@MaxMommersteeg commented on GitHub (Dec 27, 2018): Would be of great value when added to Qml.Net. For my projects I currently add an `Initialize` function for all .NET types so I can call it manually from QML. Which feels a bit hacky. Currently scanning the code and am really curious on how you would add functionality like this. One way might be leveraging QML's inheritance functionality. We could wrap every custom .NET object in a base QML type that does the following part: ```qml Component.onCompleted { // Internally, QmlComponentCreated will be called } Component.onDestroyed { // Internally, QmlComponentDestroyed will be called } ```

gitea-mirror commented

2026-05-05 11:02:52 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Dec 27, 2018):

It would have to be done in NetValueType<N>, which services as the entry point of created .NET types in QML. See here.

But yeah, it looks like it might be difficult to attach to those specific signals without the user of private headers.

I posed the question of the Qt Forums here.

If that doesn't pan out, we should just use NetValueType::NetValueType and NetValueType::~NetValueType and rename the above interfaces to indicate that they are just the constructor/deconstructor of the wrapping native type.

@pauldotknopf commented on GitHub (Dec 27, 2018): It would have to be done in ```NetValueType<N>```, which services as the entry point of created .NET types in QML. See [here](https://github.com/qmlnet/qmlnet/blob/develop/src/native/QmlNet/QmlNet/qml/NetValueType.h#L16). But yeah, it looks like it might be difficult to attach to those specific signals without the user of private headers. I posed the question of the Qt Forums [here](https://forum.qt.io/topic/98009/listening-to-attached-component-oncompleted-and-component-ondestroyed-from-c-q_object). If that doesn't pan out, we should just use ```NetValueType::NetValueType``` and ```NetValueType::~NetValueType``` and rename the above interfaces to indicate that they are just the constructor/deconstructor of the wrapping native type.

gitea-mirror commented

2026-05-05 11:02:53 -06:00

Author

Owner

@MaxMommersteeg commented on GitHub (Mar 6, 2019):

Does dd79428e86 mean this is ready? Would love to try this out on my so-called "controllers" to get rid of ugly Initialize functions.

@MaxMommersteeg commented on GitHub (Mar 6, 2019): Does https://github.com/qmlnet/qmlnet/commit/dd79428e868e5255be12d98075c98f47f1febaf3 mean this is ready? Would love to try this out on my so-called "controllers" to get rid of ugly `Initialize` functions.

gitea-mirror commented

2026-05-05 11:02:54 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Mar 6, 2019):

Yup. It isn't released yet though, you'd have to build from the latest bits.

@pauldotknopf commented on GitHub (Mar 6, 2019): Yup. It isn't released yet though, you'd have to build from the latest bits.

gitea-mirror referenced this issue

2026-05-05 11:20:31 -06:00

[PR #57] [MERGED] Readme for PhotoFrame #192