MatchAxis(vertical: false) produces unexpected output

Thanks for a great project, I’m just starting to use it.

I’m using MultiPlot (in lieu of QuickPlot’s secondY: true) and want to have similar X-axis (dates), but let the Y-axis represent different data, with different scale.

I’m use ‘Cookbook.Figure_73_Multiplot()’ to reproduce and illustrate here. If I add vertical:false, like this plt.subplots[2].MatchAxis(plt.subplots[3], vertical:false); Then the X-axis adapts to the source plot’s X-axis, but the Y-axis is left empty.

[swharden]

It looks like that did the trick! a4d5df2c4e2c867078179849313ad28148b3ddd0

I’ll publish this on NuGet then close this issue. Thanks again for both of your help!

[swharden]

Possible improvement of library: AutoAxis() must check each axis manual setup separate, and rescale axis with no manual setup (Y  in this issue example).

@StendProg this is an interesting suggestion! Instead of adding multiple arguments to AxisAuto(), would AutoAxisX() and AutoAxisY() be simpler?

---

Also, I don’t have your email address so I’ll mention a couple topics here I thought you’d find interesting. If you have questions you are welcome to email me ([e-mail]) or we can continue to converse here.

• I’m working to fully replace the ScottPlot axis management system with a new system which will make it easier for two plots to share axes in real time (panning one pans the other) and also allow the addition of a second vertical axis. The change should be invisible to existing users and produce no change in output (strict tests will confirm this).

• I’m experimenting with creating a ScottPlot.Drawing namespace which contains classes like text, line, rectangle, circle, etc… The goal is to remove all System.Drawing calls out of ScottPlot, and have the ScottPlot.Plot object just create a collection of drawing objects in memory but not actually render a bitmap. I can then render plots with different drawing systems, such as RenderWithGDI(bmp, plt) or RenderWithSkia(canvas, plt). I’d really like to be able to benefit from Skia/OpengGL, and adding support to ScottPlot (rather than developing QuickPlot) is probably the best solution.

Thank you for your encouragement on both of these topics! -Scott