Selecting a summary vector in a correlation report now propagates to the contained tornado, cross and summary plots by selecting the first matrix cell, which sends the existing selection signal handled by the report. A virtual onDataSourceChanged() hook on the abstract correlation plot is called after the summary vector selection dialog, and the matrix and tornado plots override it to re-select their first item so dependent plots update.
When a plot is used as a sub-plot of a correlation report, the data source and correlation settings are controlled from the report, so its property editor exposes only the plot settings. Used individually the plots show the complete set of options. Whether a plot is a report sub-plot is tracked with a flag set by the owning report on construction and after read.
Use updateAllRequiredEditors() for sub-plot interactions and for time step changes driven from the summary plot, so the project tree text and property panel reflect the updated auto-generated titles. Re-apply the configured dock title bar visibility after toggling a sub-plot dock, so the title bar stays hidden when a hidden sub-plot is shown again.
Driving caf::ProgressInfo from worker threads inside the OpenMP loop in
loadFileSummaryCaseData() marshaled setProgress() to the GUI thread via a
queued connection. These updates could be delivered after the ProgressInfo
scope had ended and the progress stacks were popped, accessing an empty stack
and resurrecting the just-closed dialog stuck at 0% with no way to close it.
Only update the progress dialog from the master thread, using an atomic
counter for a monotonic progress value, and guard the ProgressInfo mutators
against stale updates delivered after the stacks are empty.
* Make sure we don't trigger another select when a view in the project tree is selected.
* Fix for #14255 and related issues
* Make sure we can close and open a main window, keeping the layout when reopened.
The polygon field was added to the UI ordering by value rather than by
address, so an empty (null) polygon reference resolved to the
PdmObjectHandle overload of PdmUiOrdering::add and aborted on the null
assertion while building the property panel. Pass the field by address so
the field-handle overload is used, matching the other add calls.
Fixes#14311
Take the view's dock widget as a parameter instead of discovering it by walking the widget parent chain, so the caller supplies it directly. Also forward declare QImage in RimViewWindow.h instead of including it, and drop now unused includes in RimViewWindow.cpp.
RimProject::current() can return null while the project is being torn down. Guard the project access in the view-window lookups and valid-comparison-views query with an if-init statement so they return empty instead of dereferencing null.
The depth-related geometry results (DEPTH/DX/DY/DZ/TOPS/BOTTOM) are derived
purely from the shared grid geometry and were computed independently for the
matrix and fracture porosity models. For dual-porosity cases this recomputed the
identical per-cell geometry twice.
Replace the per-model computeDepthRelatedResults() with a single static routine
that traverses the shared main grid once, computing each cell's geometry a single
time and writing it to every porosity model in which the cell is active. The
per-property already-computed guards and the temporary-grid recompute path are
preserved, so the stored values are unchanged. All six matrix+fracture call sites
now go through a thin RigEclipseCaseData::computeDepthRelatedResults() wrapper.
The GUI thread deadlocked on a non-recursive QMutex during OSDU well
import. The download-completion slots and DataLoadController::onTaskFinished
held a mutex while triggering progress updates, which call
QApplication::processEvents(). That re-enters the event loop and dispatches
another queued parquet-download-complete event for a different well, whose
handler then blocks trying to lock the same mutex.
Release the mutex before emitting taskDone in the OSDU well path and well
log data loaders, and before calling incrementProgress() in onTaskFinished.
The map access that the mutex protects stays inside the locked scope; the
captured ProgressInfo outlives the call (kept alive by blockUntilDone) and
incrementProgress() is thread-safe via self-marshaling to the GUI thread.
Fixes#14230.