⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 view.html

📁 API資料大全
💻 HTML
📖 第 1 页 / 共 5 页
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd"><!--NewPage--><HTML><HEAD><!-- Generated by javadoc on Thu Apr 27 23:42:25 PDT 2000 --><TITLE>Java 2 Platform SE v1.3: Class  View</TITLE><LINK REL ="stylesheet" TYPE="text/css" HREF="../../../stylesheet.css" TITLE="Style"></HEAD><BODY BGCOLOR="white"><!-- ========== START OF NAVBAR ========== --><A NAME="navbar_top"><!-- --></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0"><TR><TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1"><A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">  <TR ALIGN="center" VALIGN="top">  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> &nbsp;<FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="class-use/View.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../index-files/index-1.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A>&nbsp;</TD>  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A>&nbsp;</TD>  </TR></TABLE></TD><TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM><b>Java<sup><font size=-2>TM</font></sup>&nbsp;2&nbsp;Platform<br>Std.&nbsp;Ed. v1.3</b></EM></TD></TR><TR><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">&nbsp;<A HREF="../../../javax/swing/text/Utilities.html"><B>PREV CLASS</B></A>&nbsp;&nbsp;<A HREF="../../../javax/swing/text/WrappedPlainView.html"><B>NEXT CLASS</B></A></FONT></TD><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">  <A HREF="../../../index.html" TARGET="_top"><B>FRAMES</B></A>  &nbsp;&nbsp;<A HREF="View.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD></TR><TR><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">  SUMMARY: &nbsp;INNER&nbsp;|&nbsp;<A HREF="#field_summary">FIELD</A>&nbsp;|&nbsp;<A HREF="#constructor_summary">CONSTR</A>&nbsp;|&nbsp;<A HREF="#method_summary">METHOD</A></FONT></TD><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">DETAIL: &nbsp;<A HREF="#field_detail">FIELD</A>&nbsp;|&nbsp;<A HREF="#constructor_detail">CONSTR</A>&nbsp;|&nbsp;<A HREF="#method_detail">METHOD</A></FONT></TD></TR></TABLE><!-- =========== END OF NAVBAR =========== --><HR><!-- ======== START OF CLASS DATA ======== --><H2><FONT SIZE="-1">javax.swing.text</FONT><BR>Class  View</H2><PRE><A HREF="../../../java/lang/Object.html">java.lang.Object</A>  |  +--<B>javax.swing.text.View</B></PRE><DL><DT><B>All Implemented Interfaces:</B> <DD><A HREF="../../../javax/swing/SwingConstants.html">SwingConstants</A></DD></DL><DL><DT><B>Direct Known Subclasses:</B> <DD><A HREF="../../../javax/swing/text/AsyncBoxView.html">AsyncBoxView</A>, <A HREF="../../../javax/swing/text/ComponentView.html">ComponentView</A>, <A HREF="../../../javax/swing/text/CompositeView.html">CompositeView</A>, <A HREF="../../../javax/swing/text/GlyphView.html">GlyphView</A>, <A HREF="../../../javax/swing/text/IconView.html">IconView</A>, <A HREF="../../../javax/swing/text/PlainView.html">PlainView</A></DD></DL><HR><DL><DT>public abstract class <B>View</B><DT>extends <A HREF="../../../java/lang/Object.html">Object</A><DT>implements <A HREF="../../../javax/swing/SwingConstants.html">SwingConstants</A></DL><P><p>A very important part of the text package is the View class.  As the name suggests it represents a view of the text model, or a piece of the textmodel.  It is this class that is responsible for the look of the text component.  The view is not intended to be some completely new thing that one must learn, but rather is much like a lightweight component.  In fact, the original Viewimplementation was a lightweight component.   There were several reasons whythe Component implementation was abandoned in favor of an alternative.<ol><li><p>There was barely had time to get the lightweight component support in the 1.1 version of the JDK.  There simply wasn't time to lighten up the component further to where it would need to be to be used for text purposes.  The additionsmade to JComponent increased the memory consumption, and as it currently stands it's much too heavy for representing text.</p><li><p>The layout semantics aren't quite right for text, and changing the current layout semantics of component might break existing applications.</p><li><p>The component api uses integers, but in 1.2 one can use floating point device independent coordinates.  An api that works in both 1.1 and 1.2 would be convenient for minimizing transition difficulties.  The View class uses the Shape interfaceand float arguments to enable View implementations for the Java 2 platform v1.2 and later whilestill functioning in the older 1.1 JDK.</p></ol><p>By default, a view is very light.  It contains a reference to the parent view from which it can fetch many things without holding state, and it contains a reference to a portion of the model (Element).  A view does not have to exactly represent an element in the model, that is simply a typical and therefore convenient mapping.  A view can alternatively maintain a couple of Position objects to maintain it's location in the model (i.e. represent a fragment of an element).  This is typically the result of formatting where views have been broken down into pieces.  The convenience of a substantial relationship to the element makes it easier to build factories to produce the views, and makes it easier  to keep track of the view pieces as the model is changed and the view must be changed to reflect the model.  Simple views therefore represent an Element directly and complex views do not.<p>A view has the following responsibilities:<dl><dt><b>Participate in layout.</b><dd><p>The view has a setSize method which is like doLayout and setSize in Component combined.  The view has a preferenceChanged method which is like invalidate in Component except that one can invalidate just one axis and the child requesting the change is identified.<p>A View expresses the size that it would like to be in terms of threevalues, a minimum, a preferred, and a maximum span.  Layout in a view iscan be done independantly upon each axis.  For a properly functioning Viewimplementation, the minimum span will be &lt;= the preferred span which in turnwill be &lt;= the maximum span.</p><p align=center><img src="doc-files/View-flexibility.jpg"><p>The minimum set of methods for layout are:<ul><li><a href="#getMinimumSpan(int)">getMinimumSpan</a><li><a href="#getPreferredSpan(int)">getPreferredSpan</a><li><a href="#getMaximumSpan(int)">getMaximumSpan</a><li><a href="#getAlignment(int)">getAlignment</a><li><a href="#preferenceChanged(javax.swing.text.View, boolean, boolean)">preferenceChanged</a><li><a href="#setSize(float, float)">setSize</a></ul><p>The setSize method should be prepared to be called a number of times(i.e. It may be called even if the size didn't change).  The setSize methodis generally called to make sure the View layout is complete prior to tryingto perform an operation on it that requires an up-to-date layout.  A viewssize should <em>always</em> be set to a value within the minimum and maximumspan specified by that view.  Additionally, the view must always call thepreferenceChanged method on the parent if it has changed the values for thelayout it would like, and expects the parent to honor.  The parent View isnot required to recognize a change until the preferenceChanged has been sent.This allows parent View implementations to cache the child requirements ifdesired.  The calling sequence looks something like the following:</p><p align=center><img src="doc-files/View-layout.jpg"><p>The exact calling sequence is up to the layout functionality ofthe parent view (if the view has any children).  The view may collectthe preferences of the children prior to determining what it will give each child, or it might iteratively update the children one at a time.</p><dt><b>Render a portion of the model.</b><dd><p>This is done in the paint method, which is pretty much like a component paint method.  Views are expected to potentially populate a fairly large tree.  A View has the following semantics for rendering:</p><ul><li>The view gets it's allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with.<li>The coordinate system is the same as the hosting Component (i.e. theComponent returned by the <a href="#getContainer">getContainer</a> method).This means a child view lives in the same coordinate system as the parentview unless the parent has explicitly changed the coordinate system.To schedule itself to be repainted a view can call repaint on the hostingComponent.<li>The default is to <em>not clip</em> the children.  It is more effecientto allow a view to clip only if it really feels it needs clipping.<li>The Graphics object given is not initialized in any way.  A view shouldset any settings needed.<li>A View is inherently transparent.  While a view may render into it'sentire allocation, typically a view does not.  Rendering is performed bytranversing down the tree of View implementations.  Each View is responsiblefor rendering it's children.  This behavior is depended upon for threadsafety.  While view implementations do not necessarily have to be implementedwith thread safety in mind, other view implementations that do make use ofconcurrency can depend upon a tree traversal to guarantee thread safety.<li>The order of views relative to the model is up to the implementation.Although child views will typically be arranged in the same order that theyoccur in the model, they may be visually arranged in an entirely different order.  View implementations may have Z-Order associated with them if thechildren are overlapping.</ul><p>The methods for rendering are:<ul><li><a href="#paint(java.awt.Graphics, java.awt.Shape)">paint</a></ul><p><dt><b>Translate between the model and view coordinate systems.</b><dd><p>Because the view objects are produced from a factory and therefore cannot necessarily be counted upon to be in a particular pattern, one must be able to perform translation to properly locate spatial representation of the model.  The methods for doing this are:<ul><li><a href="#modelToView(int, javax.swing.text.Position.Bias, int, javax.swing.text.Position.Bias, java.awt.Shape)">modelToView</a><li><a href="#viewToModel(float, float, java.awt.Shape, javax.swing.text.Position.Bias[])">viewToModel</a><li><a href="#getDocument()">getDocument</a><li><a href="#getElement()">getElement</a><li><a href="#getStartOffset()">getStartOffset</a><li><a href="#getEndOffset()">getEndOffset</a></ul><p>The layout must be valid prior to attempting to make the translation.The translation is not valid, and must not be attempted while changesare being broadcasted from the model via a DocumentEvent.  </p><dt><b>Respond to changes from the model.</b><dd><p>If the overall view is represented by many pieces (which is the best situation if one want to be able to change the view and write the least amount of new code), it would be impractical to have a huge number of DocumentListeners.  If each view listened to the model, only a few would actually be interested in the changes broadcasted at any given time.   Since the model has no knowledge of views, it has no way to filter the broadcast of change information.  The view hierarchy itself is instead responsible for propagating the change information.  At any level in the view hierarchy, that view knows enough about it's children to best distribute the change information further.   Changes are therefore broadcasted starting from the root of the view hierarchy.The methods for doing this are:<ul><li><a href="#insertUpdate">insertUpdate</a><li><a href="#removeUpdate">removeUpdate</a><li><a href="#changedUpdate">changedUpdate</a></ul>    <p></dl><P><HR><P><!-- ======== INNER CLASS SUMMARY ======== --><!-- =========== FIELD SUMMARY =========== --><A NAME="field_summary"><!-- --></A><TABLE BORDER="1" CELLPADDING="3" CELLSPACING="0" WIDTH="100%"><TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><TD COLSPAN=2><FONT SIZE="+2"><B>Field Summary</B></FONT></TD></TR><TR BGCOLOR="white" CLASS="TableRowColor"><TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1"><CODE>static&nbsp;int</CODE></FONT></TD><TD><CODE><B><A HREF="../../../javax/swing/text/View.html#BadBreakWeight">BadBreakWeight</A></B></CODE><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The weight to indicate a view is a bad break opportunity for the purpose of formatting.</TD></TR><TR BGCOLOR="white" CLASS="TableRowColor">

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -