Allow axis mapping context menu at run-time

[steve60tuesday]

Changing a graph's axis mapping (linear to/from logarithmic) is super easy using the context menu in edit mode.  But as far as I can tell, this feature is not available at run time:

It's inconvenient to have to stop a VI to change the axis mapping (and sometimes impossible, e.g. in stand-along applications) and I believe that most users would expect to find lin/log controls in the context menu, right next to autoscale.  Why not enable this feature in run-time?  If, for whatever reason, a developer doesn't want these options displayed, it would be easy to delete them from the run-time context menu. 

It's certainly possible to change the axis mapping programmatically, but I would prefer if it were built in to the graph control, and enabled by default.  It's frustrating to manually create axis scale control elements, over and over again, every time an application doesn't permit stopping the VI to change mapping from the edit-mode context menu.

[crossrulz]

Why not just make the menu setup you want and then save that off.  Then you can just set your run-time menu to match that file for any graph you need it in.

[AristosQueue (NI)]

We have to be VERY careful and VERY conservative putting popup menu items on items that will show up to our users' users. LV applications are very diverse, and the menu items exposed have to be things that are pretty much universally desired by our users for their users.

My presumption is that it never-to-rarely makes sense for an end user to change the mapping of a graph. The author of the VI specifies the data that is available. Are there many situations where it makes sense to switch the same data back and forth from linear to log scales? Personally, that would be odd to me. Different data sets, sure, but those would, in my experience, require more of a UI shift than just the scale -- a whole different graph with different labels, etc.

Is this ability to change scales something that most data displays in nearly all applications would want exposed?

[X.]

You have to show the scale legends. Then the mapping can be changed at runtime:

[steve60tuesday]

Good find -- thanks! I understand the argument that adding new context menu functions by default might not be helpful in all situations. But if a particular feature (e.g., log-scale mapping) doesn't make sense for a particular application, then the user can ignore it like anything else. So, I still think the scale legend drop-down menu (shown above) should be added, as a submenu, to the axes' context menu. It's not adding new functionality -- just presenting it at a more intuitive location. (And, saving panel space!) Thanks again.

[AristosQueue (NI)]

> then the user can ignore it like anything else

That is the wrong view of easy to use interfaces. A good interface doesn't have a bunch of stuff for users to ignore. It has what they want and nothing else. Users don't ignore things they don't use... they get lost in them and can't find the stuff they do use. Or, worse, they create burdens for the developer when bug reports come in based on customers using features you never tested or never expected them to use.

End user: "My graph is all messed up. You screwed up."

Developer: "Let me look."

<three days later>
Developer: "You turned on the logrithmic scale. It's working as intended."

End user: "Oh, yeah. I forgot I turned that on."

I get reports like that all the time for LV, as happens with any complex software. But a lot of the test benches that y'all write for your users aren't in the category of "major industrial software with 10,000 special cases". They're apps with one specific intended purpose, and anything extra is generally more of a bad thing than a good thing.

I didn't know you could enable it in the UI. That's a reasonable solution... if you want users to be able to toggle this setting, you enable it on the graph. I like that solution.

[steve60tuesday]

I see your point, and agree that something you can enable in the UI is the reasonable solution. Presently, by default, users can show on the scale legend at run time (from the context menu) and access the mapping controls from there, unless you specifically disable showing the scale legend. The axes' context menus are a less bulky, more intuitive place to offer some of these functions, and would be no more difficult to disable than the scale legend itself. I think this would improve LabView without disrupting the status quo. Doesn't look like this idea will get traction, though, so I'm glad I was guided to the scale legend for run-time access. It's frustrating that programmatic access to it (other than show/hide) was removed since LV8!

[tst]

As crossrulz pointed out, you can change the menus to add this in, either by editing the menu of the graph (right click>>Advanced or with menu activation event) or by using the context menu plugins in LV 2015, which will apply to all graphs on computers where the plugin is installed.

[AristosQueue (NI)]

tst: The right-click plug-ins DO NOT affect run-time panels. They only affect edit-time panels, edit-time diagrams and run-time diagrams. The plug-ins would otherwise be a magical auto-include into every EXE/DLL that you build with AppBuilder. Use the actua source code of your application to add custom popup menus to run-time panels.

[tst]

> The plug-ins would otherwise be a magical auto-include into every EXE/DLL that you build with AppBuilder

That does not sound like a bad feature, at least I had any use for the run time menus (although I agree invisible reliance on what IDE extensions you have installed is not a good recipe for consistency. It would probably require expicitly mark which plugins you want to support for each specific EXE). I don't think I ever actually needed custom RCMs on controls, but I understand how they can be useful.

[johnsold]

I often find myself changing mapping when exploring data, usually after an FFT. Some of the spectral analysis VIs have mapping inputs. I use those if the data is in waveform format. I have created mapping booleans and manipulate the data in my code as well, especially when I am not the only user.  I think that the method suggested by X. will be sufficient for my purposes, so I see no need to make a change in the functionality of graphs.

Lynn