Figured Out a Work-Around for the VantagePoint Second Y Axis Bug

comboGraph.png

I've been wrestling with a VantagePoint bug concerning the placement of Variables on the secondary Y axis, and this morning I got another email from Gordon with an example application that showed the secondary Y axis working perfectly. It took me a little bit to figure out that Gordon had put in the setLicense() call into the code, as I put mine in at another place and his trumped mine and so nothing worked, but that was a "Duh!" moment that was easy enough to figure out.

No, the problem was that on a simple graph, like Gordon's example, where the graph was all set up and ready to go before the first call to unlock() on the graph, didn't show the problem. When I looked at my code, there's all kinds of lock() and unlock() calls, and in general, the construction is far more dynamic - by design.

I was playing around with a lot of things and then came across this little nugget that was the beginning of the end for the problem. When I did the initial setting of the Variables on to the secondary Y axis, the code looked pretty familiar:

  for (int i = 0; i < cols.length; ++i) {
    getGraph().getVariableAttributes(cols[i])
        .setOption(VariableAttributes.voiSecondary, true);
  }

As you'd expect, this runs through the array of int values for the column numbers and sets those that need to be set. Pretty simple. Or so I thought.

When I did this I found that setting cols[2] actually also set cols[0] and if I cleared out cols[0] it also cleared out cols[2]. It's like they were linked somehow. I verified this by logging the status of each getOption() call for each of the columns on the graph after each call to setOption(). I was stunned.

I also was unable to reproduce this in the example Gordon gave me. I wanted to be able to send him back something but it wasn't looking good. Then I got the idea that maybe this was an order of operation issue, like some of the others have been with VantagePoint. Basically, for showing points and labels, it seems there's a necessary order to respect. This isn't required when you build the graph atomically, like Gordon's example, but it is in my code.

So I started messing with the order.

The first thing I did was to move the setting of the secondary Y axis to after the visibility of the points and labels. Immediately, it worked. Wow. That was fast. There wasn't much else to do but to document the heck out of the placement of the code, and then write it up to Gordon. In the end, I'm not sure if he's going to write back with requests for more data. If he does, I'll certainly try to supply it, but it's going to be tough. Simple is not where this guy shows up.

But it's nice to have it working as it's supposed to:

Fixed Second Y Axis