Data "hides" when using plotyy
이전 댓글 표시
I am using the following to plot two data sets ont he same graph
[AX,H1,H2] = plotyy(A,B,A,C,'plot');
It is in a loop. The first time I run this everything is fine, but if I run again, the second data set disappears after plotting the last point. It is visible upto this time.
set(H2,'Visible','on'); %# Make 2nd y axis visible, H2 as sometimes is disappears
I have used, but to no effect.
댓글 수: 6
When you say it is in a loop are you using
hold on
at all in the loop or are you wanting each plot to replace the previous one?
If you aren't using hold on I would expect the first plot to disappear when you plot the 2nd, but not for the 2nd plot to disappear.
I've never really used plotyy though so I'm not sure what its behaviour is with respect to the current axes and whether it keeps replacing the existing axes (I assume so) on a figure.
It might help if you can give a piece of code that can be run as standalone code as I don't have time to work out what I need to create in my workspace to replicate your problem (though someone else will probably provide an answer anyway!)
Jason
2015년 2월 13일
dpb
2015년 2월 13일
What effect are you trying to create? If you're trying to add additional lines to the initial plot in the loop, use
hold all
on each axis (hold for some reason has never been vectorized to accept a set of handles; must use one at a time) then add the data to each axis in turn as well.
dpb
2015년 2월 13일
Well, as the other poster notes, w/o any data we can't reproduce your efforts to 'spearmint w/o trying to build an example from scratch. As he, I'd suggest building a runnable small demo that illustrates the problem that can paste/post. Doing that may, in fact, lead to discovering the difficulty on your own in which case you can post the solution! :)
Jason
2015년 2월 13일
채택된 답변
추가 답변 (4개)
Jason
2015년 2월 13일
댓글 수: 11
dpb
2015년 2월 13일
As noted previously hold only operates on a single axes handle at a time so you've set that to on for whichever axes handles.axes4 refers to. The status of the other axes is as it was last left.
It's not clear to me why you're referring to other axes beyond AX that were referred to in the plotyy call; don't see anything in the above plot that seems to call for them; certainly don't need another set of axes to add vertical lines to one or the other of the two generated with plotyy as long as the x-data are commensurate with the current xlim values--and even if, for some reason you're adding another scaled-differently set of data it's simpler from a plotting standpoint to simply rescale it to the existing axes rather than add yet another layer/object.
But, you've not really outlined the whole objective well enough to know for sure.
Methinks you need set it for all of them
How do I call a hold on both y-axis? axes.AX ??
No, that's what I've said multiple times; you either call hold multiple times (once for each axes with the single handle) or use the set form with an array of handles.
...handles.axes4 is the GUI axes component which I plot to using ploty...
There's the source of much of your problem methinks...in looking back I see
axes(handles.axes4)
...
[AX,H1,H2] = plotyy(A,B,A,C,'plot');
plotyy creates the two axes into which it plots and returns their handles in AX. They are on top of and hiding the other axes you created above. I suspect it's when you make than one active later on that that is what's wiping out other stuff placed on top of it. Remove the explicit call to axes entirely; just use plotyy to create the axes and then those handles are the only ones you need.
Jason
2015년 2월 13일
A) I don't do GUIs so not positive about whether that's somehow mandatory to create areas within but even if is, once you get the two axes handles from plotyy, use them alone; leave the one in which they are placed in the background. I'm virtually positive that'll solve many of your problems. But, I'd think it also possible to use plotyy alone with a position vector if needed and not have the added complexity altho again, mayhaps there's something unique about the GUI I don't know.
_Addendum: There's an option w/ plotyy to pass an axis handle; on reflection I believe the way to do this if you do need the other axes to partition the GUI real estate would be to use it as
[hAx,hL1,hL2]=plotyy(handles.axes4, ...);
This leaves hAx(1) as gca when done and won't bring the underlying axes to the top in the loop or subsequent times to hide the upper layers (I think; as say, I've never done anything of any import with GUIs so am a neophyte in that area). Anyway, I'd surely try it this way first.
ADDENDUM 2:
On yet further reflection, the above action is ok the first call that creates the two plotyy axes; it also leaves the LH axes as gca. What's interesting is if I
>> hAxTop=axes; % create an axes
>> get(get(hAxTop,'children'),'type') % be default no children exist
ans =
[]
>> [hAx,hL1,hL2]=plotyy(hAxTop,1,1,10,10); % make two more via plotyy
>> get(hAxTop,'children')==hL1
ans =
1
>>
Now, the LH axes line object is a child of the base axes but not the RH axes. You have, as I suspected, two conflicting axes who are the controlling parents of this one line whereas only the RH axes of the second line is in effect.
I'm virtually positive this is why it's the first line that stays visible and the second (RH) that is covered when the underlying root axes becomes the top layer somehow.
I see in reading the documentation on creating programmatic GUIs that they do speak of adding an axes object into which later plot so they've got the same issue with two (but not three) competing axes for their examples.
There's some discussion of setting the 'NextPlot' property to 'ReplaceChildren' to ensure don't wipe out callback functions and other preset conditions; not sure if that somehow might have something to do with what's going on here or not.
Anyway, my upshot is still that when you do anything to these two axes after they're created, only use those two saved handles and I don't think you ever want to refer to the top handle again unless you're deleting the first two in order to then create a new plotyy object unless it's done as shown above as the handle in the call. I'm not sure there about what happens in subsequent calls if they occur; whether it adds more or replaces or just adds more lines; I didn't test that far.
B) Basically, yes, although the figure property is 'NextPlot' and the values are one of '[ new | add | {replace} | replacechildren ]'
hold is a higher-level function but boils down to that for the simple conditions of hold on|off sets default of 'replace' to 'add' and vice versa. The 'all' option does some other things as well.
See
doc hold
for details.
dpb
2015년 2월 16일
Could you make an example that illustrates the problem that can post so we can try to duplicate it here?
I made up a figure with
hAxTop=axes;
hAx=plotyy(x,y1,x,y2);
hold(hAx(1),'on')
hold(hAx(2),'on')
hL=plot([20 20], [0 150],'color','k','linewidth',2);
and both lines stayed visible and the vertical line appeared as expected.
Jason
2015년 2월 17일
dpb
2015년 2월 17일
Need to save the figure as a file; then attach that file...this is a link but can't save it.
Jason
2015년 2월 17일
No, when you use the File menu SaveAs, save local copy then use the paper clip to attach that file. Then I should be able to copy the file itself instead of just open the figure (which has no menu options so can't save it locally and I'm not adept-enough to try to duplicate it that will match the script w/o more effort than care to try...
ADDENDUM
Or, actually, since you must have it saved on disk already to run the test function, use the Attach File paper clip and attach that existing file.
I tried saveas here from the command window with the figure displayed after opening w/ R2012b but that was unsuccessful...the resulting open ends up w/ nothing but an empty figure for some reason. Having never played w/ the GUI stuff I don't know what the deal is...
Jason
2015년 2월 18일
0 개 추천
댓글 수: 1
Hmmm....it wouldn't let me download the file previously; I'll try again, too. I thought it had been attached as an image the way it behaved.
[scuffle, drag, ...] OK, this time I got a download option and did work.
What should happen? If I then click the button I get an axes w/ only a single red dot with blue dot moving across. Subsequent times the axes blinks which I presume isn't supposed to be?
It appears the data you're generating is off the axes y-limits for the red trace after the first point? Is that intentional or an accident?
댓글 수: 6
dpb
2015년 2월 19일
The above logic executes for every case; use sotoo
yLim=ylim(AX(1));
yDiff=diff(yLim); % don't use diff as variable; it's a builtin
if iswithin(yDiff,0,100)
delt=10;
elseif iswithin(yDiff,100,1000)
delt=100;
elseif iswithin(yDiff,1000,10000)
delt=1000;
elseif iswithin(yDiff,10000,40000)
delt=5000;
else
delt=10000;
end
newYTicks = 0:delt:floor(yLim);
for parsimony. Don't believe that's specifically the problem, however, but I can't reproduce it here w/o full code. It doesn't seem as though the last matches the prior, however, agreed.
I'd also, however, change to
ylim(AX(1),[0 floor(yLim(2))])
set(AX(1),'YTick',newYTicks)
to make the limits consistent with the tick spacing and let the tick labels adjust automagically with the tick values.
You can, if you want the plot to auto-range while building, use
set(AX,'yLimMode','auto')
As a convenience, note that at the command line if you do
axes
set(gca)
you'll get a listing of all axes properties and the current or default values of each to see what there is to piddle with that can be helpful particularly when first learning handle graphics.
dpb
2015년 2월 19일
Oh, that's my utility function that is just "syntactic sugar" to replace writing the explicit comparisons...
function flg=iswithin(x,lo,hi)
% returns T for values within range of input
% SYNTAX:
% [log] = iswithin(x,lo,hi)
% returns T for x between lo and hi values, inclusive
flg= (x>=lo) & (x<=hi);
There's another isbetween that is exclusive instead of inclusive and one that has optional parameters to set either bound as [in|ex]clusive as well just for thoroughness.
I've used them so long I tend to forget they're not TMW-supplied.
(Sidebar) They're particular helpful from a clutter-reducing standpoint in cases of returning logical arrays for indexing in selectively computing over ranges; it's much easier to read the function name and grasp the intent that parsing the relation expression so placing it in the lower level away from the higher-level code is a useful abstraction device.
As for the 'Auto' mode, hmmm....I may have to find some additional time to "'spearment"; I didn't think that would prevent/hide the tick values but I've got another commitment at this moment I'm almost late for.
"...the tick marks don't overlap...need to ensure the number of grids on the 2nd axis overlaps with the number from first y axis...I think??"
Ayup... plotyy goes to a lot of effort to ensure that there are both the same number and "pretty" spacing on the two. Somewhere I've got some sample code (Fortran) that does this; used to be you could see the internal TMW code but they've turned it into a p-file in latest releases instead of the old m-file.
ADDENDUM
I suppose it probably doesn't suit your case building the plots dynamically, but one subterfuge might be if you do know a suitable range for the two axes would be to make an invisible figure with a call to plotyy with only the min/maxes as two points for each axes so it'll do the computations. Then return those ygrid/ylim ranges and delete the figure and set them to yours. Somewhat klunky, but, hey, "any port in a storm"... :)
Jason
2015년 2월 19일
dpb
2015년 2월 19일
Don't worry on that score... :) I'm "retired" from the actual paid consulting gig so commitments are various community things or, when it's time actual farm work as returned to family farm some 15-yr ago, now...
카테고리
도움말 센터 및 File Exchange에서 Graphics Object Properties에 대해 자세히 알아보기
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!



