mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-13 10:04:13 +02:00
ispyisail
31ab7538a4
Bugtracker #309: selecting a result from the Search/Replace hit list highlights the matching element, but on a diagram too large to fit the current view, the view itself never scrolls -- the highlighted element can be entirely off-screen with no indication of where it went. The reporter pinpointed the exact spot, searchandreplacewidget.cpp:1022, and suggested repositioning the view's scrollbars. SearchAndReplaceWidget::on_m_tree_widget_currentItemChanged() already calls setHighlighted()/setSelected() on the matched element, text, or conductor when a hit is selected; it just never brings it into view. Added a call to QGraphicsItem::ensureVisible() alongside each of the three existing highlight/select calls, so the view scrolls the minimum needed for the match to be visible. Followed the same approach as JumpToElementDialog's activateCurrentItem() (added this session for #676) rather than computing scrollbar positions by hand as suggested: ensureVisible() scrolls every view showing the diagram automatically, works correctly if a folio is open in more than one window, and needed no lookup of which QGraphicsView the widget is attached to -- this widget doesn't currently hold one. It was the only existing precedent for this exact "scroll to reveal a matched item" problem anywhere in the codebase. Verified live: built and ran the app under Xvfb, zoomed into one corner of an example diagram until it needed scrollbars, searched for text appearing in two different elements ("Offset null", both op-amp offset-null pins), and confirmed selecting each result scrolled the view to a different part of the diagram, centering the matched element's highlight circle in the visible area each time. No new build warnings.