FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Display minimum/maximum axis labels · Issue #156 · oxyplot/oxyplot · GitHub

Repository navigation

Display minimum/maximum axis labels #156

Description

Imported from http://oxyplot.codeplex.com/workitem/10229

objo 2014-07-10 12:26
Add an option to show minimum/maximum values of the axes.

See

https://oxyplot.codeplex.com/discussions/551062

Activity

  1. VisualMelon commented on Apr 27, 2019

    Contributor

    The discussion seems to have been archived, but this could be a useful addition, and it should be technically simple to get an initial implementation working. I'd be happy to put together a basic proposal if there is interest/demand.

    I've been contemplating the feasibility of a MinimumIntervalCount Properties, but it's not immediately obvious how it would work. This would probably would address the problem of producing plots with only 1 or 2 labels on them (which are completly useless), should be easier to design, and might not require modifications to anything except the Axis and AxisUtilties classes.

  2. HermanEldering commented on Aug 7, 2020

    Contributor

    I have briefly looked into this. For my use case the problem was that I needed to make the ActualMaximum divisible by the major step. The issue with that is that currently the ActualMaximum is calculated before the major step is calculated and when determining ActualMaximum it doesn't know the screen size of the axis and thus can't calculate the major steps.

    For instance on a TimeSpan axis where the DataMaximum is 44 minutes, the ActualMaximum could be 45 minutes (steps of 15 minutes) or 50 minutes (when major step is 10 minutes).

    I didn't know if changing the ActualMaximum from the code where the major steps are calculated is ok or not.

  3. VisualMelon commented on Aug 7, 2020

    Contributor

    Actual Maximum is 'finalised' and consumed by UpdateTransform, which is called before the tick calculation, so you can't really change it thereafter. I think CoerceActualMaxMin would be the right place to try and force it to conform.

  4. HermanEldering commented on Aug 7, 2020

    Contributor

    CoerceActualMaxMin has basically the same issue as CalculateActualMaximum. Those are done before the size/number of steps are known. It is not possible to already determine the major step because those methods do not know the size of the plot area.

    The methods above are called from UpdateActualMaxMin() while the major step is changed from UpdateIntervals(OxyRect plotArea). Would it be okay to change ActualMaximum from UpdateTransform(OxyRect bounds)?

    This will mean the ActualMaximum will change when the plot is resized. An alternative might be selecting a fixed ActualMaximum which is divisible by many values (ie when data maximum is 44 minutes choose 60 minutes instead of 45), then in this example UpdateIntervals can choose between major steps of 60/30/20/15/10/5/etc. minutes (giving 1/2/3/4/6/12 labels respectively). A potential downside is that there might be some more empty space in the plot near the maximum.

  5. VisualMelon commented on Aug 7, 2020

    Contributor

    Ah, yeah, I keep forgetting CoerceActualMaxMin isn't in the margin loop. You probably could override UpdateTransform, and call the base implementation once to sort everything out before fudging the max/min and calling it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL