SF: Split formula evaluation and plotting in SF plotter

[MichaelHuth]

Part of #2581

[t-b]

New code LGTM. Needs conflict resolution though.

[MichaelHuth]

@t-b I moved the remaining changes from #2171 here.

[Copilot]

Pull request overview

This PR refactors the SweepFormula plotter to separate formula evaluation from plotting logic, improving code organization and maintainability. The change replaces a struct-based approach for plot metadata with a wave-based approach, enabling better separation of concerns between evaluation and display phases.

Key Changes:

• Extracted formula evaluation into new function SF_PlotterGetDataFromFormulas() that pre-evaluates all formulas before plotting
• Converted SF_PlotMetaData struct to text wave with dimension labels for plot metadata storage
• Updated error handling to collect errors during evaluation and abort at the end if any occurred

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
Packages/MIES/MIES_Structures.ipf	Removed obsolete SF_PlotMetaData structure definition
Packages/MIES/MIES_WaveDataFolderGetters.ipf	Added wave getter functions for SF plot metadata and data organization
Packages/MIES/MIES_SweepFormula.ipf	Refactored plotter with new evaluation function, converted struct access to wave indexing, improved error handling, fixed typos
Packages/MIES/MIES_SweepFormula_PSX.ipf	Updated function signatures to use wave-based metadata instead of struct
Packages/MIES/MIES_Utilities_WaveHandling.ipf	Fixed comment typo, added safety check for deep parameter
Packages/MIES/MIES_GuiUtilities.ipf	Added null check and non-existent window handling to GetAllWindows function
Packages/tests/Basic/UTF_GuiUtilities.ipf	Added comprehensive tests for GetAllWindows function

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[t-b]

Failing CI.

[MichaelHuth]

The reason for the fail is:
The test case calls

psx(...)
and
psxstats(...)

where in main psx(...) gets evaluated then PSX_Plot (and PSX_PostPlot) is called that setups the plot, then psxstats is evaluated, where the evaluation relies on an existing psx plot.

With the changed the evaluation is done first, such that psx(...) is evaluated, then psxstats(...) and that fails because there is no plot window yet.

PSX_Plot / PSX_PostPlot can be called later but psxstats evaluation requires results from these calls. I do not see a simple way to split the data preparation and plotting in PSX.

I think this prevents generally to split off the evaluation now from displaying the data in the plotter. Considering that this should prepare the plotter for operations with plotting "instructions", the way would be to incrementally build up the output panel with subsequently adding plot subwindows.

[t-b]

Thanks for digging. What would then be the way forward?

[t-b]

From the top of my head. We could delay running psxstats after the plotting.

[MichaelHuth]

Delaying the plotting of psxstats would not help, because already the evaluation of a formula that contains psxstats requires that any previously evaluated formula containing psx was already plotted. For the general case the plotter does not know if psxstats was one operation that was part of the evaluation.

I first thought I move the storage for the psx working DF from the plot window to the data browser window (as far as I tested multiple psx plots separated by and do not work anyway). Then I the data creation part would need to be done in PSX_Operation already, such that it is already available when psxstats is evaluated. But I think psxstats also interacts with elements of the psx plot, which would not be present at that time...

So instead of trying to make PSX work with splitting evaluation and plotting I now think that currently a feasible way is to change the plotter that it also creates the plot/table subwindows dynamically. Such that there is always an evaluation step and a plotting step (if the evaluation yielded results). The plotting adds then a new subwindow and everything is tiled at the end.
If the evaluation returns data from an operation with full plotting information (like a ivscc_apfreqency should be) then more than one subwindow for this evaluation is added.

Logically this means that I pull the window / guide creation and plotGraphs wave filling in the loop that parses the formulas.

[t-b]

So instead of trying to make PSX work with splitting evaluation and plotting I now think that currently a feasible way is to change the plotter that it also creates the plot/table subwindows dynamically. Such that there is always an evaluation step and a plotting step (if the evaluation yielded results). The plotting adds then a new subwindow and everything is tiled at the end.

Sounds good!

[MichaelHuth]

This PR is replaced by #2592