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. [Solved] QTextBlock::userState behaviour for new blocks ?
Forum Updated to NodeBB v4.3 + New Features

[Solved] QTextBlock::userState behaviour for new blocks ?

Scheduled Pinned Locked Moved General and Desktop
2 Posts 1 Posters 1.6k 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.
  • V Offline
    V Offline
    Vaquita Tim
    wrote on 21 Feb 2012, 16:09 last edited by
    #1

    Hi All,

    I'm trying to pin down what the QTextBlock::userState behaviour should be when new blocks are inserted in QTextEdit.

    I'm using it as an ID to reference a data source. The data source may have newlines in it, which will create new TextBlocks (automagically). Of course I set the userState value for the initial text block, before inserting the text. I would like the new text blocks that are created for me to adopt the same userState.

    This is not helped by my using Qt 4.5.3* (Windows). This appears to give all new TextBlocks a userState of -1 (unless I'm deleting blocks somewhere and adding them in again...). Wheras I'm fairly sure it used to work as I want in 4.5.1 (unless I'm going crazy).

    So, is the behaviour in 4.5.3 (any new TextBlock has a userState==-1) definitive ? Is it the same in 4.8(!) ? Or is 4.5.1 correct and a bug has slipped in ? I couldn't see any specs about this in the docs. I rather suspect the 4.5.3 is correct. It sounds fairly sensible behaviour to me in general - just happens not to be what I want !

    In either case, it might be a good idea for me to control the blocks' userStates explicitly. That would require some kind of signal where I could detect when a new block is created (e.g. if the user hits the return key). If anyone has advice on that it would be good :-) And, I'm happy to upgrade if it helps of course !

    TIA

    Tim

    • this is something of a hobby project, and I don't get to work on it very often, or for very long. If I updated Qt every time, I would never get any work done on my project. Maybe when I retire I will have more time...
    1 Reply Last reply
    0
    • V Offline
      V Offline
      Vaquita Tim
      wrote on 12 Mar 2012, 13:42 last edited by
      #2

      Okay - for those of you trying the same kind of thing, I've solved it explicitly, as I outlined, by overiding the handler key-presses in my class derived from QTextEdit, to handle return keys. It looks something like this :-

      @void PSRTextEdit::keyPressEvent(QKeyEvent *e)
      {

      if( e->key()==Qt::Key_Return || e->key()==Qt::Key_Enter )
      { // put in my text block with the right ID
      assert( m_pSRDocument && "no doc ?!" );
      QTextCursor TextCursor( textCursor() );
      TextCursor.insertBlock();
      TextCursor.block().setUserState( GetNodeID() );
      return;
      }

      QTextEdit::keyPressEvent(e);
      }
      @

      ...though maybe it would be nicer to wait for the key press to have been handled, and then set the ID afterwards, in your case.

      Of course if the above was a supremely stupid thing to do, then let me know !

      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