Difference between revisions of "Table Position Bug While Scrolling Workspace"
(Created page with "There is a bug in MATLAB such that when an axes's parent is a uipanel, whose parent is another uipanel, the position of the axes is not correctly calculated as the top-level uipa...") |
|||
| Line 1: | Line 1: | ||
| − | There is a bug in MATLAB such that when an axes's parent is a uipanel, whose parent is another uipanel, the position of the axes is not correctly calculated as the top-level uipanel is moved. This occurs in Rave with table-type workspace objects. The main Rave workspace is the top-level uipanel, and the table lives in its own uipanel, which takes the place of handles. | + | There is a bug in MATLAB such that when an axes's parent is a uipanel, whose parent is another uipanel, the position of the axes is not correctly calculated as the top-level uipanel is moved. This occurs in Rave with table-type workspace objects. The main Rave workspace is the top-level uipanel, and the table lives in its own uipanel, which takes the place of handles.fakerax(ai). (Uipanels are used because they crop all axes children exactly to the uipanel limits, whereas axes alone will not partially crop text objects.) |
| − | Rave accounts for this bug in the function ravemoveview, which looks for workspace objects whose handles. | + | Rave accounts for this bug in the function ravemoveview, which looks for workspace objects whose handles.fakerax is a uipanel, and simply re-sets the uipanel's position to its current value. Although the position vector is unchanged, by calling set after the workspace has moved, the lower level panels redraw in the correct position. |
| − | The important point is that any workspace object that lives in its own uipanel must store that panel in handles. | + | The important point is that any workspace object that lives in its own uipanel must store that panel in handles.fakerax so that Rave knows to apply this fix whenever the workspace is scrolled. |
Latest revision as of 20:20, 10 October 2012
There is a bug in MATLAB such that when an axes's parent is a uipanel, whose parent is another uipanel, the position of the axes is not correctly calculated as the top-level uipanel is moved. This occurs in Rave with table-type workspace objects. The main Rave workspace is the top-level uipanel, and the table lives in its own uipanel, which takes the place of handles.fakerax(ai). (Uipanels are used because they crop all axes children exactly to the uipanel limits, whereas axes alone will not partially crop text objects.)
Rave accounts for this bug in the function ravemoveview, which looks for workspace objects whose handles.fakerax is a uipanel, and simply re-sets the uipanel's position to its current value. Although the position vector is unchanged, by calling set after the workspace has moved, the lower level panels redraw in the correct position.
The important point is that any workspace object that lives in its own uipanel must store that panel in handles.fakerax so that Rave knows to apply this fix whenever the workspace is scrolled.
