Turn off scrolling x axis labels

[gvan]

Is there anyway to turn off the scrolling grid labels on a stripchart?  They are quite annoying in two of my applications and the stripchart controls did not do this in 8.1.1. and I have not made any changes to the software.

I am plotting streaming data that has embedded GPS time stamps.  I keep track of the time vs the plotted data and set the x-axis offset such that they left label and right label show the counting data and time of the data on screen.  When the "newly-added" date string quickly scrolling/blinking across the plot looks very bad.  Why can't I sent the number of x-axis divisions to 0 or is there some other way to kill the scrolling label, but keep the two min and max labels?

I also have a graph control with a transparent background (that I use for cursors) on top of the stripchart.  The overlapping graph causing the stripchart plots to break, but I've seen the posts on that problem already.  Hopefully a fix will come on that soon since it is critical error in many of our applications.

[Alex D]

You are correct, the interior labels are showing up in 8.5.0, which is new. If you feel strongly that you don't want them, you can set the x-divisions to one. The only side effect of this will be that you won't have any vertical gridlines. There is no way to get the exact behavior of pre 8.5 back (gridlines with no labels). Let me know if this solution (one x-division) works for you.

Regards,

-alex

[gvan]

Setting the x-axis divisions to 1 does not remove all of the scrolling labels... this is still 1 that scrolls.  This is why I asked why I can't set the divisions to zero?  I already have the gridlines turned off.   I (and our customers) have always found the scrolling gridlines to be annoying and distracting as well.   We use strip charts to emulate an oscilloscope view and I thought that is what they are for.  The labels and gridlines do not move on any of the dozens of scopes that I've used.

Also, the labels on the edges of 8.1 strip charts were left and right justified.  They are now centered on the edge of the plot area.  As such, the plot area size jumps around as the label changes.  This looks ridiculous.   It is especially bad when the axis labels are formatted as long date strings or when the application is plotting data points at speeds more then a few dozen samples per second.

I am a strong believer that whenever new features are added to a control that break/change the old control the programmer should have the option to turn it off or use the old control.  i.e. I shouldn't have to rewrite an application between IDE revisions. These strip chart changes (and the overlapping control bug that I hope is fixed very soon) have completely broken several of our applications and do not, so far as I know, give us any sort of work around option.

I would very much like a ATTR_SHOW_INTERIOR_LABELS attribute for strip charts that when set to 0 would restore the old label behavior of strip charts.

Message Edited by gvan on 12-20-2007 12:29 PM

[LuisG]

Hello gvan,

You're of course correct that it's a very bad idea to change the behavior of an existing application just because the CVI run-time engine is upgraded (which can even happen inadvertently). We always strive to avoid that. Whenever something does change, it's usually for one of two reasons: 1. because of a bug, which of course, we'll try to fix as soon as possible, and 2. because we considered it a cosmetic change. The key, of course, is: what is considered a cosmetic change? In this case, we considered adding the inner markers of the axis a cosmetic change (and similarly, recentering the max and min markers, which was a done as a consequence of adding the inner markers). In retrospect, and given the scenario that you presented, I now realize that this was an incorrect decision on our part. We added the inner markers because we were already making some substantive changes to the functionality of the chart, and several users had requested the ability to display the inner markers. But we should have given more weight to considering that this might not be a welcome change for everyone.

Normally, we would have handled this change via a new attribute, like you suggested. But we couldn't really do that because of a bad decision that was made back in the CVI 3.0 timeframe. The bad decision was that we suppressed the inner markers, back then, but not the vertical gridlines. These two should have been controlled by the same attribute, in order to be consistent with the graph control axes, and with the y-axis of the chart control. But because of that initial decision, in order to accomplish that consistency goal, we had to bind the two together again, which meant adding the inner markers, by default, to the chart, and then control the visibility of both via the ATTR_NUM_DIVISIONS attribute.

However, based on what you've said, it seems that even when the number of divisions is set to 1, a signle inner marker and gridline is appearing. This is unexpected and, pending further investigation, I'm considering this a bug, to be fixed as soon as possible, along with the overlapped control bug. Once that bug is fixed, you really should be able to make both gridlines and markers disappear by setting the number of divisions to 1. And so I apologize not only for requiring you make a code change in order to preserve your existing behavior, but I also apologize for the bug.

We are also planning to address the problem of the plot area resizing frequently. We plan to add a graph and chart attribute that, when enabled, will force the plot area to remain at a fixed size, instead of always adjusting to the changes in the axes.

In the meanwhile, would it be feasible for you to display your oscilloscope in a graph control, instead of a chart? Do you need the scope to scroll when you add new data to it, or would it be sufficient to replace the old data with new data?

Luis

NI

[gvan]

Thanks for the helpful and candid reply.  And thanks for understanding my frustrations.

If you are planning to restore some of the old behavior (and or add some label/plot display options), can I make a "cosmetic" request?

When the number of axis divisions is set to zero (and/or the plot area size is fixed) can the labels at the min and max plot edges be left and right justified like they used to be?  When those labels are long strings (as in the the case of a full data and time string) centering them wastes a lot of valuable screen space.  (or cuts them off if the plot area size stays fixed) 

As for my current applications, I could use a graph control, but not easily.  I would have to maintain a data history buffer.  It is important for the data to scroll.  I also (as you may have guessed) use the Time string axis label option in one application and it saves me from having to recalculate the time stamp on the plot on every update.  (I do have to periodically sync it back up though).  I will likely also run into the graph updating /redraw bug  that my coworker found.  I don't think the fix for it made it into the 8.5 release from Beta  ( http://forums.ni.com/ni/board/message?board.id=beta11&thread.id=64 )

I do like some of the new strip chart features (legends, more channels, etc), but I also liked the old ones that 'broke'.

Greg

[LuisG]

Hi Greg,

Yes, I understand the need for your request to not center the labels. We'll add an option to allow the x-axis labels to not be centered when the number of divisions is one (zero is not a valid number of divisions). Also, to clarify what I meant earlier about a fixed plot area, I meant that users would be able to set the plot area size to be as big or as small at they chose. If it's too big, then the axis labels might be cut off, but that's okay. At least that's the current plan.

Luis

[LuisG]

Hi Greg, it's me again.

This morning I had a discussion with a colleague regarding the "rogue" vertical gridline that appears in the chart, even when the number of divisions is set to 1, and the conclusion of that conversation was that this is actually not a bug. It's intended behavior. I was wrong earlier to call it a bug. This is actually the same behavior that already existed prior to 8.5 (of course the difference was that before 8.5, only the gridline would appear -- not the gridline plus a label).

When I thought that this was a bug, I was thinking about the number of divisions from the perspective of the graph, in which case there are always n-1 gridlines for n divisions. However, when one thinks about the x-axis of a strip chart in continuous mode, the situation changes a bit. Consider a scenario where you have n divisions on the x axis. The resulting number of grid lines, in that case, is n-1, which means that when the chart is in its initial state, and you set the number of divisions to 1, the number of visible gridlines is 0. But there is always an nth gridline, that coincides with the right edge of the plot area.  And as soon as the chart starts scrolling, that gridline, and the other n-1 gridlines, start drifting leftwards, because the individual gridlines stay associated with same x value, even as the chart scrolls. This scrolling scenario does not exist with graphs, and so in that case, new gridline values can be re-calculated each time that the axis end points change. But if the chart also recalculated its gridline values, the scrolling performance would be impacted significantly.

I know this is a bit complicated (which is why I got it wrong earlier in the discussion...). In any case, rest assured that we will still be creating an attribute that completely restores the 8.1 behavior (no interior labels, and uncentered end point labels, regardless of the number of divisions). The only (minor) practical difference from what I had promised earlier is that even when this attribute is enabled, you will always see at least one gridline as the chart scrolls, even if the number of divisions is 1.

Hopefully that made some sense...

Luis

[gvan]

That does make sense when you consider that the "graph" is scrolling. 

On another note (referencing strip charts), why don't strip charts have cursors?  I almost always place a transparent graph with visible cursors on top of the plot area of my strip charts so that I have cursors to measure time, frequency, amplitude, etc. of signals.  This is a fairly easy thing to do so I've never requested cursors on strip charts before, but many of my charts are therefore overlapped with a control which is one reason why the overlapped-chart-plotting bug has impacted many of our applications.

Greg

Message Edited by gvan on 12-27-2007 07:12 AM

[LuisG]

Greg,

There isn't really a great reason that I can think of, other than the fact that we wouldn't be able to support the full functionality of cursors (specifically, snap-to-point cursors). Besides that, it was just the fact that we haven't received user requests for this, and so we didn't prioritize it as a chart feature.

I'm recording the fact that you are requesting it, and if we receive additional requests, we'll definitely bump it up as a priority.

Luis

[MartyMcDAX]

Hi Greg,

I found another forum post where the question of cursors on charts is discussed.  Charts (unlike graphs) are continuously updated and therefore the limits of the chart are often moving.  If cursors were included in charts, they would run the risk of having to be redrawn frequently.  You can read more about it at the forum below.

http://forums.ni.com/ni/board/message?board.id=170&message.id=102968&jump=true

I hope that helps.