2. Elementary description
=========================
-XRC resource file is a well-formed XML 1.0 document. All elements of XRC file are
-from the http://www.wxwindows.org/wxxrc namespace.
+XRC resource file is a well-formed XML 1.0 document. All elements of XRC file
+are from the http://www.wxwindows.org/wxxrc namespace.
The root node of XRC document must be <resource>. The <resource> node has
optional "version" property. Default version (in absence of the version
The <object> node represents a single object (GUI element) and it usually maps
directly to a wxWindows class instance. It three properties: "name", "class"
and "subclass". "class" must always be present, it tells XRC what wxWindows
-object should be created in this place. The other two are optional.
-"name" is ID used to identify the object. It is the value passed to the XRCID() macro
-and is also used to construct wxWindow's id and name attributes and must be unique
-among all children of the neareset container object (wxDialog, wxFrame, wxPanel,
-wxNotebook) upside from the object in XML nodes hiearchy (two distinct containers
-may contain objects with same "name", though). "subclass" is
-optional name of class whose constructor will be called instead of the constructor
-for "class". Subclass must be available in the program that loads the resource,
-must be derived from "class" and must be registered within wxWindows' RTTI system.
+object should be created in this place. The other two are optional. "name" is
+ID used to identify the object. It is the value passed to the XRCID() macro and
+is also used to construct wxWindow's id and name attributes and must be unique
+among all children of the neareset container object (wxDialog, wxFrame,
+wxPanel, wxNotebook) upside from the object in XML nodes hiearchy (two distinct
+containers may contain objects with same "name", though). "subclass" is
+optional name of class whose constructor will be called instead of the
+constructor for "class". Subclass must be available in the program that loads
+the resource, must be derived from "class" and must be registered within
+wxWindows' RTTI system.
Example:
...
</object>
-<object> node may have arbitrary child nodes. What child nodes and their semantics
-are class-dependent and are defined later in this document. The user is allowed
-to register new object handlers within XRC and extend it to accept new <object>
-classes (and therefore different <object>'s child nodes).
-
-<object_ref> node is identical to <object>, except that it does _not_ have "class"
-property and has additonal required property "ref". It's concept is similar to Unix
-symlinks: value of the "ref" property is equal to the value of "name" property of
-some existing node (called referred node) in the resources (not neccessary top-level).
-Referred node's "class" property and all subnodes are copied in place of the referee
-<object_ref> node which is then processed as regular <object> node. If the <object_ref>
-node itself has child nodes, then these nodes _override_ any nodes from the referred node.
+<object> node may have arbitrary child nodes. What child nodes and their
+semantics are class-dependent and are defined later in this document. The user
+is allowed to register new object handlers within XRC and extend it to accept
+new <object> classes (and therefore different <object>'s child nodes).
+
+<object_ref> node is identical to <object>, except that it does _not_ have
+"class" property and has additonal required property "ref". It's concept is
+similar to Unix symlinks: value of the "ref" property is equal to the value of
+"name" property of some existing node (called referred node) in the resources
+(not neccessary top-level). Referred node's "class" property and all subnodes
+are copied in place of the referee <object_ref> node which is then processed as
+regular <object> node. If the <object_ref> node itself has child nodes, then
+these nodes _override_ any nodes from the referred node.
Example:
Style[wxSomeClass]
------------------
List of style flags that can be passed to wxSomeClass' constructor. Flags are
-written in same way as in C++ code (e.g. "wxSUNKEN_BORDER", "wxHW_SCROLLBAR_NEVER")
-and are delimined with any combination of whitespaces and '|'. Possible flags
-are class-dependent and are not described in this technote. Please refer to wxWindows
-manual for all styles that given class can accept; if XRC does not accept a flag
-listed in wxWindows documentation, it is a bug.
+written in same way as in C++ code (e.g. "wxSUNKEN_BORDER",
+"wxHW_SCROLLBAR_NEVER") and are delimined with any combination of whitespaces
+and '|'. Possible flags are class-dependent and are not described in this
+technote. Please refer to wxWindows manual for all styles that given class can
+accept; if XRC does not accept a flag listed in wxWindows documentation, it is
+a bug.
Bitmap
define own constants, efectively any string is legal here). Examples are
"wxART_FILE_OPEN" (id) or "wxART_MENU" (client).
-Any of "stock_id" or "stock_client" properties or the filename may be omitted. XRC
-determines the bitmap to use according to this algorithm:
- 1. If there is non-empty "stock_id" property, query wxArtProvider for the bitmap
- (if there is no "stock_client", use default one, which is usually wxART_OTHER;
- exceptions are noted in class-specific sections bellow). If the query fails,
- continue to 2.
+Any of "stock_id" or "stock_client" properties or the filename may be omitted.
+XRC determines the bitmap to use according to this algorithm:
+ 1. If there is non-empty "stock_id" property, query wxArtProvider for the
+ bitmap (if there is no "stock_client", use default one, which is usually
+ wxART_OTHER; exceptions are noted in class-specific sections bellow). If
+ the query fails, continue to 2.
2. Load the bitmap from the file in attribute value.
style Style[wxScrolledWindow] wxHSCROLL | wxVSCROLL
+wxSplitterWindow
+----------------
+position Position -1,-1
+size Size -1,-1
+style Style[wxSplitterWindow] wxSP_3D
+sashpos Integer 0
+ (Initial sash position)
+minsize Integer -1
+ (Minimal panel size)
+orientation "horizontal"|"vertical" horizontal
+
+wxSplitterWindow must have at least one and at most two children objects.
+If there's only one child object, it is passed to wxSplitterWindow::Initialize
+and the splitter is created unsplitted. If there are two children, the
+splitter is created splitted, either horizontally or vertically depending
+on the value of "orientation" attribute.
+
+
+wxToolBar
+---------
+position Position -1,-1
+size Size -1,-1
+style Style[wxToolBar] wxNO_BORDER|wxTB_HORIZONTAL
+bitmapsize Size -1,-1
+ (Size of contained bitmaps)
+margins Size -1,-1
+packing Integer -1
+separation Integer -1
+
+wxToolBar node may have children <object> and <object_ref> nodes. Their class
+may be either "tool", "separator" or any wxWindows class derived from
+wxControl. "tool" and "separator" are special pseudo-classes that may only
+appear within wxToolBar node. Their attributes are as follows:
+
+ separator
+ ---------
+ (doesn't have any attributes)
+
+ tool
+ ----
+ bitmap Bitmap
+ bitmap2 Bitmap wxNullBitmap
+ toggle Boolean 0
+ radio Boolean 0
+ label I18nString ""
+ tooltip I18nString ""
+ longhelp I18nString ""
+ position Position -1,-1
+
+ Constraints:
+ At most one of "toggle" and "radio" attributes may be 1.
+ Attribute "position" may not appear if "label" or "radio" attributes
+ are used or if parent wxToolBar's style contains wxTB_TEXT.
+
+ Note:
+ Use of "position" attribute is strongly discouraged, it is deprecated
+ usage of wxToolBar and it is not supported by MSW and GTK
+ implementations.
+
+Children objects are added to the toolbar using AddTool for "tool" class,
+AddSeparator for "separator" and AddControl for other classes.
+
+
5. More features
================
projects / wxWidgets.git / blobdiff