I'm trying to get ScottPlot to work for the Version 4.1 Cookbook documentation. https://scottplot.net/cookbook/4.1/
However, apparently WL8 has ScottPlot Version 1.0.0.beta installed,
I see in version 4.1 there is a FillBelow() function.
(see https://scottplot.net/cookbook/4.1/category/plottable-signal-plot/#signal-plot-quickstart)
Is there a way to override the ScottPlot version WL8 is using and Install my own, which would follow the 4.1 documentation?
However, apparently WL8 has ScottPlot Version 1.0.0.beta installed,
CODE:so this documentation is useless. Can someone update ScottPlot to Version 4.1 so it corresponds to the online documentation?
WriteToDebugLog(Plot.Version);
I see in version 4.1 there is a FillBelow() function.
(see https://scottplot.net/cookbook/4.1/category/plottable-signal-plot/#signal-plot-quickstart)
CODE:Does anyone know how to do the exact same thing in the ScottPlot version 1.0.0.beta that WL8 uses?
var sig = plt.AddSignal(data); sig.FillBelow();
Is there a way to override the ScottPlot version WL8 is using and Install my own, which would follow the 4.1 documentation?
Rename
Version 1.0 is our internal build number because we compile the library ourselves.
Wish we could update to every build of some dependency library but as you know it adds up to the product maintenance and testing because there may be breaking changes we'd have to keep up with. My legacy code using ScottPlot already required some tweaks after the latest version upgrade.
Wish we could update to every build of some dependency library but as you know it adds up to the product maintenance and testing because there may be breaking changes we'd have to keep up with. My legacy code using ScottPlot already required some tweaks after the latest version upgrade.
To answer your question: yes, there is a way:
1. Go to Nuget website https://www.nuget.org/packages/ScottPlot/
2. Click on "Download Package". For example, the current link is https://www.nuget.org/api/v2/package/ScottPlot/4.1.45
3. Unzip this archive, taking ScottPlot.dll from /lib/netstandard2.0
4. Rename the file to WealthLab.ScottPlot.dll
5. Make a copy of the source file at "c:\Program Files\Quantacula, LLC\WealthLab 8\WealthLab.ScottPlot.dll" and overwrite it
I also experimented with changing the version number in WealthLab8.deps.json (plain JSON file) in Notepad++ to 4.1.45.0 but it seems that leaving it as is works as well.
1. Go to Nuget website https://www.nuget.org/packages/ScottPlot/
2. Click on "Download Package". For example, the current link is https://www.nuget.org/api/v2/package/ScottPlot/4.1.45
3. Unzip this archive, taking ScottPlot.dll from /lib/netstandard2.0
4. Rename the file to WealthLab.ScottPlot.dll
5. Make a copy of the source file at "c:\Program Files\Quantacula, LLC\WealthLab 8\WealthLab.ScottPlot.dll" and overwrite it
I also experimented with changing the version number in WealthLab8.deps.json (plain JSON file) in Notepad++ to 4.1.45.0 but it seems that leaving it as is works as well.
QUOTE:
Version 1.0 is our internal build number because we compile the library ourselves.
Don't do that because it's confusing. Have ScottPlot return the actual build number.
I had version problems with ScottPlot a year ago, so it hasn't been updated for some time. I appreciate you can't update it constantly, but install it without rebuilding it so it's quick and simple for you (or me) to update.
Thanks for the info on how to update it myself. I will definitely give that a try.
We do this for our own build system.
Believe me, we would have done that if it was possible. It would not work with .NET6 unless we rebuilt the source. Perhaps this has changed since then, we can create a tracking issue to check out the situation.
The new Scottplot update works fine straight from Nuget, so there's no longer a need for us to compile our own fork, it'll be included in Build 7.
Thanks; that's great news. Try to keep the ScottPlot library "as is" (unadulterated) if it's compatible with .NET 6.X.
There are bugs in the older ScottPlot version, but it's inappropriate to report bugs to the author unless I'm running the current version.
Yes, I appreciate the ScottPlot upgrade will break some of my older ScottPlot code. But at least the new version will correspond better with the online documentation.
So if some packages are only compatible with .NET 4.7, they can't simply be combined with another app (WL8) that's dependent on .NET 6.X? They need to be rebuilt? (I'm not that keen about supporting backwards compatibility.)
I'm wondering if WL switched to .NET 6.X too soon, but I like being able to use .NET 6 features (e.g. XML serializer) that weren't compatible with Core 3.1.
There are bugs in the older ScottPlot version, but it's inappropriate to report bugs to the author unless I'm running the current version.
Yes, I appreciate the ScottPlot upgrade will break some of my older ScottPlot code. But at least the new version will correspond better with the online documentation.
QUOTE:
there's no longer a need for us to compile our own fork,
So if some packages are only compatible with .NET 4.7, they can't simply be combined with another app (WL8) that's dependent on .NET 6.X? They need to be rebuilt? (I'm not that keen about supporting backwards compatibility.)
I'm wondering if WL switched to .NET 6.X too soon, but I like being able to use .NET 6 features (e.g. XML serializer) that weren't compatible with Core 3.1.
Your Response
Post
Edit Post
Login is required