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

[JonB]

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?

[JonB]

@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.

[VRonin]

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

[mrjj]

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

[JonB]

@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. http://doc.qt.io/qt-5/qtabwidget.html#currentWidget).

[JonB]

@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.

[mrjj]

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

[JonB]

@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.

[JonB]

@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.

[mrjj]

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.

[JonB]

@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.

[mrjj]

@JonB
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.

[JonB]

@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!

[mrjj]

@JonB
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 :)