Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Solved Invert QRegExp functionality in QSortFilterProxyModel

    General and Desktop
    2
    5
    154
    Loading More Posts
    • 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.
    • C
      crizos last edited by crizos

      Hi all,

      I have a QTreeView where I use QSortFilterProxyModel to filter the elements that are displayed to contain the given QRegExp. What I want is to invert that functionality, where the elements that will be displayed will be these that do NOT contain the given QRegExp.

      How I could do that?

      Thank you,
      Chris

      JonB 1 Reply Last reply Reply Quote 0
      • JonB
        JonB @crizos last edited by JonB

        @crizos
        There isn't an inbuilt Qt "flag" for this. I can give you the way of "approximately" "not"ting a regular expression, but it's a bit hairy, and involves "zero width lookahead assertions". I don't know how well it would play with the filter expression expected here.

        I wonder if the simpler way would be to subclass and override filterAcceptsRow() to do the necessary when you want "not" to be active. Untested, but I assume you can just call the base method (so it deals with the regular expression for you), and then just return "not" that, i.e.

        bool MySortFilterProxyModel::filterAcceptsRow(int source_row, const QModelIndex &source_parent) const
        {
            bool accept = QSortFilterProxyModel::filterAcceptsRow(source_row, source_parent);
            return iWantNot ? !accept : accept;
        }
        
        C 1 Reply Last reply Reply Quote 0
        • JonB
          JonB @crizos last edited by JonB

          @crizos
          As a general comment you should be using QRegularExpression and corresponding methods if you are currently using QRegExp.

          There isn't an inbuilt "not". You can of course code at the filterAcceptsRow() level, but I imagine you're not doing that. "Notting" a regular expression can be hasslesome: are you looking for a generic solution for an arbitrary regular expression, or only a certain kind?

          1 Reply Last reply Reply Quote 0
          • C
            crizos last edited by crizos

            @JonB thanks for the tip, currently I am stuck with v5.9. I was looking for a generic way to do an inversion of the "normal" searching procedure. But I was hoping for an in-built "switch" implementation doing what I want.

            JonB 1 Reply Last reply Reply Quote 0
            • JonB
              JonB @crizos last edited by JonB

              @crizos
              There isn't an inbuilt Qt "flag" for this. I can give you the way of "approximately" "not"ting a regular expression, but it's a bit hairy, and involves "zero width lookahead assertions". I don't know how well it would play with the filter expression expected here.

              I wonder if the simpler way would be to subclass and override filterAcceptsRow() to do the necessary when you want "not" to be active. Untested, but I assume you can just call the base method (so it deals with the regular expression for you), and then just return "not" that, i.e.

              bool MySortFilterProxyModel::filterAcceptsRow(int source_row, const QModelIndex &source_parent) const
              {
                  bool accept = QSortFilterProxyModel::filterAcceptsRow(source_row, source_parent);
                  return iWantNot ? !accept : accept;
              }
              
              C 1 Reply Last reply Reply Quote 0
              • C
                crizos @JonB last edited by

                @JonB
                I think you are right, I will explore overriding filterAcceptsRow. I don't want to try as you said "Notting" the regular expression as it may do the things harder than they should be.

                Thanks for the help!

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post