Detect which QTextEdit currently has the cursor/caret, for paste
-
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 callinsertPlainText@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
QTextEditwas on its own tab, now they're all on one page) and just usedcurrentWidget()(e.g. http://doc.qt.io/qt-5/qtabwidget.html#currentWidget). -
@mrjj
No cigar! That's precisely why I wrote:It is not
QApplication.focusWidget(), that turns out to be theQListWidgetI am clicking in. -
@JonB
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 theQTextEditwhich is as it should be, and means that I can just useQApplication.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.
-
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 atQApplication.focusWidget()and only do the copy-paste if that is one of myQTextEdits which does accept items from that list, else ignore, which will do me. -
@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.@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
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!
