A Zero Line at values other than zero?

This might not be your desired solution, but I always do this by drawing a line instead:

Thanks. Yes. Drawing works too. However, during the development of interactive demos that use control panel check boxes to show/hide features on graphs, turning on/off calibration lines at positions other than zero will be easier on hand a ModifyGraph zeroline(bottom)=1/0 than using a slew of commands to create + store + hide + show drawings.

No big deal. Just a thought that might be easier to apply as a matter of habit instead of the wave or line drawing approach.

I see you point. Indeed, showing and hiding a line may get somewhat involved. 

Here is another suggestion. You can create a new vertical axis, offset its zero position and add a zero line to it. Set the zero-line thickness >0. Set the axis thickness to zero. Here is a recreation macro for an example I tried. The zero-line position can then presumably be modified by setting the axis limits for the hidden new axis.

The attached figure shows two instances of wave0, with default axes and the zero line of the hidden 'newLeft' axis. The visible  axes are for the red trace. The blue trace matches the hidden left axis and is for information only (it can be removed).

There's some user-interface code for drawing lines on a graph here:

https://www.wavemetrics.com/comment/5680#comment-5680

Maybe not quite what you want because it doesn't allow turning lines on and off, but it does make it easy to add a reference line to a plot without having to look though all the options in the drawing dialog.

Jeff-

Would there be just one line, but at a settable value?

As soon as we released that, someone (maybe you?) would want lines with names so that you could have more than one and be able to turn them on and off independently.

It seems like this might be one of those things where the target might be  moving, and depend on who was using it.

By the way, another possibility for a line on a graph is to use the cursors. I forget when exactly I added this, but at least in Igor 8 you can choose the horizontal or vertical hair of a hairline cursor, plus you can set the width and color of the line. You can even choose to have two lines (the outer limits of a wide cursor line) or three lines (the outer limits plus center line). The main drawback is that the lines don't print or appear on exported graphics (though SavePICT/SNAP will save a low-res picture).

For instance, do this:

Then run this recreation macro:

The only thing I can think of that might be a problem is that you can't lock the cursor to a value. Your users will be able to click and drag them to the "wrong" place.

I meant to note that some of the image processing dialogs use these special cursor styles. For instance, the line profile dialog shows the averaging width via the multiple-line crosshair cursor. It was these dialogs that motivated the implementation.

Hah!

Doesn't completely lock the cursors, but it does keep you from clicking and dragging the cursor to a new place. What an amazingly complicated application. I implemented that, and didn't remember it...

johnweeks wrote:

Jeff-

Would there be just one line, but at a settable value?

As soon as we released that, someone (maybe you?) would want lines with names so that you could have more than one and be able to turn them on and off independently.

My immediate interest was for only the so-called ZERO line to have a settable value. Specifically, for a particular application that I have in mind, I want a "reference" line at y = 1 rather than y = 0.

As for having lines with names and more than one line and anything beyond one line at a value other than zero, to be honest, at that point, *I* would program something with drawing tools or waves (that can be turned on/off with hideTrace(...) or, now that I know, with cursors.

But ...

Perhaps this points to a longer term idea for a Tick and Grid Options tab with Enable/Inhibit Grids panel to mirror what is done with Ticks????

In summary, for now and for the foreseeable future, I would be happy for quite a long time if I could just set a "reference zero line" at one defined value that does not necessarily have to be zero.

Thanks!

Many years ago (middling Igor 6 era) I wrote some code to implement an arbitrary number of lines (both horizontal and vertical) on a graph that the user could drag to define multiple areas of interest. Behind the scenes I used a 3-column wave, one column for x and another for y, and a third for colour. This wave would consist of two rows for a pair of coordinate values followed by a row of NaN’s to break the lines. The vertical lines were plotted using the normal graph x axis and a hidden y axis with limits 0 to 1, and similarly the horizontal used the graph y axis against a hidden x axis. I wrote code to manage all this, and to even name the lines using a string list in the wave’s note and use hook functions to enable the user to interact with these lines. This universal code was used for many different graphs within the application.

Unfortunately, I no longer have access to that code, but this concept does lend itself to be made into a package to (probably) fulfil the current requirements and possible future moving targets eluded to by John.

Coincidently, I had a similar problem to Jeff a couple of weeks ago – I wanted a single ‘guide line’ at a y-value of 100. I ended up using the drawing tools much along the lines suggested by @chozo in this thread.

Related to this topic of programmatic drawing, might it be possible to name drawing objects, or to attach user data to an object or a named group of objects?

The reason that I ask is that if I draw objects programmatically that are related to a trace, it can be hard to keep track of things if the trace is renamed or if the user decides to manually delete an object. I'm happy that the user should be able to do these things, but life would be easier with some expanded naming possibilities.

@tony Presently, you can name a group of drawing objects. See the DrawAction operation. You can create groups that are solely for the purpose of applying names to drawing objects in order to later manipulate the group of objects.

At present there is no provision for user data associated with drawing objects. I would have to think about how to implement such a thing.

So now there are two kinds of groups- named groups that are just a collection of one or more objects just for purposes of naming and groups that actually behave like a single drawing object for purposes of selection.