Learn what Felgo offers to help your business succeed. Start your free evaluation today! Felgo for Your Business


OverviewFelgo 3 Support (Qt 5) › Bug in ItemEditor/EditableComponent ?

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #16394


    Have some issues with itemEditor and the way values in EditableComponent are bind to the item properties they change.

    Will try to explain.
    I have one itemEditor, one simple Item(id: balance) with one property and one EditableCompoent which changes the balance property.
    Whenever I change the balance property,but not from itemEditor, it is not reflected in the itemEditor.
    But when I change the property from itemEditor itself, it works fine.
    More or less looks like itemEditor is not aware of property changes if it’s done outside.

    Here is mu full example.
    Basically it is a basic template for Felgo games with one simple change to replicate my issue.
    When you click on mousearea I update balance.counter, increase it by 5.
    Bu the item editor doesn’t show it unless I add empty EditableComponent, but it breaks other things.
    Please look at 2 comments I left in the code.

    import Felgo 3.0
    import QtQuick 2.0
    GameWindow {
        id: gameWindow
        activeScene: scene
        screenWidth: 960
        screenHeight: 640
        Scene {
            id: scene
            // the "logical size" - the scene content is auto-scaled to match the GameWindow size
            width: 480
            height: 320
            ItemEditor {
                id: itemEditor
                z: 1000
                visible: true
            Item {
                id: balance
                property int counter: 0
            EditableComponent {
                target: balance
                properties: {
                    "Level": {
                        "counter": {"label": "Counter", "min": 0, "max": 100 },
            // If I uncomment this empty EditableComponent itemEditor will start reflecting external changes of balance.counter BUT this will break things like
            // saving level in LevelEditor, LevelEditor will start saving empty data for EditableComponent, HELP
            //EditableComponent {}
            Rectangle {
                id: rectangle
                color: "green"
                x: itemEditor.width
                width: scene.width - itemEditor.width
                height: parent.height
                Text {
                    id: textElement
                    // qsTr() uses the internationalization feature for multi-language support
                    text: qsTr("Current counter value is " + balance.counter)
                    color: "red"
                    anchors.centerIn: parent
                MouseArea {
                    anchors.fill: parent
                    z: 1001
                    onClicked: {
                        balance.counter += 5
                        // this change by default is not reflected in itemEditor!!!!

    Either it is a bug or I don’t understand how it should work.


    Felgo Team

    Hi Marcin,

    hm, looks like a possible bug on first sight, we’ll run some tests to verify this. Thanks a lot for that short example.




    Hi Alex,

    Any news in this area?
    I think I discovered more issues.
    1. There are some simple cases where levelEditor doesn’t save editableComponent data until some specific things happen.
    2. Also does this feature support multiple levelEditor elements in one Project?
    For me, when I try to use two different instances, calling save on one level editor which exists in the project, even if explicitly I call save method on this one, it calls save method on all level editors. Basically this issues causes saving default levels on all level editors in project.

    Should I create issues for every bit I found?
    Probably would put some simple examples to replicate issues.


    Felgo Team

    Hi Marcin!

    The issue of the property changes not being reflected in the editor is actually not a bug. The editor is designed to allow configuring and storing properties, this goes only one way. The editor controls the property, but does not reflect other changes made to the property.

    About the new issues:

    • Storing Issue: Can you provide a simple example where storing the data does not work?
    • Multiple Level Editors: Is there are specific reason why you need multiple level editors in your project? The general idea is to have one level editor which is used to create, save, load and edit the different levels of your game.




    Hello Günther,
    Thank you for answer and explanation.

    Short answer:
    1. I agree with your design and the limitation of not tracking external property changes.
    2. Case for multiple level editors- laziness 🙂 – case where I was testing both level balancing and 2 different approaches for some solutions.
    In the end you select from menu a level, just one level has different behaviour for something than other.
    But probably can handle this with level editor boolean A/B property.

    But again, I think my approach is not the best here, so I don’t think there is a requirement really to implement this, as of now.
    Maybe I will find something, but before I report it will make sure it is a valid use case and worth implementing.
    3. Potential issues in simple use case.
    I didn’t have time yet but will double check if I can get the base scenario working without issues(once I change how I handle level balancing in my game)
    If I encounter issues will let you know.

    Long answer:
    I started introducing simple level balancing with only EditableComponent, without separate entities balancing,  because it makes sense  in my case and it is going to be only this, no entity balancing the way you show it in examples.
    At the beginning I was mixing live gameplay with level editor on the fly, hence the need for LevelEditor to handle both sources of data(editor and external changes).
    But the more I play with it and more people use it who are not developers(responsible more for level balancing/ux/ui etc) the more I agree with your design.
    In the end separation is needed, either you are now balancing this one level or you are playing the whole game(multiple levels, waves etc).



    Felgo Team

    Thanks for your answers, all clear from my side for now then 😉

    We’ll be in touch once you finish your testing and the final simple use-case!





    Hi Günther,
    I think I managed to get things working almost the way I wanted.
    There are still few things for me to tweak, mostly because my case is not that standard, but I will be fine.
    Won’t propose new things for LevelEditor, for now … 🙂
    Instead I will be waiting for the update with some things I am looking for  (khem, khem, AdMob/Appodeal)



    Small update.
    Normally I mostly “complain” ;p;p
    But I must say, once you put all bits together, can agree with your promo materials:
    Level Editor, together with game network, is f*cking awesome!
    Big time saver and, in the end, was quite easy to implement once you get the design right.
    Can’t imagine how I worked without it for so long time.


    Felgo Team

    Thanks a lot for the praise 😉
    Given your enthusiasm and all the features you’re adding, I’m really looking forward to play your game when it’s done!

    All the best,

Viewing 9 posts - 1 through 9 (of 9 total)

RSS feed for this thread

You must be logged in to reply to this topic.

Qt_Technology_Partner_RGB_475 Qt_Service_Partner_RGB_475_padded