Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

reformatted for 79 chars width and added wxToolBar docs

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@18814 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Václav Slavík
2003-01-18 23:50:36 +00:00
parent c37ffc1fef
commit 432be5aade
1 changed files with 81 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

114
docs/tech/tn0014.txt
View File

@@ -56,8 +56,8 @@ can think of it as attribute value syntax definition).
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
@@ -83,15 +83,16 @@ subnodes, all of which must have the "name" property.
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:
@@ -99,18 +100,19 @@ 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> 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_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:
@@ -188,11 +190,12 @@ size (wxSize type) and not position (wxPosition type).
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
@@ -204,12 +207,12 @@ wxArtClient respectively) values as used by wxArtProvider (because the user may
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.
@@ -300,6 +303,51 @@ size Size -1,-1
style Style[wxScrolledWindow] wxHSCROLL | wxVSCROLL
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
================