Waveform Graph Legend Weirdness

[Daklu]

In one of my apps I have a pop up window users can use to easily see temperature changes over time. There are roughly 30 different temperatures they would like to track, so I'm using the waveform graph legend's built-in 'vertical scrollbar' and 'plot visibility checkbox' features.

The problem I've run into is that while plots are automatically added to the waveform when users increase the size of the legend, there does not appear to be any way to remove plots from the waveform/legend. I've dug through the waveform graph's properties dialog box, properties nodes, and invoke nodes and for the life of me I cannot find any way to remove a plot from the legend.

Anyone have ideas?

[ShaunR]

The property node Legend>>Number of Rows?

[Daklu]

Nope, that was my first guess too. It's really a resize function and changes the height of the legend to show n plots. It doesn't actually remove any plots from the legend. (Though it will add them if you set n to be more than the number of currently available plots.)

[ShaunR]

I'm not really understanding then since the charts/graphs display as many pots as you wire to them.

[Daklu]

Yes, the chart display will do that, but the legend seems to "remember" all the plots regardless of whether or not there is any data for that particular plot. So for instance, in the fp example above, once I "accidentally" added Plot 4 by dragging the bottom edge of the legend there is no way to remove it. It will continue to be visible to users by scrolling down to it even though I never used it and don't need it.

I did find a 4 year old post on the darkside that explains the same problem I'm having. That specific solution doesn't work in my case but I'm trying to adapt it.

[Daklu]

After 5+ hours of fighting this stupid issue, I found the solution in the Legend:Plot Minimum property.

Though the property does do what the documentation and property name imply, what it doesn't tell you is the Plot Minimum property is automatically updated at edit time when you fiddle around with the legend. What they also don't tell you is the edit-time update only *increases* the Plot Minimum value, it never appears to *decrease* it.

<rant>

Grrr... I *know* my irritation level is pretty high right now and I'm likely not thinking this through, but this reeks of a poorly designed api. Why in the world would I expect the "Plot Minimum" property to behave like that during edit-time? Asymmetrical behaviors should be avoided if at all possible, and if it's not possible to avoid them they need to be documented.

</rant>

[hooovahh]

There's a few things I don't like about the graph controls, and this will just add to my list. I'm going to guess that the reason I have such difficult times with graph controls behaving the way I want, is because they are more advanced controls than a simple string, or numeric, and alot of functionality is actually built into the control, and the behavior I expect may not be the behavior that NI intended when they came out with them. Sure they've added features over the years, with different Property/Invoke nodes, but I still feel like they are complicated and would need NI to invest alot of time to get them to function in a way that is more useful.

The functionality in that plot list section of the graph control is very lacking when compared to an array with a vertical scroll bar, and maybe that is the real problem I have with it and exposing more functions for it would probably make me a little happier.

[asbo]

hooovahh, I had the distinct impression that this was handled correctly in the TDMS viewer you were working. Am I wrong? I feel like we had a discussion about this exact issue and I was totally expecting you to drop in with a couple magical property nodes.

[Rolf Kalbermatter]

The functionality in that plot list section of the graph control is very lacking when compared to an array with a vertical scroll bar, and maybe that is the real problem I have with it and exposing more functions for it would probably make me a little happier.

Well there is always possibility for disagreement with a certain implementation, and I'm not saying the way they are now is without real quirks, but graphs are indeed a very complicated beast. From early days when graphs had much less options (and property nodes were just a very limited possibility) one had to do sometimes rather adventurous things to get a certain feature visually. What I remember from there is that there are sometimes totally contradicting requirements for a certain operation. You couldn't implement one thing without sacrificing something else, and that was not only because of the limited control you had with property nodes and all, but often also a fundamental problem.

On one side you do not want a popup menu with 300 options to select from, on the other hand you want it as flexible as possible without need to go into complicated property node voodoo. And I'm convinced there is no way to get those two requirements fulfilled. Also when adding a new option to a control like a graph, there will be always at least one corner case that needs yet again special handling, and with nowadays complicated graph quite likely a few dozen of them, and they are so easy to miss even with very involved testing and user involvement.

[Jordan Kuehn]

I encountered this last year. Here's what NI says.

Jordan,

I wanted to follow up with you regarding your service request about the

number of visible plots in your legend. I have discussed this with other

engineers and unfortunately there is not a way to decrease the number of

plots showing up when you have the legend scrollbars visible. The only

workaround that there is currently is to remove the scrollbar and

programmatically change the number of plots being displayed at once.

I would also urge you to submit this feature to the idea exchange. The

idea exchange is an online forum where customers can submit features that

they would like to see in LabVIEW and vote on which ideas are the best.

R&D then incorporates the top ideas into the next version of LabVIEW. You

can go to ni.com/ideas. If you don't have time to submit this idea, let me

know and I'd love to submit it for you.

Good luck on your application.

Regards,

Zach Collins

Applications Engineering

National Instruments

www.ni.com/support

[Daklu]

I encountered this last year. Here's what NI says.

"...unfortunately there is not a way to decrease the number of plots showing up when you have the legend scrollbars visible."

Huh. That's interesting--the dark side link I posted has a solution that shows how to do just that.

On one side you do not want a popup menu with 300 options to select from, on the other hand you want it as flexible as possible without need to go into complicated property node voodoo. And I'm convinced there is no way to get those two requirements fulfilled.

There certainly isn't a way to do it if NI continues its history of giving developers prepackaged solutions, but it is possible. Instead of trying to deliver solutions that meet everyone's use case (which leads to flexibility/complexity paradox), provide the developers with a framework of the elements so they can build their own solutions. You can still deliver prepackaged solutions that meet the needs of 80% of the users, but the solution is built on the framework and devs have some way to customize the behavior (via source code edits or object composition) so devs can modify or extend the functionality as needed.

Yes, in principle it probably is possible for someone to create their own graph x-control from scratch, so one could argue NI has already provided the framework. In the same way I can dump a pile of logs on your property and claim you have enough to build a house. Technically it may be true, but for practical matters it doesn't help much. With graphs and charts (and other aspects of LV programming) NI offers us the choice between their pre-built home and a pile of logs. It would be a lot easier to build the house I need if I could get NI to deliver bundles of 2x4s.

[Jordan Kuehn]

Huh. That's interesting--the dark side link I posted has a solution that shows how to do just that.

There certainly isn't a way to do it if NI continues its history of giving developers prepackaged solutions, but it is possible. Instead of trying to deliver solutions that meet everyone's use case (which leads to flexibility/complexity paradox), provide the developers with a framework of the elements so they can build their own solutions. You can still deliver prepackaged solutions that meet the needs of 80% of the users, but the solution is built on the framework and devs have some way to customize the behavior (via source code edits or object composition) so devs can modify or extend the functionality as needed.

Yes, in principle it probably is possible for someone to create their own graph x-control from scratch, so one could argue NI has already provided the framework. In the same way I can dump a pile of logs on your property and claim you have enough to build a house. Technically it may be true, but for practical matters it doesn't help much. With graphs and charts (and other aspects of LV programming) NI offers us the choice between their pre-built home and a pile of logs. It would be a lot easier to build the house I need if I could get NI to deliver bundles of 2x4s.

I was less than pleased at that response and am still a little confused as to why it behaves this way. As was mentioned the "Number of Rows" property should give this functionality IMO. Your post here has revived the anger and frustration I experienced last August when banging my head against the wall. :beer_mug:

[Rolf Kalbermatter]

I was less than pleased at that response and am still a little confused as to why it behaves this way. As was mentioned the "Number of Rows" property should give this functionality IMO. Your post here has revived the anger and frustration I experienced last August when banging my head against the wall. :beer_mug:

Things aren't usually as simple as they seem, or as some tagline says that I read here or on the NI forum:

"If a problem seems simple, I haven't understood the problem yet."

NI can't just take an existing property node and change it's behavior without a lot of thought. Otherwise applications that have worked in previous versions suddenly start to do very weird things after upgrading to a new version. So they have to pretty much leave property nodes alone as soon as they let them out in the wild. Chances are that there was a real brainstorming session about exactly this when they added the scrollbar to the plot legend and that several smart heads in the team came up with several reasons why changing the "Number of Rows" property to reduce the number of plots is not a good idea in that case. And they therefore added the "Legend:Plot Minimum" property to the graph, which should do what you want, if I understand your problem correctly.

And that an application engineer doesn't always know about every possible property out there is not that amazing either. They can't spend 1 hour on every support call, or their manager is starting to breath down their neck about why they have such a low number of support calls. And since the enhanced plot legend is a new feature in 2011, it is not very likely that any of the other AEs in at least 50 cubicles distance would know the answer either right out of their mind.

There certainly isn't a way to do it if NI continues its history of giving developers prepackaged solutions, but it is possible. Instead of trying to deliver solutions that meet everyone's use case (which leads to flexibility/complexity paradox), provide the developers with a framework of the elements so they can build their own solutions. You can still deliver prepackaged solutions that meet the needs of 80% of the users, but the solution is built on the framework and devs have some way to customize the behavior (via source code edits or object composition) so devs can modify or extend the functionality as needed.

Yes, in principle it probably is possible for someone to create their own graph x-control from scratch, so one could argue NI has already provided the framework. In the same way I can dump a pile of logs on your property and claim you have enough to build a house. Technically it may be true, but for practical matters it doesn't help much. With graphs and charts (and other aspects of LV programming) NI offers us the choice between their pre-built home and a pile of logs. It would be a lot easier to build the house I need if I could get NI to deliver bundles of 2x4s.

I have to admit to have troubles to imagine a mechanism to allow that much of customization of controls, without opening up the LabVIEW object handling on C++ API niveau, with all the nasty chances of NULL pointer exceptions, and out of bounds memory accesses, as well as a versioning nightmare if you want to have these controls survive the move from LabVIEW 20xx to 20xx + 1. And it would be definitely even more complex than Xcontrols.

LabVIEW had in its early days just such an API, which exposed the front panel object event dispatch table to external code. But this object dispatch table had to be modified with every new version of LabVIEW and made therefore the idea of external controls based on this quite useless, since they wouldn't have survived an upgrade to a new LabVIEW version. So that interface was left in limbo in LabVIEW 4 and entirely removed around LabVIEW 5.

[hooovahh]

hooovahh, I had the distinct impression that this was handled correctly in the TDMS viewer you were working. Am I wrong? I feel like we had a discussion about this exact issue and I was totally expecting you to drop in with a couple magical property nodes.

So I did develop a fix of sorts. I basically re-created the functionality of the Plot Legend so that I could do the things I wanted. Like don't allow the value of the vertical scrollbar to be greater than the number of plots, and allowing me to change the value of the scrollbar programatically.

The problem with re-creating the Plot Legend is there is a ton of functionality in it. Changing plot color, plot type, line width, line size, bar plots, filling to other plots, interpolation, point style, scales, exporting data, and a few others. What I did was re-create the functionality I used the most which was a very small subset. In the end I wasn't satisfied with the results and all the extra code involved so I reverted back to the normal Plot Legend just leaving a few known bugs with how the graph functions.

[Daklu]

Things aren't usually as simple as they seem, or as some tagline says that I read here or on the NI forum:

"If a problem seems simple, I haven't understood the problem yet."

(See sig.)

I have to admit to have troubles to imagine a mechanism to allow that much of customization of controls...

My comments were based on my experiences in the late 90's and early 00's developing custom controls in VB6 and C#. It wasn't perfect, but it wasn't bad either. Labview's control customization features feel anemic in comparison.

I didn't mean to imply it would be an easy task. In fact, I expect it would be fairly significant undertaking and while I won't claim it would be simple to implement, I believe it could be done without forcing developers to directly interact with the c++ api. When creating custom controls there are typically two areas we are interested in customizing: appearance and behavior.

I'll start with the appearance since it's a little easier to visualize. We can address this using composition. Let's take your typical vertical scrollbar. It has four visual elements: the up button, down button, scroll handle, and background. The scrollbar as a whole is a composition of those four elements interacting in a specific way. For the purposes of this discussion I'll use the word "frame" to refer to an independent visual element. Each of the four elements is a frame. The scrollbar as a whole is also a frame composed of the four subframes.

Suppose I want to change the appearance of scrollbar in a Listbox. Currently I have to create a customized a listbox control. If I want to keep that same scrollbar appearance in non-listbox controls I have to create customized versions of each one. Depending on the level of customization, that could turn into a huge amount of work. Furthermore, current controls don't provide the same level of scrollbar customization. I can change the width or position of the scrollbar in a listbox. I cannot do that with a legend scrollbar. The inconsistency is understandable, but it makes LV more difficult to work with than it should be.

Now let's assume each frame has some behavior associated with it. Since these are UI elements the behaviors are implemented in the form of event handlers. A frame and it's behaviors combine to create a control--a front panel element we can drag and drop onto our vis. Changing a control's built-in behavior is addressed using dependency injection. Define an interface of those event handlers the control handles internally. Create a class implementing the default behavior, with one method for each event handler. Let devs create a child class and override the event handling methods for the events whose behavior they want to change. Provide a way to bind the dev's event handler class to the control. (i.e. Perhaps a "Set EventHandler" property node for block diagrams and right click option for front panels.)

So my question is, why are scrollbars (and all control sub elements) tied so tightly to the controls they're associated with? Why aren't they an independent control with their own events? Why can't I customize a listbox, select the vertical scrollbar, and open another control customization panel to customize it? (And then in turn choose to customize one of the four frames of the scrollbar?) LV developers are already familiar with the idea of composition via OOP and clusters. This wouldn't be an intellectual stretch.

This might even be possible using xcontrols--I've never tried composing an xcontrol from other xcontrols or delegating the event handlers to a public interface class. I know AQ has talked about integrating xcontrols and LV classes in the past, but I don't remember if his use case addressed these specific issues. If it is possible, why isn't NI doing it? If it isn't possible, it should be. Controls could still behave largely as they do today with the addition of accessor methods for the subcontrols. Developers only need to dig into the details if the default controls don't meet their needs. We'd have a lot more flexibility if the controls were exposed to us as hierarchy of controls instead of as an opaque, shrink-wrapped package.

One potential difficulty I can see is in how Labview blurs the line between edit-time and run-time. That still throws me for a loop now and then. (Such as the unexpected edit time behavior of the chart control.) If I wire my custom event handler to a control, should that custom behavior persist when the vi is not executing? Personally I wouldn't expect it to, but I don't speak for NI's customer base. (I'd also prefer a dev environment that better separates the "tool" aspect of LV from the "programming" aspect of LV. Maybe "GView" to emphasize it's programming language orientation.)

I'm sure there are numerous other difficulties I haven't thought of. I'm also sure there are valid historical reasons why LV controls didn't evolve in this way. I don't have a problem with that. I do hope that something like this is at least on NI's radar and they have concrete plans to move in that direction. I've grown to really enjoy dataflow programming; it suits my thought processes well. At the same time, Labview seems to continuously be 15 years behind other programming languages and as I grow as a programmer it seems like Labview is struggling to keep up.