QML private properties



  • Greetings,

    In Qt 4.8 RC, I'm declaring a private property like this:
    @property bool __test: false

    on__testChanged: console.debug("Hi !")@
    I'm getting that:

    bq. PanelRelated.qml:23 Cannot assign to non-existent property "on__testChanged"

    Does anybody know why ?



  • So

    bq. on__testChanged

    (as in example) or

    bq. on__textChanged

    (as in error message)

    May be it is just a typo in your code?



  • Hi Vass.

    My bad. Fixed. Still not working though.

    Have you tried on your side ? Does it work for you ?



  • Hi,

    It works for me (though I tested in Qt 5) if I capitalize test, i.e. on__TestChanged. I'm not sure if this is documented behavior or not.

    Regards,
    Michael


  • Moderators

    Capitalising first letter is documented, but here - strictly speaking - first letter is '_'. Would be a good idea to add info about this behaviour of private properties to the documentation.



  • Well, depends on if you classify _ as a letter or not ;-) QChar::isLetter() says no.

    I guess this applies to signals as well, doesn't it? So <code>signal __someSignal</code> results in a <code>on__SomeSignal</code> signal handler.


  • Moderators

    :) Ok let's say I meant first character, not letter.

    By intuition, I would say that if first character is not a letter, then the first actual letter should not get capitalised. But it seems this was designed in an other way. That's why I think it good to be added to docs.

    Lukas - I've tried it with signals, and the answer is negative. Example:
    @
    signal __queueOrder (string orderName, real newX, real newY)
    on__QueueOrder: ActionLogic.queueOrder(orderName, newX, newY); // ERROR!
    on__queueOrder: ActionLogic.queueOrder(orderName, newX, newY); // CORRECT!
    @

    And now this looks like inconsistent behaviour. Would be nice if the principle was the same for properties and signals. Should we fill a bug report, or maybe was that fixed in Qt5? I'm too busy now to try this in Qt5, even though I have it compiled.



  • [quote author="sierdzio" date="1325581128"]By intuition, I would say that if first character is not a letter, then the first actual letter should not get capitalised. But it seems this was designed in an other way. That's why I think it good to be added to docs.[/quote]

    If this is the intended behaviour it definitly should be added to the docs for clarification. I've added a docnote to "Introduction to the QML Language":http://developer.qt.nokia.com/doc/qt-4.8/qdeclarativeintroduction.html for now where the captialization is mentioned.

    [quote author="sierdzio" date="1325581128"]Lukas - I've tried it with signals, and the answer is negative.[/quote]

    That's rather strange and I would have guessed that there is just a single piece of code that is resposible for capitalization so the behaviour should be consistent - but obviously it is not.

    [quote author="sierdzio" date="1325581128"]Would be nice if the principle was the same for properties and signals. Should we fill a bug report, or maybe was that fixed in Qt5? I'm too busy now to try this in Qt5, even though I have it compiled.[/quote]

    -As it is quite a while to Qt 5 I'm going to file a bug report- -"QTBUG-23414":https://bugreports.qt.nokia.com/browse/QTBUG-23414- . However, this might not be an easy one to fix, as it will break existing code.


  • Moderators

    Please, verify first.

    I've tried again now, and it seems I was partially wrong. Underscores in signals do not work at all! MOC throws an error at runtime. But Qt Creator allows to write the syntax I provided above (with underscores but no capitalisation).



  • [quote author="sierdzio" date="1325582995"]Please, verify first.
    I've tried again now, and it seems I was partially wrong. Underscores in signals do not work at all! MOC throws an error at runtime. But Qt Creator allows to write the syntax I provided above (with underscores but no capitalisation).[/quote]

    Even though Qt Creator allows it, it looks like there are no signal handlers generated for signals not starting with a letter.

    @
    Item {
    signal publicSignal
    signal _privateSignal

    onPublicSignal: { console.debug('onPublicSignal') }
    
    on_PrivateSignal: { console.debug('on_PrivateSignal') }
    on_privateSignal: { console.debug('on_privateSignal') }
    

    }

    Cannot assign to non-existent property "on_PrivateSignal"
    Cannot assign to non-existent property "on_privateSignal"
    @

    Which raises another question - intended behaviour or bug (as Qt and moc do support signals starting with underscores) ;-)



  • Well, as it turns out signals with underscores do work, but there are no handlers generated or there is a naming scheme used I haven't figured out yet.

    @

    Item {
    signal publicSignal
    signal __privateSignal

    onPublicSignal: { console.debug('onPublicSignal') }
    
    Component.onCompleted: {
        publicSignal();      // does work
        __privateSignal();  // does work too
    }
    
    on__PrivateSignal: { console.debug('on_privateSignal') }   // does not work, undefined property
    on__privateSignal: { console.debug('on_privateSignal') }   // does not work, undefined property
    

    }
    @


  • Moderators

    Best way now is to ask on development ML. I'll do that now.


  • Moderators

    Done. I'll report any news that we get from there.



  • Fine. Thanks.



  • Looks like I started a debate here.

    In the meantime I'm declaring private properties that way:
    @property bool pTest@

    Thanks guys.


  • Moderators

    Right, we've got some answers.

    The capitalisation for signals with double underscores works in Qt5, but will not be ported back to 4.x

    Capitalising the first actual letter is intentional and will stay this way.

    Craig also responded with some useful info on using underscores in C++ code (it's reserved by ISO standard)

    Conversation can be followed here: "link":http://lists.qt-project.org/pipermail/development/2012-January/001149.html.



  • Thanks for reporting back. Quite interesting that symbol names with preceding underscores can be seen as "just don't do it", although Qt itself uses them extensively ;-)

    However, if I get things right this does not effect QML, signals with preceding underscores should work and will do so with Qt5.


  • Moderators

    Yeah, I've raised the same point in my reply to Craig.

    AFAIK, QML "talks" directly with MOC, passing signal names as strings - so C++ standard should have nothing to say here. But I may be wrong. And definitely it's a good thing to remember that such a clause happens to exist in the ISO standard.



  • Hi,

    I find this thread cause there is an issue with QtCreator that push me in mistake. QtCreator find this "on__OriginXChanged" invalid and "on__originXChanged", but the first one with the upper case is the property name working when the application runs.

    PS : I use Qt 5.2


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.