Detect which QTextEdit currently has the cursor/caret, for paste

  • Page has a QListWidget with items which can double-clicked, and several QTextEdits. One of the QTextEdits currently has the "flashing text insert cursor/caret" somewhere inside it. Double-clicking an item in the list should insert its text at the cursor/caret in the text edit, via QTextEdit::insertPlainText(QListWidgetItem::text()).

    • The problem is: which QTextEdit instance has the cursor/caret? It is not QApplication.focusWidget(), that turns out to be the QListWidget I am clicking in.

    • Or, alternatively, should this be done via some global "paste" Qt function which knows where the cursor/caret is?

  • Qt Champions 2018

    What I would do is reimplement the focus event of the QTextEdits to emit a signal, connect that signal to a slot that stores the "last used textedit" and use this stored value to call insertPlainText

  • Lifetime Qt Champion

    there is also
    QWidget * fw = qApp->focusWidget();

  • @VRonin
    Thanks for prompt reply. Yes, I realized I can do that if I have to, but I'm lazy and don't like writing more than about one line per each problem I encounter :) I will do that if I have to, but you're saying that there is no call I can make to just ask which widget/text/line edit currently has the caret? Because obviously the windowing system must know.

    For the record, the code used to work when it had tabs/stacked widgets (not sure which, each QTextEdit was on its own tab, now they're all on one page) and just used currentWidget() (e.g.

  • @mrjj
    No cigar! That's precisely why I wrote:

    It is not QApplication.focusWidget(), that turns out to be the QListWidget I am clicking in.

  • Lifetime Qt Champion

    oh sorry. missed that. its not option to flag QListWidget with noFocus if u dont need keyboard navigation?

  • @mrjj
    Even if I did that, there may be other widgets on the page which accept focus. I don't think I should be changing the list widget's behaviour, I just need to know which text edit the insert cursor is currently sitting inside, regardless.

  • @VRonin , @mrjj
    I had not realized/noticed that as soon as I (single- or double-) click an item in the list then the edit widget loses the flashing insert caret. I had thought that remained as-was. My bad.

    In that light, although @VRonin's proposal of tracking "the last focussed widget" is probably what I originally had in mind, I now think it is clearer & simpler to accept @mrjj's suggestion of setting QListWidget::setFocusPolicy(Qt.NoFocus) instead. This leaves the caret visible in the QTextEdit which is as it should be, and means that I can just use QApplication.focusWidget() to identify the edit widget, which is all neater. I do lose the automatic ability for the user to use the arrow keys to scroll through the list items, but the stakeholder is happy with this.

    Thank you both.

  • Lifetime Qt Champion

    Just as a note.
    You can use
    QApplication::focusChanged(QWidget *old, QWidget *now)
    to disable ListWidget in case user can focus to other widget where
    the feature ListWidget provides cannot be used.

  • @mrjj
    Thank you for that too. For now on list double-click I simply look at QApplication.focusWidget() and only do the copy-paste if that is one of my QTextEdits which does accept items from that list, else ignore, which will do me.

  • Lifetime Qt Champion

    Yep i did assume in your use case it would be fine to simply ignore but
    in other cases, it might been needed to show visual clue of feature being unavailable
    as not to be confusing for end user.

  • @mrjj
    Unfortunately, the 32K's-worth of existing code lines inherited by me make no attempt anywhere to enable/disable widgets according to availability context. Whether this is by oversight, design, or inability of end-users to understand why something is disabled and preferring click-causes-error-message-or-ignore instead I cannot say, but now is not the time to tamper with it! Were I doing it from scratch, I would have followed your suggestion!

  • Lifetime Qt Champion

    well if rest of code never use such design clues then i would also consider it waste of time to
    implement it in one form :)

Log in to reply

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