Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Questions on property notifiers
Forum Updated to NodeBB v4.3 + New Features

Questions on property notifiers

Scheduled Pinned Locked Moved General and Desktop
2 Posts 2 Posters 547 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • X Offline
    X Offline
    x6herbius
    wrote on last edited by
    #1

    I have a couple of questions relating to the way QProperty notify signals should be used. I understand that they are fired when the property value changes but, for a title property for example, I've seen two different types of signal:

    @void titleChanged();
    void titleChanged(const QString&);@

    Is there any specific advantage of one over the other, or any situation in which either one would be preferred, or is it good practice to implement both? Personally my current issue is that if I implement the latter in a component of a larger object, I can't hook up the signal containing a parameter to the larger object's generic

    @void objectChanged();@

    signal without first going through a boilerplate slot like

    @handleTitleChanged(const QString&) { emit objectChanged(); }@

    This method works but gets irritatingly messy when a number of different types of notification, each with different parameters, need to be hooked up to one single object change notification.

    Any opinions of more experienced Qt users than myself would be much appreciated.

    1 Reply Last reply
    0
    • Chris KawaC Offline
      Chris KawaC Offline
      Chris Kawa
      Lifetime Qt Champion
      wrote on last edited by
      #2

      There's no point in implementing them both. You can connect a slot that has fewer number of parameters than the signal, just not more. You don't need that wrapper.

      I guess the choice which you implement depends on the property and how it's going to be used. In case of a title, when someone connects to that change signal it's reasonable to assume that he is interested in what that title is, so I'd go for a version with parameter. Sometimes the value is not that important but the fact that it changes is. But I'd say the parameter version is more general.

      Implementing both of these is actually a bad idea, because one is superset of the other anyway and it actually makes the new connect syntax a mess. Compiler can't figure out which overload you want and so you need an ugly cast like this:
      @
      connect(sender, static_cast<(void)(SenderClass::*)(int)>(&SenderClass::signal), receiver, &ReceiverClass::slot);

      //when there's only one the syntax is easier:
      //slot can be parameterless even if signal has a parameter
      connect(sender, &SenderClass::signal, receiver, &ReceiverClass::slot);
      @

      1 Reply Last reply
      0

      • Login

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • Users
      • Groups
      • Search
      • Get Qt Extensions
      • Unsolved