mirror of
https://git.dev.opencascade.org/repos/occt.git
synced 2025-04-03 17:56:21 +03:00
0024269: Content of occt documentation should be formated
building subsection introduced; wok moved to dev guides section;
Requirements and Installation sections were interchanged;
some Unicode characters removed from .md files; \DeclareUnicodeCharacter{00A0}{ } instruction added into refman file
images insertion rolled back to dual html,latex insertion; mainpage now is processed (index.tex);
surplus part of overview has been removed
foundation_classes.md and technical_overview.md updated;
Reviewed step, tobj, xde and partly iges; Corrections in other guides.
Overview installation and requirements changes updated
This commit is contained in:
ysn
bugmaster
parent
4df5470212
commit
dba69de2f0
@ -14,14 +14,15 @@ user_guides/ocaf/ocaf.md
|
||||
user_guides/tobj/tobj.md
|
||||
user_guides/shape_healing/shape_healing.md
|
||||
user_guides/draw_test_harness/draw_test_harness.md
|
||||
user_guides/wok/wok.md
|
||||
|
||||
dev_guides/dev_guides.md
|
||||
dev_guides/wok/wok.md
|
||||
dev_guides/cdl/cdl.md
|
||||
dev_guides/tests/tests.md
|
||||
dev_guides/documentation/documentation.md
|
||||
dev_guides/wok/wok.md
|
||||
|
||||
dev_guides/building/building.md
|
||||
dev_guides/building/wok/wok.md
|
||||
dev_guides/building/automake.md
|
||||
dev_guides/building/cmake.md
|
||||
dev_guides/building/code_blocks.md
|
||||
|
||||
@ -88,7 +88,7 @@ This License does not grant any rights to use the trademarks, trade names and do
|
||||
|
||||
### 11. Copyright
|
||||
|
||||
The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright © notice which appears when You download the Software.
|
||||
The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright (c) notice which appears when You download the Software.
|
||||
|
||||
|
||||
### 12. Term
|
||||
@ -133,7 +133,7 @@ Open CASCADE S.A.S. is a French société par actions simplifiée having its mai
|
||||
|
||||
The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License").
|
||||
You may not use the content of this file except in compliance with the License.
|
||||
Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
|
||||
Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright (c) Open CASCADE S.A.S., 2001. All rights reserved.
|
||||
|
||||
"The Original Code and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement.
|
||||
|
||||
@ -146,9 +146,9 @@ Please see the License for the specific terms and conditions governing rights an
|
||||
|
||||
#### Schedule "B"
|
||||
|
||||
"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
|
||||
"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright (c) Open CASCADE S.A.S., 2001. All rights reserved.
|
||||
|
||||
Modifications to the Original Code have been made by ________________________. Modifications are copyright © [Year to be included]. All rights reserved.
|
||||
Modifications to the Original Code have been made by ________________________. Modifications are copyright (c) [Year to be included]. All rights reserved.
|
||||
|
||||
The software Open CASCADE Technology and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
|
||||
|
||||
|
||||
@ -3,29 +3,31 @@ Overview {#mainpage}
|
||||
|
||||
@section OCCT_OVW_SECTION_1 Welcome
|
||||
|
||||
Welcome to Open CASCADE Technology version 6.6.0, a minor release,
|
||||
Welcome to Open CASCADE Technology version 6.7.0, a minor release,
|
||||
which introduces a number of new features and improved traditional
|
||||
functionality along with some changes over the previous maintenance release 6.5.5.
|
||||
functionality along with some changes over the previous release 6.6.0.
|
||||
|
||||
This release makes Open CASCADE Technology even a more powerful and stable
|
||||
development platform for 3D modeling and numerical simulation applications.
|
||||
|
||||
Open CASCADE Technology 6.6.0 is a full-featured package that allows developing
|
||||
Open CASCADE Technology 6.7.0 is a full-featured package that allows developing
|
||||
applications on Windows and Linux platforms.
|
||||
|
||||
@htmlonly<center>@endhtmlonly http://www.opencascade.org
|
||||
|
||||
|
||||
@image html /overview/images/overview_occttransparent.png
|
||||
@image latex /overview/images/overview_occttransparent.png
|
||||
|
||||
Copyright © 2001-2013 OPEN CASCADE S.A.S.
|
||||
Copyright (c) 2001-2013 OPEN CASCADE S.A.S.
|
||||
|
||||
|
||||
@image html /resources/occt_logo.png
|
||||
@image latex /resources/occt_logo.png
|
||||
|
||||
@htmlonly</center>@endhtmlonly
|
||||
|
||||
@section OCCT_OVW_SECTION_2 Copyrights
|
||||
|
||||
Copyright© 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
|
||||
Copyright(c) 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
|
||||
|
||||
Trademark information
|
||||
----------------------
|
||||
@ -77,7 +79,7 @@ text image generation tools, and many other products.
|
||||
|
||||
FreeType 2 is released under two open-source licenses: BSD-like FreeType License and the GPL.
|
||||
|
||||
**Intel® Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program.
|
||||
**Intel(R) Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program.
|
||||
It is a library that helps you to take advantage of multi-core processor performance without having to be a threading expert.
|
||||
Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that
|
||||
abstracts platform details and threading mechanisms for scalability and performance.
|
||||
@ -85,7 +87,7 @@ TBB is available under GPLv2 license with the runtime exception.
|
||||
|
||||
Open CASCADE Technology WOK module on Windows also makes use of LGPL-licensed C routines * regexp and getopt, taken from GNU C library.
|
||||
|
||||
**Doxygen** (Copyright © 1997-2010 by Dimitri van Heesch) is open source documentation system for
|
||||
**Doxygen** (Copyright (c) 1997-2010 by Dimitri van Heesch) is open source documentation system for
|
||||
C++, C, Java, Objective-C, Python, IDL, PHP and C#. This product is used in Open CASCADE Technology
|
||||
for automatic creation of Technical Documentation from C++ header files.
|
||||
If you need further information on Doxygen, please refer to http://www.stack.nl/~dimitri/doxygen/index.html.
|
||||
@ -169,6 +171,74 @@ then run **wgendoc** command with required arguments
|
||||
|
||||
e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm
|
||||
|
||||
@section OCCT_OVW_SECTION_5 Requirements
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_1 Linux Intel
|
||||
<table>
|
||||
<tr> <th>Operating System </th> <th> 64-bit: Mandriva 2010, CentOS 5. 5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu-1304, Debian 6.0 * </th> </tr>
|
||||
<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
|
||||
<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space. </td > </tr>
|
||||
<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
|
||||
<tr> <td> Video card </td> <td> **GeForce** The following versions of GeForce drivers are recommended: 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html </td > </tr>
|
||||
<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
|
||||
<tr> <td>C++ </td> <td>GNU gcc 4.0. - 4.7.3. </td > </tr>
|
||||
<tr> <td> TCL (for testing tools) </td> <td> Tcltk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/8.6.html</td > </tr>
|
||||
<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.nokia.com/downloads </td > </tr>
|
||||
<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
|
||||
<tr> <td> FreeImage (Support of common graphic formats) </td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
|
||||
<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
|
||||
<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
|
||||
<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/ </td> </tr>
|
||||
</table>
|
||||
\* Debian 60 64 bit is a permanently tested platform.
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_2 Windows Intel
|
||||
|
||||
<table>
|
||||
<tr> <th>Operating System </th> <th> 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3 </th> </tr>
|
||||
<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
|
||||
<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 650 Mb of disk space but during the process of installation you will need 1,2 Gb of free disk space. </td > </tr>
|
||||
<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
|
||||
<tr> <td> Video card </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx
|
||||
</td > </tr>
|
||||
<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
|
||||
<tr> <td>C++ </td> <td>Microsoft Visual Studio .NET 2005 SP1 with all security updates
|
||||
Microsoft Visual Studio .NET 2008 SP1*
|
||||
Microsoft Visual Studio .NET 2010
|
||||
Microsoft Visual Studio .NET 2012
|
||||
Microsoft Visual Studio .NET 2013
|
||||
</td > </tr>
|
||||
<tr> <td> TCL (for testing tools) </td> <td> TActiveTcl 8.5 or 8.6
|
||||
http://www.activestate.com/activetcl/downloads </td > </tr>
|
||||
<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr>
|
||||
<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
|
||||
<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
|
||||
<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
|
||||
<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
|
||||
<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/ </td> </tr>
|
||||
</table>
|
||||
|
||||
* The official release of OCCT for Windows contains libraries built with VC++ 2008.
|
||||
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_3 MAC OS X
|
||||
|
||||
<table>
|
||||
<tr> <th>Operating System </th> <th> Mac OS X 10.6.8 Snow Leopard / 10.7 Lion </th> </tr>
|
||||
<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
|
||||
<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space. </td > </tr>
|
||||
<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
|
||||
<tr> <td> Video card </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx
|
||||
</td > </tr>
|
||||
<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
|
||||
<tr> <td>C++ </td> <td>XCode 3.2 or newer (4.x is recommended) </td > </tr>
|
||||
<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr>
|
||||
<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
|
||||
<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
|
||||
<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
|
||||
<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
|
||||
<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td> OpenCL 1.2.8 native </td> </tr>
|
||||
</table>
|
||||
|
||||
@section OCCT_OVW_SECTION_4 Installation
|
||||
|
||||
@ -209,26 +279,32 @@ and build it using the relevant tools. For additional convenience of the users,
|
||||
OPEN CASCADE also provides the documents with recommendations on building
|
||||
third-party products from source files.
|
||||
|
||||
|
||||
|
||||
When the installation is complete, you will find the following directories
|
||||
(some might be absent in case of custom installation):
|
||||
|
||||
|
||||
|
||||
### Description of directory tree
|
||||
@image html /overview/images/overview_installation.png "The directory tree"
|
||||
@image latex /overview/images/overview_installation.png "The directory tree"
|
||||
|
||||
|
||||
* **3rdparty** * This folder contains third-party products necessary to compile and use OCCT as well as start sample applications with Visual C++ 2008;
|
||||
* **ros/adm** * This folder contains administration files, which allow rebuilding OCCT;
|
||||
* **ros/adm/cmake** * This folder contains files of CMake building procedure;
|
||||
* **ros/adm/msvc** * This folder contains Visual Studio projects for Visual C++ 2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
|
||||
* **ros/data** * This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
|
||||
* **ros/doc** * This folder contains OCCT Overview documentation;
|
||||
* **ros/drv** * This folder contains source files generated by WOK (private header files and instantiations of generic classes);
|
||||
* **ros/inc** * This folder contains all OCCT header files;
|
||||
* **ros/samples** * This folder contains sample applications.
|
||||
* **ros/src** * This folder contains OCCT source files. They are organized in folders, one per development unit;
|
||||
* **ros/tests** * This folder contains scripts for OCCT testing.
|
||||
* **ros/win32/vc9** * This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2008;
|
||||
|
||||
* **adm** This folder contains administration files, which allow rebuilding OCCT;
|
||||
* **adm/cmake** This folder contains files of CMake building procedure;
|
||||
* **adm/msvc** This folder contains Visual Studio projects for Visual C++ 2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
|
||||
* **data** This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
|
||||
* **doc** This folder contains OCCT Overview documentation;
|
||||
* **drv** This folder contains source files generated by WOK (private header files and instantiations of generic classes);
|
||||
* **inc** This folder contains all OCCT header files;
|
||||
* **samples** This folder contains sample applications.
|
||||
* **src** This folder contains OCCT source files. They are organized in folders, one per development unit;
|
||||
* **tests** This folder contains scripts for OCCT testing.
|
||||
* **win32/vc9** This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2008;
|
||||
|
||||
3rd party products have been moved to the root of Open CASCADE installation.
|
||||
|
||||
@image html /overview/images/overview_3rdparty.png "The third-party products"
|
||||
@image latex /overview/images/overview_3rdparty.png "The third-party products"
|
||||
|
||||
|
||||
@subsection OCCT_OVW_SECTION_4_2 System Environment Variables
|
||||
@ -266,7 +342,7 @@ The scripts are located in the OpenCACADE<version_number>/ros folder of the sour
|
||||
* **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
|
||||
* **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only);
|
||||
* **MMGT_OPT** if set to 1, the memory manager performs optimizations as described below; if set to 2,
|
||||
Intel ® TBB optimized memory manager is used; if 0 (default), every memory block is allocated
|
||||
Intel (R) TBB optimized memory manager is used; if 0 (default), every memory block is allocated
|
||||
in C memory heap directly (via malloc() and free() functions).
|
||||
In the latter case, all other options except MMGT_CLEAR and MMGT_REENTRANT are ignored;
|
||||
* **MMGT_CLEAR** if set to 1 (default), every allocated memory block is cleared by zeros;
|
||||
@ -312,89 +388,12 @@ in XML validators or editors, together with persistent XmlOcaf documents;
|
||||
* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
|
||||
* **TCLLIBPATH**, **TCL_LIBRARY**, **TK_LIBRARY** and **TIX_LIBRARY** are required to allow work with **DRAW** and **WOK**.
|
||||
|
||||
|
||||
@section OCCT_OVW_SECTION_5 Requirements
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_1 Linux Intel
|
||||
|
||||
| Operating System | 32/64-bit: Debian: 4.0, Mandriva: 2010* |
|
||||
| :--------------------------------------------- | :------------------------------------------------------------------------------------------------- |
|
||||
| Minimum memory | 512 Mb, 1 Gb recommended |
|
||||
| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
|
||||
| Minimum swap space | 500 Mb |
|
||||
| Video card | GeForce, |
|
||||
| | The following versions of GeForce drivers are recommended: |
|
||||
| | 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html |
|
||||
| | 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
|
||||
| C++ | GNU gcc 4.0. * 4.3.2. |
|
||||
| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
|
||||
| | http://www.tcl.tk/software/tcltk/8.6.html |
|
||||
| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
|
||||
| Freetype (OCCT Text rendering) | freetype-2.4.10 |
|
||||
| | http://sourceforge.net/projects/freetype/files/ |
|
||||
| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
|
||||
| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
|
||||
| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
|
||||
| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
|
||||
| TBB (optional tool for parallelized | TBB 3.x or 4.x |
|
||||
| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_2 Windows Intel
|
||||
|
||||
| Operating System | 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3 |
|
||||
| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
|
||||
| Minimum memory | 512 Mb, 1 Gb recommended |
|
||||
| Free disk space | For full installation Open CASCADE Technology requires 650 Mb of disk space. |
|
||||
| (complete installation) | but during the process of installation you will need 1,2 Gb of free disk space. |
|
||||
| Minimum swap space | 500 Mb |
|
||||
| Video card | GeForce, |
|
||||
| | Version 266.58 WHQL or later is recommended:http://www.nvidia.com/Download/index.aspx |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
|
||||
| C++ | Microsoft Visual Studio .NET 2005 SP1 with all security updates |
|
||||
| | Microsoft Visual Studio .NET 2008 SP1* |
|
||||
| | Microsoft Visual Studio .NET 2010 |
|
||||
| | Microsoft Visual Studio .NET 2012 |
|
||||
| TCL (for testing tools) | ActiveTcl 8.5 or 8.6 |
|
||||
| | http://www.activestate.com/activetcl/downloads |
|
||||
| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
|
||||
| Freetype (OCCT Text rendering) | freetype-2.4.10 |
|
||||
| | http://sourceforge.net/projects/freetype/files/ |
|
||||
| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
|
||||
| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
|
||||
| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
|
||||
| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
|
||||
| TBB (optional tool for parallelized | TBB 3.x or 4.x |
|
||||
| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_3 MAC OS X
|
||||
|
||||
| Operating System | Requires Mac OS X 10.6.8 Snow Leopard / 10.7 Lion |
|
||||
| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
|
||||
| Minimum memory | 512 Mb, 1 Gb recommended |
|
||||
| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
|
||||
| Minimum swap space | 500 Mb |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
|
||||
| C++ | XCode 3.2 or newer (4.x is recommended) |
|
||||
| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
|
||||
| | http://www.tcl.tk/software/tcltk/8.6.html |
|
||||
| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
|
||||
| Freetype (OCCT Text rendering) | freetype-2.4.10 |
|
||||
| | http://sourceforge.net/projects/freetype/files/ |
|
||||
| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
|
||||
| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
|
||||
| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
|
||||
| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
|
||||
| TBB (optional tool for parallelized | TBB 3.x or 4.x |
|
||||
| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
|
||||
|
||||
|
||||
@section OCCT_OVW_SECTION_6 Release Notes
|
||||
|
||||
|
||||
Open CASCADE Technology latest version
|
||||
@htmlonly
|
||||
<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/release_notes.pdf">Release Notes</a>
|
||||
<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.7.0/doc/release_notes.pdf">Release Notes</a>
|
||||
@endhtmlonly (PDF)
|
||||
|
||||
|
||||
@ -407,7 +406,8 @@ Draw is a command interpreter based on TCL and a graphical system used for testi
|
||||
|
||||
Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
|
||||
|
||||
|
||||
@image html /overview/images/overview_draw.png
|
||||
@image latex /overview/images/overview_draw.png
|
||||
|
||||
Scripts can be written to customize Draw and perform tests.
|
||||
New types of objects and new commands can be added using C++ programming language.
|
||||
@ -528,7 +528,8 @@ The list of MFC samples:
|
||||
* Animation
|
||||
* Convert
|
||||
|
||||
|
||||
@image html /overview/images/overview_mvc.png
|
||||
@image latex /overview/images/overview_mvc.png
|
||||
|
||||
**Remarks:**
|
||||
|
||||
@ -545,7 +546,8 @@ OCCT contains three samples based on Qt application framework
|
||||
|
||||
Import Export programming sample contains 3D Viewer and Import // Export functionality.
|
||||
|
||||
|
||||
@image html /overview/images/overview_qt.png
|
||||
@image latex /overview/images/overview_qt.png
|
||||
|
||||
Tutorial
|
||||
---------
|
||||
@ -582,7 +584,8 @@ for testing this functionality (accessible only through TEST pre-processor defin
|
||||
|
||||
C# sample containing 3D Viewer and Import // Export functionality.
|
||||
|
||||
|
||||
@image html /overview/images/overview_c__ie.png
|
||||
@image latex /overview/images/overview_c__ie.png
|
||||
|
||||
Import:
|
||||
|
||||
@ -602,3 +605,7 @@ Export:
|
||||
|
||||
* C# sample is available only on Windows platform;
|
||||
* It is delivered in source code only and must be built with Microsoft Visual C++ 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
32
dox/dev_guides/building/building.md
Normal file
32
dox/dev_guides/building/building.md
Normal file
@ -0,0 +1,32 @@
|
||||
Building OCCT Libraries {#dev_guides__building}
|
||||
=========
|
||||
|
||||
The source package of the Open CASCADE Technology including the source files of samples
|
||||
and tools and the set of building procedures is available for self-dependent preparation
|
||||
binary files on UNIX and Windows platforms.
|
||||
|
||||
In order to build OCCT libraries from these sources for use in your program,
|
||||
you need to:
|
||||
|
||||
1. Install the required third-party libraries.
|
||||
|
||||
Follow the instructions provided in the documents titled "Building 3rd party
|
||||
products for OCCT" on http://dev.opencascade.org/?q=home/resources for
|
||||
choice of the needed libraries, their installation and building.
|
||||
|
||||
2. If you use OCCT sources from Git repository or do come changes affecting
|
||||
CDL files or dependencies of OCCT toolkit, update header files generated
|
||||
from CDL, and regenerate build scripts for your environment using WOK.
|
||||
See \subpage dev_guides__building__wok "WOK" for details.
|
||||
|
||||
Skip to step 3 if you use complete source package (e.g. official OCCT
|
||||
release) without changes in CDL.
|
||||
|
||||
3. Build using your preferred build tool.
|
||||
- \subpage dev_guides__building__automake "Building on Linux with Autotools"
|
||||
- \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
|
||||
- \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
|
||||
- \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
|
||||
- \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
|
||||
|
||||
The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
|
||||
BIN
dox/dev_guides/building/wok/images/wok_image001.jpg
Normal file
BIN
dox/dev_guides/building/wok/images/wok_image001.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
dox/dev_guides/building/wok/images/wok_image002.jpg
Normal file
BIN
dox/dev_guides/building/wok/images/wok_image002.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
157
dox/dev_guides/building/wok/wok.md
Normal file
157
dox/dev_guides/building/wok/wok.md
Normal file
@ -0,0 +1,157 @@
|
||||
WOK {#dev_guides__building__wok}
|
||||
=========
|
||||
|
||||
WOK is a legacy build environment for Open CASCADE Technology. It is required
|
||||
for generation of header files for classes defined with @ref ug_cdl "CDL"
|
||||
("Cascade Definition Language"). Also tools for generation of project files
|
||||
for other build systems, and OCCT documentation, are integrated to WOK.
|
||||
|
||||
WOK thus is needed in the following situations:
|
||||
- Building from OCCT sources from Git repository (do not contain generated files)
|
||||
- Building after some changes made in CDL files
|
||||
|
||||
Before installing and using WOK, make sure that you have installed a compiler (it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS) and third-party components required for building OCCT.
|
||||
|
||||
@section wok1 Installing WOK
|
||||
|
||||
Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
|
||||
|
||||
@subsection wok11 Windows
|
||||
|
||||
Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
|
||||
|
||||
@image html /dev_guides/building/wok/images/wok_image001.jpg
|
||||
@image latex /dev_guides/building/wok/images/wok_image001.jpg
|
||||
|
||||
Click Next and proceed with the installation.
|
||||
At the end of the installation you will be prompted to specify the version and the location of Visual Studio to be used, and the location of third-party libraries:
|
||||
|
||||
@image html /dev_guides/building/wok/images/wok_image002.jpg
|
||||
@image latex /dev_guides/building/wok/images/wok_image002.jpg
|
||||
|
||||
You can change these settings at any time later. For this click on the item "Customize environment (GUI tool)" in the WOK group in the Windows Start menu.
|
||||
|
||||
The shortcuts from this group provide two ways to run WOK:
|
||||
* In command prompt window ("WOK TCL shell").
|
||||
* In Emacs editor ("WOK Emacs"). Using Emacs is convenient if you need to work within WOK environment.
|
||||
|
||||
By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev).
|
||||
|
||||
@subsection wok12 Linux
|
||||
|
||||
* Unpack the .tgz archive containing WOK distributive into an installation directory <WOK_INSTALL_DIR>.
|
||||
|
||||
* Perform the following commands assuming that you have unpacked WOK distributive archive into <WOK_INSTALL_DIR>:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
cd <WOK_INSTALL_DIR>/site
|
||||
wok_confgui.sh
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Define all necessary paths to third-party products in the dialog window:
|
||||
|
||||
@image html /dev_guides/building/wok/images/wok_image003.jpg
|
||||
@image latex /dev_guides/building/wok/images/wok_image003.jpg
|
||||
|
||||
* Run the following commands to create WOK LOC factory:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
cd <WOK_INSTALL_DIR>/site
|
||||
wok_init.sh
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Your installation procedure is over. To run WOK use one the following commands:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
cd <WOK_INSTALL_DIR>/site
|
||||
wok_emacs.sh
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
or
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
cd <WOK_INSTALL_DIR>/site
|
||||
wok_tclsh.sh
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@subsection wok13 Mac OS X
|
||||
|
||||
* In the Finder double click on wokSetup.dmg file. This will open a new window. Drag and drop "wokSetup" folder from this window at the location in the Finder where you want to install WOK, i.e. <WOK_INSTALL_DIR>.
|
||||
|
||||
* Browse in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokConfig. This will open a window with additional search path settings. Define all necessary paths to third-party products in the dialog window:
|
||||
|
||||
@image html /dev_guides/building/wok/images/wok_image004.jpg
|
||||
@image latex /dev_guides/building/wok/images/wok_image004.jpg
|
||||
|
||||
* Run the following commands to create WOK LOC factory:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
cd <WOK_INSTALL_DIR>/site
|
||||
wok_init.sh
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokEmacs.
|
||||
|
||||
|
||||
@section wok2 Initialization of Workbench
|
||||
|
||||
To start working with OCCT, clone the OCCT Git repository from the server (see http://dev.opencascade.org/index.php?q=home/resources for details) or unpack the source archive.
|
||||
|
||||
Then create a WOK workbench (command wcreate) setting its Home to the directory, where the repository is created ($CASROOT variable). The workbench should have the same name as that directory.
|
||||
|
||||
For example, assuming that OCCT repository has been cloned into D:/occt folder:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
LOC:dev> wcreate occt -DHome=D:/occt
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note: $CASROOT is equal to D:/occt now
|
||||
|
||||
Then you can work with this workbench using normal WOK functionality (wprocess, umake, etc.; see WOK User’s Guide for details) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or make command on Linux, as described below.
|
||||
|
||||
@section wok3 Generation of building projects
|
||||
|
||||
Use command wgenproj in WOK to generate derived headers, source and building projects files:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
LOC:dev> wokcd occt
|
||||
LOC:dev:occt> wgenproj [ -target=<TARGET> ] [ -no_wprocess ]
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
TARGET:
|
||||
* vc8 - Visual Studio 2005
|
||||
* vc9 - Visual Studio 2008
|
||||
* vc10 - Visual Studio 2010
|
||||
* vc11 - Visual Studio 2012
|
||||
* cbp - CodeBlocks
|
||||
* cmake - CMake
|
||||
* amk - AutoMake
|
||||
* xcd - Xcode
|
||||
-no_wprocess - skip generation of derived headers and source files
|
||||
|
||||
Note that this command takes several minutes to complete at the first call.
|
||||
|
||||
Re-execute this step to generate derived headers, source and building projects files if some CDL files in OCCT have been modified (either by you directly, or due to updates in the repository). Note that in some cases WOK may fail to update correctly; in such case remove sub-directories drv and .adm and repeat the command.
|
||||
|
||||
To regenerate derived headers and source files without regeneration of projects use command:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
LOC:dev> wokcd occt
|
||||
LOC:dev:occt> wprocess -DGroups=Src,Xcpp
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The generated building project has been placed into $CASROOT/adm folder:
|
||||
* for vc8 - $CASROOT/adm/msvc/vc8
|
||||
* for vc9 - $CASROOT/adm/msvc/vc9
|
||||
* for vc10 - $CASROOT/adm/msvc/vc10
|
||||
* for vc11 - $CASROOT/adm/msvc/vc11
|
||||
* for cbp - $CASROOT/adm/<OS> /cbp
|
||||
* for cmake - $CASROOT/adm/cmake
|
||||
* for amk - $CASROOT/adm/lin/amk
|
||||
* xcd - $CASROOT/adm/<OS>/xcd
|
||||
|
||||
@section wok4 Generation of documentation
|
||||
|
||||
Use command wgendoc in WOK to generate reference documentation:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
:LOC:dev> wokcd occt
|
||||
:LOC:dev:occt> wgendoc
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The following options can be used:
|
||||
* -wb=< workbench name > the name of OCCT workbench (the current one by default);
|
||||
* -m=< list of modules > the list of modules that will be contained in the documentation;
|
||||
* -outdir=< path > the output directory for the documentation;
|
||||
* -chm the option to generate CHM file;
|
||||
* -hhc=< path > the path to HTML Help Compiler (hhc.exe) or equivalent;
|
||||
* -qthelp=< path > the option to generate Qt Help file, it is necessary to specify the path to qthelpgenerator executable;
|
||||
* -doxygen=< path > the path to Doxygen executable
|
||||
* -dot=< path > the path to GraphViz dot executable
|
||||
@ -18,21 +18,10 @@ Using the services described in the **packages**, you can construct an **execut
|
||||
|
||||
To save data in a file, you need to define persistent classes. Then, you group these classes in a schema, which provides the necessary read/write tools.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image003.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image003.jpg
|
||||
|
||||
Figure 1. Building an Open CASCADE Technology application
|
||||
@section occt_1819379591_986437237 2. Introduction to CDL
|
||||
@subsection occt_1819379591_98643723721 Purposes of the Language
|
||||
@ -40,21 +29,8 @@ You can use CDL to **define data **in the Open CASCADE Technology environment.
|
||||
|
||||
You use CDL in the **design phase **of a development process to define a set of software components which best model the concepts stated in the application specification.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@image html /dev_guides/cdl/images/cdl_image004.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image004.jpg
|
||||
|
||||
Figure 2. The Development Process
|
||||
|
||||
@ -120,21 +96,9 @@ You declare the variables of a **data manipulation language **as being of certa
|
||||
|
||||
* Data types manipulated by handle (or reference)
|
||||
* Data types manipulated by value
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image005.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image005.jpg
|
||||
|
||||
Figure 3. Manipulation of data types
|
||||
|
||||
@ -333,16 +297,16 @@ Capital and small letters are not equivalent (i.e. AB, Ab, aB, ab are four diff
|
||||
|
||||
The following is a list of keywords.
|
||||
|
||||
alias any as asynchronous
|
||||
class client deferred end
|
||||
enumeration exception executable external
|
||||
fields friends from generic
|
||||
immutable imported inherits instantiates
|
||||
is library like me
|
||||
mutable myclass out package
|
||||
pointer primitive private protected
|
||||
raises redefined returns schema
|
||||
static to uses virtual
|
||||
alias any as asynchronous
|
||||
class client deferred end
|
||||
enumeration exception executable external
|
||||
fields friends from generic
|
||||
immutable imported inherits instantiates
|
||||
is library like me
|
||||
mutable myclass out package
|
||||
pointer primitive private protected
|
||||
raises redefined returns schema
|
||||
static to uses virtual
|
||||
|
||||
In a CDL file, the following characters are used as punctuation:
|
||||
; : , = ( ) [ ] ‘ “
|
||||
@ -361,12 +325,12 @@ There are two types of numeric constants: integer and real.
|
||||
An **integer **constant consists of a string of digits, which may or may not be preceded by a sign. Integer constants express whole numbers.
|
||||
**Examples**
|
||||
|
||||
1995 0 -273 +78
|
||||
1995 0 -273 +78
|
||||
|
||||
A **real **constant may or may not be preceded by a sign, and consists of an integral part followed by a decimal point and a fractional part (either one or both parts may be null, but both parts must always be present). It may also be followed by the letter E to indicate that the following figures represent the exponent (also optionally signed).
|
||||
**Examples**
|
||||
|
||||
5.0 0.0 -0.8E+3 5.67E-12
|
||||
5.0 0.0 -0.8E+3 5.67E-12
|
||||
|
||||
***Literal Constants***
|
||||
|
||||
@ -375,12 +339,12 @@ Literal constants include individual characters and strings of characters.
|
||||
An **individual character **constant is a single printable character enclosed by two apostrophes. (See the definition of the class Character in the Standard Package).
|
||||
**Examples**
|
||||
|
||||
‘B’ ‘y’ ‘&’ ‘*’ ‘’’ ‘‘
|
||||
‘B’ ‘y’ ‘&’ ‘*’ ‘’’ ‘‘
|
||||
|
||||
A **string **constant is composed of printable characters enclosed by quotation marks.
|
||||
**Examples**
|
||||
|
||||
’’G’’ ’’jjjj’’ ’’This is a character string, isn’t it?’’
|
||||
’’G’’ ’’jjjj’’ ’’This is a character string, isn’t it?’’
|
||||
|
||||
The **quotation mark **can itself appear within a character string as long as it is preceded by a backslash.
|
||||
**Examples**
|
||||
@ -408,20 +372,20 @@ Four of these primitives are known to the schema of the database because they i
|
||||
|
||||
The primitives inheriting from Storable are the following:
|
||||
|
||||
**Boolean **Is used to represent logical data. It has only two values:
|
||||
**Boolean **Is used to represent logical data. It has only two values:
|
||||
*True *and *False*.
|
||||
**Byte **8-bit number.
|
||||
**Character **Designates any ASCII character.
|
||||
**ExtCharacter **Is an extended character.
|
||||
**Integer **Is an integer number.
|
||||
**Real **Denotes a real number (i.e. one with a whole and a fractional part, either of which may be null).
|
||||
**ShortReal **Real with a smaller choice of values and memory size.
|
||||
**Byte **8-bit number.
|
||||
**Character **Designates any ASCII character.
|
||||
**ExtCharacter **Is an extended character.
|
||||
**Integer **Is an integer number.
|
||||
**Real **Denotes a real number (i.e. one with a whole and a fractional part, either of which may be null).
|
||||
**ShortReal **Real with a smaller choice of values and memory size.
|
||||
|
||||
There are also non-storable primitives. They are:
|
||||
|
||||
**CString **Is used for literal constants.
|
||||
**ExtString **Is an extended string.
|
||||
**Address **Represents a byte address of undetermined size.
|
||||
**CString **Is used for literal constants.
|
||||
**ExtString **Is an extended string.
|
||||
**Address **Represents a byte address of undetermined size.
|
||||
|
||||
The services offered by each of these types are described in the Standard Package.
|
||||
|
||||
@ -435,7 +399,8 @@ Two types are manipulated by handle:
|
||||
* Types defined using classes inheriting from the **Transient **class.
|
||||
These types are not storable as such in a file.
|
||||
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image006.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image006.jpg
|
||||
|
||||
Figure 4. Manipulation of a data type by reference
|
||||
|
||||
@ -446,22 +411,9 @@ Types, which are manipulated by value, behave in a more direct fashion than tho
|
||||
|
||||
You can store types known to the schema (i.e. either primitives or inheriting from Storable) and manipulated by value inside a persistent object as part of the representation. This is the only way for you to store objects “manipulated by value” in a file.
|
||||
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@image html /dev_guides/cdl/images/cdl_image007.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image007.jpg
|
||||
|
||||
Figure 5. Manipulation of a data type by value
|
||||
Three types are manipulated by value:
|
||||
|
||||
@ -522,21 +474,10 @@ The elements, which make up the definition of a class, are divided into four pa
|
||||
* the invariants
|
||||
* the internal representation
|
||||
* the friend methods and friend classes.
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image009.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image009.jpg
|
||||
|
||||
**Figure 7. Contents of a class**
|
||||
*** a deferred class does not have to contain a constructor**
|
||||
|
||||
@ -588,7 +529,7 @@ data-type}’)’]
|
||||
|
||||
@subsubsection occt_1819379591_1718435309331 Package declaration
|
||||
|
||||
**Packages** are used to group classes, which have some logical coherence. For example, the Standard Package groups together all the predefined resources of the language. In its simplest form, a package contains the declaration of all data types, which it introduces. You may also use a package to offer public methods and hide its internal classes by declaring them private.
|
||||
**Packages** are used to group classes, which have some logical coherence. For example, the Standard Package groups together all the predefined resources of the language. In its simplest form, a package contains the declaration of all data types, which it introduces. You may also use a package to offer public methods and hide its internal classes by declaring them private.
|
||||
** **
|
||||
**Example**
|
||||
|
||||
@ -629,7 +570,8 @@ Grouped behind the keyword **uses **are the names of all the packages containin
|
||||
|
||||
The methods you declare in a package do not belong to any particular class. **Package methods ***must *carry a name different from the data types contained in the package. Like any other method, they can be overloaded. With the exception of the keyword **me **and the visibility (a package method can *only *be either public or private) package methods are described in the same way as **instance methods**.
|
||||
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image010.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image010.jpg
|
||||
Figure 8. Contents of a package
|
||||
|
||||
The example of the package below includes some of the basic data structures:
|
||||
@ -716,7 +658,7 @@ is
|
||||
end SingleList;
|
||||
-- Third compilation unit, the class “Set” :
|
||||
generic class Set from Collection (Item as Storable)
|
||||
inherits
|
||||
inherits
|
||||
Persistent from Standard;
|
||||
raises
|
||||
NoSuchObject from Collection,
|
||||
@ -724,7 +666,7 @@ NoMoreObject from Collection
|
||||
private class Node instantiates SingleList
|
||||
from Collection (Item);
|
||||
-- etc....
|
||||
end Set;
|
||||
end Set;
|
||||
|
||||
|
||||
NOTE
|
||||
@ -828,7 +770,7 @@ const Handle(Standard_Type)& TYPE (MyPack_MyImport)
|
||||
static Handle(Standard_Type) _aType =
|
||||
new Standard_Type (“MyPack_MyImport”,sizeof
|
||||
(MyPack_MyImport))
|
||||
return _aType;
|
||||
return _aType;
|
||||
}
|
||||
|
||||
Then, add the names of these two files (MyPack_MyImport.hxx, MyPack_MyImport.cxx) to a file called FILES in the src subdirectory of the package. If the file does not exist you must create it.
|
||||
@ -938,11 +880,11 @@ end;
|
||||
|
||||
The behavior of an object class is defined by a list of **methods, **which are either **functions **or **procedures**. Functions return an object, whereas procedures only communicate by passing arguments. In both cases, when the transmitted object is an instance manipulated by a handle, its identifier is passed. There are three categories of methods:
|
||||
|
||||
**Object constructor **Creates an instance of the described class. A class will have one or more object constructors with various arguments or none.
|
||||
**Object constructor **Creates an instance of the described class. A class will have one or more object constructors with various arguments or none.
|
||||
|
||||
**Instance method **Operates on the instance which owns it.
|
||||
**Instance method **Operates on the instance which owns it.
|
||||
|
||||
**Class method **Does not work on individual instances, only on the class itself.
|
||||
**Class method **Does not work on individual instances, only on the class itself.
|
||||
|
||||
@subsubsection occt_1819379591_1972310108411 Object Constructors
|
||||
|
||||
@ -965,7 +907,7 @@ numeric-constant | literal-constant | named-constant
|
||||
declaration-of-constructed-type ::=
|
||||
**returns **[ **mutable **] class-name
|
||||
|
||||
The name of the constructors is fixed: “Create”. The object returned by a constructor is always of the type of the described class. If that type is manipulated by a handle, you *must *declare it as **mutable**, in which case the content of the instance it references is accessible for further modification.
|
||||
The name of the constructors is fixed: “Create”. The object returned by a constructor is always of the type of the described class. If that type is manipulated by a handle, you *must *declare it as **mutable**, in which case the content of the instance it references is accessible for further modification.
|
||||
|
||||
For example, the constructor of the class “Point”
|
||||
**Example**
|
||||
@ -1004,7 +946,7 @@ identifier formal-part-of-instance-method
|
||||
[ declaration-of-returned-type ]
|
||||
[ exception-declaration ]
|
||||
formal-part-of-instance-method ::=
|
||||
’(’ me [’:’ passing-mode parameter-access ] {’;’
|
||||
’(’ me [’:’ passing-mode parameter-access ] {’;’
|
||||
parameter}’)’
|
||||
parameter ::=
|
||||
identifier {’,’ identifier} ’:’ passing-mode
|
||||
@ -1124,8 +1066,8 @@ coord: Real[3];
|
||||
Depending on their type, Object fields have one of the two forms. When the field is of the “manipulated by handle” type, it corresponds to an identifier. In this case, the contents of the object can be shared by other objects or by a handle in a program. When the field is of a “manipulated by value” type, it contains the value of the object. In this case you say the object is **embedded**.
|
||||
|
||||
@subsection occt_1819379591_197231010843 Exceptions
|
||||
|
||||
Exceptions describe exceptional situations, which can arise during the execution of a method. With the raising of an exception, the normal course of program execution is interrupted. The actions carried out in response to this situation are called treatment of exception.
|
||||
|
||||
Exceptions describe exceptional situations, which can arise during the execution of a method. With the raising of an exception, the normal course of program execution is interrupted. The actions carried out in response to this situation are called treatment of exception.
|
||||
|
||||
exception-treatment ::= **raises **exception-name {’,’
|
||||
exception-name}
|
||||
@ -1146,11 +1088,11 @@ raises OutOfRange;
|
||||
|
||||
Instance methods are likely to raise certain exceptions called **systematic exceptions **which do not have to appear. They are:
|
||||
|
||||
**NullObject **Raised when the principal object does not exist.
|
||||
**NullObject **Raised when the principal object does not exist.
|
||||
|
||||
**ImmutableObject **Raised when a method tries to modify an immutable principal object.
|
||||
**ImmutableObject **Raised when a method tries to modify an immutable principal object.
|
||||
|
||||
**TypeMismatch **Raised if an argument typed by association is of an unsuitable type.
|
||||
**TypeMismatch **Raised if an argument typed by association is of an unsuitable type.
|
||||
|
||||
These exceptions are described in the Standard Package (System Toolkits).
|
||||
|
||||
@ -1176,7 +1118,7 @@ declaration-of-a-sub-class ::=
|
||||
|
||||
A class cannot inherit one of its descendent classes; nor can it inherit a native type. All the classes of a system can be described in a non-cyclic diagram called the **inheritance graph**.
|
||||
|
||||
The definition of a sub-class is identical to that of a simple class. Note that a super-class *must not *appear in the **uses **clause of the sub-class, even if it appears in the definition of the sub-class. The behavior of a sub-class includes as a minimum all instance methods and protected methods of its super-classes.
|
||||
The definition of a sub-class is identical to that of a simple class. Note that a super-class *must not *appear in the **uses **clause of the sub-class, even if it appears in the definition of the sub-class. The behavior of a sub-class includes as a minimum all instance methods and protected methods of its super-classes.
|
||||
|
||||
NOTE
|
||||
Note that constructors and class methods are never inherited.
|
||||
@ -1191,7 +1133,7 @@ declaration-of-a-redefined-method ::=
|
||||
identifier formal-part-of-instance-method [returnedtype-
|
||||
declaration]
|
||||
[declaration-of-exceptions]
|
||||
** is redefined **[visibility]’;’
|
||||
** is redefined **[visibility]’;’
|
||||
|
||||
A redefined method must conform to the syntax described in the super-class where it appears. The exceptions contained in the super-class can be renewed, and others may be added as long as they inherit from an ancestor class.
|
||||
|
||||
@ -1212,7 +1154,7 @@ declaration-of-a-non-redefinable-method ::=
|
||||
identifier formal-part-of-instance-method [returnedtype-
|
||||
declaration]
|
||||
[declaration-of-exceptions]
|
||||
** is virtual **[visibility]’;’
|
||||
** is virtual **[visibility]’;’
|
||||
|
||||
All methods are static by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method.
|
||||
|
||||
@ -1228,7 +1170,7 @@ The CDL language allows you to describe a class, which introduces methods witho
|
||||
|
||||
declaration-of-a-deferred-class ::=
|
||||
**deferred class **class-name
|
||||
[**inherits **class-name
|
||||
[**inherits **class-name
|
||||
[**uses **data-type {’,’ data-type}]
|
||||
[**raises **exception-name {’,’ exception-name}]
|
||||
**is **class-definition
|
||||
@ -1376,29 +1318,29 @@ inherits Persistent
|
||||
raises NoSuchObject
|
||||
is
|
||||
Create returns mutable SingleList;
|
||||
---Purpose: Creates an empty list
|
||||
---Purpose: Creates an empty list
|
||||
IsEmpty (me) returns Boolean;
|
||||
---Purpose: Returns true if the list me is empty
|
||||
---Purpose: Returns true if the list me is empty
|
||||
SwapTail (me : mutable; S : in out mutable
|
||||
SingleList)
|
||||
---Purpose: Exchanges the tail of list me with S
|
||||
---Purpose: Exchanges the tail of list me with S
|
||||
-- Exception NoSuchObject raised when me is
|
||||
empty
|
||||
raises NoSuchObject;
|
||||
Value (me) returns Item
|
||||
---Purpose: Returns first element of the list me
|
||||
Value (me) returns Item
|
||||
---Purpose: Returns first element of the list me
|
||||
-- Exception NoSuchObject raised when me is
|
||||
empty
|
||||
raises NoSuchObject;
|
||||
Tail (me) returns mutable SingleList
|
||||
Tail (me) returns mutable SingleList
|
||||
---Purpose: Returns the tail of the list me
|
||||
-- Exception NoSuchObject raised when me is
|
||||
empty
|
||||
raises NoSuchObject;
|
||||
fields
|
||||
fields
|
||||
Data : Item;
|
||||
Next : SingleList;
|
||||
end SingleList;
|
||||
Next : SingleList;
|
||||
end SingleList;
|
||||
|
||||
Even though no object of the type “SingleList” IS created, the class contains a constructor. This class constitutes a model, which will be recopied at instantiation time to create a new class which will generate objects. The constructor will then be required.
|
||||
**Example**
|
||||
@ -1423,7 +1365,7 @@ The syntax is as follows:
|
||||
|
||||
instantiation-of-a-generic-class ::=
|
||||
[**deferred**] **class **class-name
|
||||
** instantiates **class-name ’(’data-type {’,’
|
||||
** instantiates **class-name ’(’data-type {’,’
|
||||
data-type}’);’
|
||||
|
||||
Instantiation is said to be **static**. In other words, it must take place before any use can be made of the type of the instantiated class. Each data type is associated term by term with those declared at the definition of the generic class. These latter ones, when they are not of the type **any**, restrict instantiation to those classes, which have a behavior at least equal to that of the class specified in the type constraint, including constructors. Note that this is not guaranteed by inheritance itself.
|
||||
@ -1443,18 +1385,18 @@ It often happens that many classes are linked by a common generic type. This is
|
||||
**Example**
|
||||
|
||||
declaration-of-a-generic-class ::=
|
||||
[**deferred**] **generic class **class-name ’(’generic-
|
||||
[**deferred**] **generic class **class-name ’(’generic-
|
||||
type{’,’generic-type}’)’
|
||||
[**inherits **class-name {’,’ class-name}]
|
||||
[**uses **data-type {’,’ data-type}]
|
||||
[**raises **exception-name {’,’ exception-name}]
|
||||
[{[visibility] class-declaration}]
|
||||
** is **class-definition
|
||||
[**inherits **class-name {’,’ class-name}]
|
||||
[**uses **data-type {’,’ data-type}]
|
||||
[**raises **exception-name {’,’ exception-name}]
|
||||
[{[visibility] class-declaration}]
|
||||
** is **class-definition
|
||||
**end **[class-name]’;’
|
||||
class-declaration ::=
|
||||
incomplete-declaration-of-a-class |
|
||||
declaration-of-a-non-generic-class |
|
||||
instantiation-of-a-generic-class
|
||||
class-declaration ::=
|
||||
incomplete-declaration-of-a-class |
|
||||
declaration-of-a-non-generic-class |
|
||||
instantiation-of-a-generic-class
|
||||
|
||||
**Nested classes**, even though they are described as non-generic classes, are generic by construction, being inside the class of which they are a part. As a consequence, the generic types introduced by the **encompassing class **can be used in the definition of the nested class. This is true even if the generic type is only used in a nested class. The generic types still* must *appear as an argument of the encompassing class. All other types used by a nested class *must *appear in its **uses **or **raises **clauses, just as if it were an independent class.
|
||||
|
||||
@ -1467,34 +1409,34 @@ generic class Set (Item as Storable)
|
||||
inherits Persistent
|
||||
private class Node instantiates SingleList (Item);
|
||||
class Iterator
|
||||
uses Set, Node
|
||||
raises NoSuchObject, NoMoreObject
|
||||
is
|
||||
Create (S : Set) returns mutable Iterator;
|
||||
uses Set, Node
|
||||
raises NoSuchObject, NoMoreObject
|
||||
is
|
||||
Create (S : Set) returns mutable Iterator;
|
||||
---Purpose: Creates an iterator on the group S
|
||||
More (me) returns Boolean;
|
||||
More (me) returns Boolean;
|
||||
---Purpose: Returns true if there are still elements
|
||||
-- to explore
|
||||
Next (me) raises NoMoreObject;
|
||||
-- to explore
|
||||
Next (me) raises NoMoreObject;
|
||||
---Purpose: Passes to the following element
|
||||
Value (me) returns any Item raises NoSuchObject;
|
||||
Value (me) returns any Item raises NoSuchObject;
|
||||
---Purpose: Returns the current element
|
||||
fields
|
||||
Current : Node;
|
||||
fields
|
||||
Current : Node;
|
||||
end Iterator;
|
||||
is
|
||||
Create returns mutable Set;
|
||||
Create returns mutable Set;
|
||||
---Purpose: Creates an empty group
|
||||
IsEmpty (me) returns Boolean;
|
||||
IsEmpty (me) returns Boolean;
|
||||
---Purpose: Returns true if the group is empty
|
||||
Add (me : mutable; T : Item);
|
||||
Add (me : mutable; T : Item);
|
||||
---Purpose: Adds an item to the group me
|
||||
Remove (me : mutable; T : item) raises
|
||||
Remove (me : mutable; T : item) raises
|
||||
NoSuchObject;
|
||||
---Purpose: Removes an item from the group me
|
||||
etc.
|
||||
fields
|
||||
Head : Node;
|
||||
etc.
|
||||
fields
|
||||
Head : Node;
|
||||
end Set;
|
||||
|
||||
Note that in their fields, both “Set” and “Iterator” are clients of another class, “Node”. This last can be effectively declared **private **for it only appears in fields which are themselves private.
|
||||
@ -1543,19 +1485,19 @@ identifier {’,’ identifier} ’:’ data-type
|
||||
Example
|
||||
|
||||
fields
|
||||
Phi, Delta, Gamma : AngularMomenta [3]
|
||||
is protected ;
|
||||
Phi, Delta, Gamma : AngularMomenta [3]
|
||||
is protected ;
|
||||
|
||||
|
||||
@subsubsection occt_1819379591_1972310108463 Visibility of Methods
|
||||
|
||||
Methods act on fields. Only methods belonging to a class can act on the fields of the class; this stems from the principle of object encapsulation. Methods can be characterized in three ways: by default, methods are **public**. Methods can be declared **private **or **protected **to restrict their usage.
|
||||
|
||||
**Public methods **Are the default and are generally the most common. They describe the behavior of a class or a package, and they are callable by any part of a program.
|
||||
**Public methods **Are the default and are generally the most common. They describe the behavior of a class or a package, and they are callable by any part of a program.
|
||||
|
||||
**Private methods **Exist only for the internal structuring of their class or their package. Private class methods can only be called by methods belonging to the same class. Private package methods can only be called by all methods belonging to the same package and its classes.
|
||||
**Private methods **Exist only for the internal structuring of their class or their package. Private class methods can only be called by methods belonging to the same class. Private package methods can only be called by all methods belonging to the same package and its classes.
|
||||
|
||||
**Protected methods **Are private methods, which are also callable from the interior of descendent classes.
|
||||
**Protected methods **Are private methods, which are also callable from the interior of descendent classes.
|
||||
|
||||
If you want to restrict the usage of a method, you associate with it a visibility as follows :
|
||||
|
||||
@ -1588,15 +1530,15 @@ Friend classes or methods are declared inside the class, which reveals its priv
|
||||
|
||||
declaration-of-friends ::=
|
||||
**friends **friend {’,’friend}
|
||||
friend ::=
|
||||
identifier **from **[**class**] class-name [formal-part] |
|
||||
friend ::=
|
||||
identifier **from **[**class**] class-name [formal-part] |
|
||||
**Defining the Software Components 67**
|
||||
identifier **from **[**package**] package-name [formal-part] |
|
||||
** class**] class-name
|
||||
formal-part ::=
|
||||
simple-formal-part |
|
||||
formal-part-of-instance-method |
|
||||
formal-part-of-class-method
|
||||
** class**] class-name
|
||||
formal-part ::=
|
||||
simple-formal-part |
|
||||
formal-part-of-instance-method |
|
||||
formal-part-of-class-method
|
||||
|
||||
The formal part *must *be presented if the method contains one; thus this can be overloaded without necessarily propagating the friend relationship among its homonyms. The keyword **class **allows you to avoid certain ambiguities. For example, it removes any confusion between “method M from class C” and “method M from package P”.
|
||||
|
||||
@ -1606,23 +1548,11 @@ As an example, take a method, which calculates the perpendicular distance betwe
|
||||
friends Distance from Line (me; P : Point)
|
||||
|
||||
A method can be a friend to many classes. The class to which the method belongs does *not *need to appear in the **uses **clause of other classes of which it is a friend.
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table> When the methods of a class are all friends of another class, you can establish the friendship at the level of the class.
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image011.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image011.jpg
|
||||
|
||||
When the methods of a class are all friends of another class, you can establish the friendship at the level of the class.
|
||||
|
||||
Figure 9. Visibility of various components
|
||||
@section occt_1819379591_858765726 Appendix A. Syntax Summary
|
||||
@ -1754,7 +1684,7 @@ redefinition |** ****redefined**** **[redefinition]
|
||||
**raises**** **exception-name {’,’ exception-name}
|
||||
|
||||
(35) declaration-of-visibility ::=
|
||||
**is**** **visibility
|
||||
**is**** **visibility
|
||||
|
||||
(36) declaration-of-attributes-of-instance-method ::=
|
||||
**is**** **visibility | **is **definition-of-level
|
||||
@ -1844,7 +1774,7 @@ package-name]
|
||||
[**inherits**** **class-name
|
||||
[**uses**** **data-type {’,’ data-type}]
|
||||
[**raises**** **exception-name {’,’ exception-name}]
|
||||
** is **definition-of-a-class
|
||||
** is **definition-of-a-class
|
||||
**end **[class-name]’;’
|
||||
|
||||
(55) type-constraint ::=
|
||||
@ -1858,19 +1788,6 @@ identifier **as**** **type-constraint
|
||||
|
||||
@subsection occt_1819379591_213955286151 Comparison of CDL & C++ Syntax for Data Types manipulated by Handle and by Value
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@image html /dev_guides/cdl/images/cdl_image012.jpg
|
||||
@image latex /dev_guides/cdl/images/cdl_image012.jpg
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Developer Guides {#dev_guides}
|
||||
================
|
||||
|
||||
@section OCCT_OVW_SECTION1 Source Repository
|
||||
## Source Repository
|
||||
|
||||
This directory contains sources of Open CASCADE Technology (OCCT), a collection
|
||||
of C++ libraries providing services for 3D surface and solid modeling, CAD data
|
||||
@ -15,39 +15,7 @@ compliance with the License. Please see the LICENSE file or obtain a copy of the
|
||||
License at http://www.opencascade.org and read it completely before using this
|
||||
software.
|
||||
|
||||
@section OCCT_OVW_SECTION11 Building OCCT Libraries
|
||||
|
||||
The source package of the Open CASCADE Technology including the source files of samples
|
||||
and tools and the set of building procedures is available for self-dependent preparation
|
||||
binary files on UNIX and Windows platforms.
|
||||
|
||||
In order to build OCCT libraries from these sources for use in your program,
|
||||
you need to:
|
||||
|
||||
1. Install the required third-party libraries.
|
||||
|
||||
Follow the instructions provided in the documents titled "Building 3rd party
|
||||
products for OCCT" on http://dev.opencascade.org/?q=home/resources for
|
||||
choice of the needed libraries, their installation and building.
|
||||
|
||||
2. If you use OCCT sources from Git repository or do come changes affecting
|
||||
CDL files or dependencies of OCCT toolkit, update header files generated
|
||||
from CDL, and regenerate build scripts for your environment using WOK.
|
||||
See \subpage dev_guides__wok "WOK" for details.
|
||||
|
||||
Skip to step 3 if you use complete source package (e.g. official OCCT
|
||||
release) without changes in CDL.
|
||||
|
||||
3. Build using your preferred build tool.
|
||||
- \subpage dev_guides__building__automake "Building on Linux with Autotools"
|
||||
- \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
|
||||
- \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
|
||||
- \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
|
||||
- \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
|
||||
|
||||
The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
|
||||
|
||||
@section OCCT_OVW_SECTION111 Automatic tests
|
||||
## Automatic tests
|
||||
|
||||
OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness",
|
||||
a console application based on Tcl (a scripting language).
|
||||
@ -88,15 +56,24 @@ To see intermediate commands and their output during the test execution,
|
||||
add one more argument '-echo' at the end of the command line, or type 'dlog get'
|
||||
after test completion.
|
||||
|
||||
For more information consult \subpage dev_guides__tests "Automatic Testing System"
|
||||
For more information consult \subpage dev_guides__tests
|
||||
|
||||
@section OCCT_OVW_SECTION1112 CDL Overview
|
||||
## docs
|
||||
**short description**
|
||||
|
||||
CDL is the component definition language of the Open CASCADE Technology (OCCT) programming platform.
|
||||
Some components, which CDL allows you to create, are specific to OCCT application architecture.
|
||||
\subpage dev_guides__documentation
|
||||
|
||||
For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide"
|
||||
## wok
|
||||
**short description**
|
||||
|
||||
@section OCCT_OVW_SECTION1113 Documentation Overview
|
||||
\subpage dev_guides__wok
|
||||
|
||||
\subpage dev_guides__documentation "Documentation Developer's Guide"
|
||||
## building
|
||||
**short description**
|
||||
|
||||
\subpage dev_guides__building
|
||||
|
||||
## cdl
|
||||
**short description**
|
||||
|
||||
\subpage dev_guides__cdl
|
||||
@ -20,6 +20,9 @@ The latest version: http://www.mathjax.org/download/
|
||||
<b>MiKTeX</b> or equivalent tool (used for PDF document creation)
|
||||
Latest version: http://miktex.org/download
|
||||
|
||||
**Note**: to generate pdf documentation with MiKTeX you should execute gen.bat with MiKTeX environment
|
||||
(e.g. into MiKTeX command promt)
|
||||
|
||||
@section OCCT_DM_SECTION_2_1 Documentation Generation
|
||||
|
||||
Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
|
||||
@ -80,7 +83,8 @@ The MarkDown files have a "*.md" extension and are based on rules desribed in
|
||||
|
||||
@subsection OCCT_DM_SECTION_3_2 Directory Structure
|
||||
|
||||
|
||||
@image html /dev_guides/documentation/images/documentation_image001.png
|
||||
@image latex /dev_guides/documentation/images/documentation_image001.png
|
||||
|
||||
Every separate article has own folder if images are used in it. These images
|
||||
are stored into "images" subfolder.
|
||||
@ -90,7 +94,7 @@ If you want to use the same image for several articles, you can place the one in
|
||||
**Note**: Every article can use any image that is used by others articles. To avoid incorrect image
|
||||
displaying, use relative path to the image (starting from dox folder). For instance
|
||||
@verbatim
|
||||
|
||||
@image html /dev_guides/snv/images/snv_image001.svg
|
||||
@endverbatim
|
||||
|
||||
Result of generation of the documentation is:
|
||||
@ -103,14 +107,14 @@ Result of generation of the documentation is:
|
||||
|
||||
- Place a new article into folder that is chosen taking into account the place of the article
|
||||
at the hierarchy of the documentation. For instance the article about "using SVN working with OCCT
|
||||
source code" (svn.md - the file of the article) might be placed into /dox/devs_guide/ . If the article has images then you may create
|
||||
source code" (svn.md - the file of the article) might be placed into /dox/dev_guides/ . If the article has images then you may create
|
||||
the own folder of the article and subfolder in it for images. For instance
|
||||
*/dox/devs_guide/svn/ - for svn.md file
|
||||
*/dox/devs_guide/svn/images/ - for images
|
||||
*/dox/dev_guides/svn/ - for svn.md file
|
||||
*/dox/dev_guides/svn/images/ - for images
|
||||
|
||||
- Update dox/FILES.txt to add relative path to svn.md. For instance
|
||||
@verbatim
|
||||
devs_guide/snv/svn.md
|
||||
dev_guides/snv/svn.md
|
||||
@endverbatim
|
||||
|
||||
**Note**: the place of the relative path to an article is connected with the place
|
||||
@ -129,403 +133,3 @@ http://en.wikipedia.org/wiki/Help:Displaying_a_formula
|
||||
|
||||
More information on MarkDown and Doxygen syntax can be found at:
|
||||
http://www.stack.nl/~dimitri/doxygen/manual
|
||||
|
||||
|
||||
@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
|
||||
|
||||
Each OCCT document file in *.md format has a simple structure.
|
||||
It can contain:
|
||||
|
||||
| Content type | Obligation |
|
||||
| :---------------- | :-------------------: |
|
||||
| Header | M |
|
||||
| Footer | M |
|
||||
| Plain text | O |
|
||||
| List | O |
|
||||
| Table | O |
|
||||
| Code | O |
|
||||
| Formula | O |
|
||||
| Image | O |
|
||||
| Page numbers | M (auto generation) |
|
||||
| Table of contents | M (auto generation) |
|
||||
|
||||
The legend:
|
||||
|
||||
* M is for Mandatory
|
||||
* O is for Optional
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_1 Text Caption (a header)
|
||||
|
||||
headings of different levels can be specified with the following code:
|
||||
|
||||
@verbatim
|
||||
Header 1 {#header1}
|
||||
=======
|
||||
@endverbatim
|
||||
|
||||
to get
|
||||
|
||||
Header 1
|
||||
=========
|
||||
|
||||
and with the following code:
|
||||
|
||||
@verbatim
|
||||
Header 2 {#header2}
|
||||
--------
|
||||
@endverbatim
|
||||
|
||||
to get
|
||||
|
||||
Header 2
|
||||
---------
|
||||
|
||||
Where a word in curly braces is a MarkDown-style reference, which can be used in table of contents.
|
||||
If you would like to have the table of contents, it is recommended to use \@section,
|
||||
\@subsection and \@subsubsection pages instead of MarkDown headers as follows:
|
||||
|
||||
@verbatim
|
||||
@section Section_Name Section Header
|
||||
@subsection SubSection_Name SubSection Header
|
||||
@subsubsection SubSubSection_Name SubSubSection Header
|
||||
@endverbatim
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_2 Plain Text
|
||||
|
||||
Plain text is a text in a notepad-like format. To insert special symbols,
|
||||
like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\
|
||||
To emphasize some words, write one pair of asterisks ( * ) or underscores ( _ ) across the word
|
||||
to make it *italic* and two pairs of these symbols to make a word **Bold**.
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_3 Lists
|
||||
|
||||
To create a bulleted list, start each line with a hyphen or an asterisk,
|
||||
followed by a space. List items can be nested. This code:
|
||||
|
||||
@verbatim
|
||||
* Bullet 1
|
||||
* Bullet 2
|
||||
* Bullet 2a
|
||||
* Bullet 2b
|
||||
* Bullet 3
|
||||
@endverbatim
|
||||
|
||||
produces this list:
|
||||
|
||||
* Bullet 1
|
||||
* Bullet 2
|
||||
* Bullet 2a
|
||||
* Bullet 2b
|
||||
* Bullet 3
|
||||
|
||||
To create a numbered list, start each line with number and a period, then a space. Thus this code
|
||||
|
||||
@verbatim
|
||||
1. ListItem_1
|
||||
2. ListItem_2
|
||||
3. ListItem_3
|
||||
@endverbatim
|
||||
|
||||
produces this list:
|
||||
|
||||
1. ListItem_1
|
||||
2. ListItem_2
|
||||
3. ListItem_3
|
||||
|
||||
It is recommended to indent lists with 2 spaces.
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_4 Tables
|
||||
|
||||
A table consists of a header line, a separator line, and at least one row line.
|
||||
Table columns are separated by the pipe (|) character. The following example:
|
||||
|
||||
@verbatim
|
||||
First Header | Second Header
|
||||
------------- | -------------
|
||||
Content Cell | Content Cell
|
||||
Content Cell | Content Cell
|
||||
@endverbatim
|
||||
|
||||
will produce the following table:
|
||||
|
||||
First Header | Second Header
|
||||
------------ | -------------
|
||||
Content Cell | Content Cell
|
||||
Content Cell | Content Cell
|
||||
|
||||
Column alignment can be controlled via one or two colons at the header separator line:
|
||||
|
||||
@verbatim
|
||||
| Right | Center | Left |
|
||||
| ----: | :----: | :---- |
|
||||
| 10 | 10 | 10 |
|
||||
| 1000 | 1000 | 1000 |
|
||||
@endverbatim
|
||||
|
||||
which will looks as follows:
|
||||
|
||||
| Right | Center | Left |
|
||||
| ----: | :----: | :---- |
|
||||
| 10 | 10 | 10 |
|
||||
| 1000 | 1000 | 1000 |
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_5 Code Blocks
|
||||
|
||||
It is recommended to indent a code lines with 4 spaces.
|
||||
A fenced code block does not require indentation, and is defined by a pair of "fence lines".
|
||||
Such line consists of 3 or more tilde (~) characters on a line.
|
||||
The end of the block should have the same number of tildes. Here is an example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
a one-line code block
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default the output is the same as for a normal code block.
|
||||
To highlight the code, the developer has to indicate the typical file extension,
|
||||
which corresponds to the programming language, after the opening fence.
|
||||
For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
|
||||
|
||||
@verbatim
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
int func(int a,int b) { return a*b; }
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@endverbatim
|
||||
|
||||
which will produce:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
int func(int a,int b) { return a*b; }
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Verbatim content can be written by using framing \@verbatim \@endverbatim . For instance
|
||||
|
||||
@verbatim
|
||||
verbatim text
|
||||
@endverbatim
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_6 References
|
||||
|
||||
To insert a reference to a website, it is proposed to write a URL. For example: http://en.wikipedia.org
|
||||
To insert a reference to another part of the same document, the developer can write:
|
||||
|
||||
@verbatim
|
||||
@htmlonly
|
||||
<a href="#OCCT_DOC_SECTION_5">Doxygen Configuration file</a>
|
||||
@endhtmlonly
|
||||
@endverbatim
|
||||
|
||||
to get a link to paragraph : @htmlonly <a href="#OCCT_DOC_SECTION_5">Doxygen configuration</a> @endhtmlonly
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_7 Images
|
||||
|
||||
To insert image into document the developer can write the following code(in Doxygen-style):
|
||||
@verbatim
|
||||
|
||||
@endverbatim
|
||||
|
||||
This code tells Doxygen to insert a picture right in the place this code was written. Like this:
|
||||
@verbatim
|
||||
|
||||
@endverbatim
|
||||
|
||||
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_8 Table Of Contents
|
||||
|
||||
To get the table of contents at the beginning of the document, write \@tableofcontents tag.
|
||||
But it is not needed now because TreeView option for HTML is used.
|
||||
The TOC in the PDF document will be generated automatically.
|
||||
|
||||
@subsection OCCT_DM_SECTION_A_9 Formulas
|
||||
|
||||
Formulas within documents will be generated using MathJax tool.
|
||||
|
||||
A developer has to specify these parameters in Doxyfile to enable support of MathJax in Doxygen:
|
||||
|
||||
USE_MATHJAX = YES
|
||||
MATHJAX_FORMAT = HTML-CSS
|
||||
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
|
||||
MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
|
||||
|
||||
To use MathJax tool with the HTML page, it's \<head\> block has to contain
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.html}
|
||||
<script type="text/x-mathjax-config">
|
||||
MathJax.Hub.Config({
|
||||
tex2jax: {inlineMath: [["$","$"],["\\(","\\)"]]},
|
||||
displayAlign: "left"
|
||||
});
|
||||
</script>
|
||||
|
||||
<script type="text/javascript"
|
||||
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
|
||||
</script>
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
First script configures MathJax to understand separator types and to left allign formulas.
|
||||
The second script inserts reference to MathJax tool.
|
||||
This tool will always be used when the HTML output will be shown.
|
||||
|
||||
Equations can be written by several ways:
|
||||
|
||||
1.Unnumbered displayed formulas that are centered on a separate line.
|
||||
These formulas should be put between \@f\[ and \@f\] tags. An example:
|
||||
|
||||
@verbatim
|
||||
@f$[
|
||||
|I_2|=\left| \int_{0}^T \psi(t)
|
||||
\left\{
|
||||
u(a,t)-
|
||||
\int_{\gamma(t)}^a
|
||||
\frac{d\theta}{k(\theta,t)}
|
||||
\int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
|
||||
\right\} dt
|
||||
\right|
|
||||
@f$]
|
||||
@endverbatim
|
||||
|
||||
gives the following result:
|
||||
|
||||
@f$
|
||||
|I_2|=\left| \int_{0}^T \psi(t)
|
||||
\left\{
|
||||
u(a,t)-
|
||||
\int_{\gamma(t)}^a
|
||||
\frac{d\theta}{k(\theta,t)}
|
||||
\int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
|
||||
\right\} dt
|
||||
\right|
|
||||
@f$
|
||||
|
||||
2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags. An example:
|
||||
|
||||
@verbatim
|
||||
\begin{align}
|
||||
\dot{x} & = \sigma(y-x) \\
|
||||
\dot{y} & = \rho x - y - xz \\
|
||||
\dot{z} & = -\beta z + xy
|
||||
\end{align}
|
||||
@endverbatim
|
||||
|
||||
gives the following result:
|
||||
@latexonly
|
||||
\begin{align}
|
||||
\dot{x} & = \sigma(y-x) \\
|
||||
\dot{y} & = \rho x - y - xz \\
|
||||
\dot{z} & = -\beta z + xy
|
||||
\end{align}
|
||||
@endlatexonly
|
||||
|
||||
@htmlonly
|
||||
\begin{align}
|
||||
\dot{x} & = \sigma(y-x) \\
|
||||
\dot{y} & = \rho x - y - xz \\
|
||||
\dot{z} & = -\beta z + xy
|
||||
\end{align}
|
||||
@endhtmlonly
|
||||
|
||||
3.Inline formulas can be specified using this syntax:
|
||||
|
||||
@verbatim
|
||||
@f$ \sqrt{3x-1}+(1+x)^2 @f$
|
||||
@endverbatim
|
||||
|
||||
that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
|
||||
|
||||
@section OCCT_DM_SECTION_B Appendix 2: Doxygen Configuration
|
||||
|
||||
@subsection OCCT_DM_SECTION_B_1 Doxygen Configuration File
|
||||
|
||||
To generate documentation from "source" *.md files a developer can use file OCCT.doxyfile,
|
||||
which is located in /docs directory of OCCT (more information can be found at @htmlonly
|
||||
<a href="#OCCT_DM_SECTION_X_X_X">Directory Structure</a> @endhtmlonly paragraph)
|
||||
or create his own configuration file, called "Doxyfile". The configuration file may look as follows:
|
||||
|
||||
@verbatim
|
||||
DOXYFILE_ENCODING = UTF-8
|
||||
PROJECT_NAME = "OCCT User's Guides"
|
||||
PROJECT_NUMBER = 1.0.1
|
||||
PROJECT_LOGO = "D:/OS/OCCT/docs/OCCT_logo.png"
|
||||
OUTPUT_LANGUAGE = English
|
||||
TAB_SIZE = 4
|
||||
MARKDOWN_SUPPORT = YES
|
||||
AUTOLINK_SUPPORT = NO
|
||||
SHOW_FILES = NO
|
||||
WARNINGS = YES
|
||||
WARN_IF_UNDOCUMENTED = YES
|
||||
WARN_IF_DOC_ERROR = YES
|
||||
WARN_NO_PARAMDOC = NO
|
||||
WARN_FORMAT = "$file:$line: $text"
|
||||
INPUT = "D:/OS/OCCT/docs/"
|
||||
INPUT_ENCODING = UTF-8
|
||||
FILE_PATTERNS = *.md
|
||||
RECURSIVE = YES
|
||||
IMAGE_PATH = tmp
|
||||
GENERATE_HTML = YES
|
||||
SEARCHENGINE = NO
|
||||
HTML_OUTPUT = html
|
||||
HTML_FILE_EXTENSION = .html
|
||||
HTML_HEADER = "static/header.html"
|
||||
HTML_FOOTER = "static/footer.html"
|
||||
HTML_STYLESHEET = "static/general.css"
|
||||
HTML_EXTRA_STYLESHEET = "static/styles.css"
|
||||
HTML_COLORSTYLE_HUE = 220
|
||||
HTML_COLORSTYLE_SAT = 100
|
||||
HTML_COLORSTYLE_GAMMA = 80
|
||||
HTML_TIMESTAMP = YES
|
||||
HTML_DYNAMIC_SECTIONS = NO
|
||||
HTML_INDEX_NUM_ENTRIES = 100
|
||||
GENERATE_LATEX = YES
|
||||
GENERATE_RTF = YES
|
||||
@endverbatim
|
||||
|
||||
@subsection OCCT_DM_SECTION_B_2 Doxygen Output Customization
|
||||
|
||||
The customization of the output files, produced by Doxygen, can be made by using different Doxyfile parameters,
|
||||
like HTML_COLORSTYLE_SAT, which specifies one of HSV color component of HTML page header, and also by using DoxygenLayout xml file.
|
||||
A developer can use default file from /docs directory or generate his own with doxygen -l command. It may looks as follows:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.xml}
|
||||
<doxygenlayout version="1.0">
|
||||
<!-- Generated by doxygen 1.8.3.1 -->
|
||||
<!-- Navigation index tabs for HTML output -->
|
||||
<navindex>
|
||||
<tab type="mainpage" visible="yes" title="Introduction"/>
|
||||
<tab type="pages" visible="yes" title="Documents" intro=
|
||||
"This section contains links to all OCCT documents that are available at the moment"/>
|
||||
<tab type="modules" visible="no" title="" intro=""/>
|
||||
<tab type="namespaces" visible="no" title="">
|
||||
<tab type="namespacelist" visible="no" title="" intro=""/>
|
||||
<tab type="namespacemembers" visible="no" title="" intro=""/>
|
||||
</tab>
|
||||
<tab type="classes" visible="no" title="">
|
||||
<tab type="classlist" visible="no" title="" intro=""/>
|
||||
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
|
||||
<tab type="hierarchy" visible="no" title="" intro=""/>
|
||||
<tab type="classmembers" visible="no" title="" intro=""/>
|
||||
</tab>
|
||||
<tab type="files" visible="yes" title="Files">
|
||||
<tab type="filelist" visible="yes" title="" intro=""/>
|
||||
<tab type="globals" visible="yes" title="" intro=""/>
|
||||
</tab>
|
||||
<tab type="examples" visible="no" title="" intro=""/>
|
||||
</navindex>
|
||||
...
|
||||
</doxygenlayout>
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tag \<tab\> specifies tabs which appear at the head of each html page. For the OCCT user documentation
|
||||
"mainpage" and "pages" tabs are usually needed and their visible parameter should always be "yes".
|
||||
The visibility of other tabs should be set to "no".
|
||||
|
||||
Developers can find more information about Doxygen configuration in the help file
|
||||
or at http://www.stack.nl/~dimitri/doxygen/manual/
|
||||
|
||||
@subsection OCCT_DM_SECTION_B_3 Doxywizard Usage
|
||||
|
||||
The easiest way of applying and modification of Doxyfile is to use a Doxywizard application,
|
||||
which is usually a part of the Doxygen tool. To apply a configuration file, the developer should
|
||||
select "Open..." item of the File menu or press Ctrl + O. Modification of Doxyfile can be made
|
||||
using "Wizard" or "Expert" tabs of Doxywizard application.
|
||||
|
||||
Developers can find more information about Doxywizard usage in the help file or at
|
||||
http://www.stack.nl/~dimitri/doxygen/manual/doxywizard_usage.html.
|
||||
|
||||
@ -173,7 +173,8 @@ By convention, names of test groups, grids, and cases should contain no spaces a
|
||||
Names begin, end, data, parse.rules, grids.list, cases.list are reserved.
|
||||
General layout of test scripts is shown on Figure 1.
|
||||
|
||||
|
||||
@image html /dev_guides/tests/images/tests_image001.png
|
||||
@image latex /dev_guides/tests/images/tests_image001.png
|
||||
|
||||
Figure 1. Layout of tests folder
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 3.5 KiB |
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 7.9 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 7.0 KiB After Width: | Height: | Size: 7.0 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 1.2 KiB After Width: | Height: | Size: 1.2 KiB |
|
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 1.5 KiB |
|
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 1.5 KiB |
|
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 1.5 KiB |
|
Before Width: | Height: | Size: 1.4 KiB After Width: | Height: | Size: 1.4 KiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 107 KiB |
File diff suppressed because it is too large
Load Diff
@ -340,8 +340,8 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
|
||||
puts $texfile "\\fancyhead\[RO\]{\\fancyplain{}{\\bfseries\\thepage}}"
|
||||
puts $texfile "\\fancyfoot\[LE\]{\\fancyplain{}{}}"
|
||||
puts $texfile "\\fancyfoot\[CE\]{\\fancyplain{}{}}"
|
||||
puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
|
||||
puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
|
||||
puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
|
||||
puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
|
||||
puts $texfile "\\fancyfoot\[CO\]{\\fancyplain{}{}}"
|
||||
puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}"
|
||||
puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}"
|
||||
@ -378,6 +378,7 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
|
||||
puts $texfile "}"
|
||||
puts $texfile "\n"
|
||||
puts $texfile "%===== C O N T E N T S =====\n"
|
||||
# puts $texfile "\\DeclareUnicodeCharacter{00A0}{ }"
|
||||
puts $texfile "\\begin{document}"
|
||||
puts $texfile ""
|
||||
puts $texfile "% Titlepage & ToC"
|
||||
@ -386,7 +387,7 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
|
||||
puts $texfile "\\begin{titlepage}"
|
||||
puts $texfile "\\vspace*{7cm}"
|
||||
puts $texfile "\\begin{center}%"
|
||||
puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{occttransparent.png}\\\\\\\\"
|
||||
puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{overview_occttransparent.png}\\\\\\\\"
|
||||
puts $texfile "{\\Large Open C\\-A\\-S\\-C\\-A\\-D\\-E Technology \\\\\[1ex\]\\Large 6.\\-6.\\-0 }\\\\"
|
||||
puts $texfile "\\vspace*{1cm}"
|
||||
puts $texfile "{\\Large $docLabel}\\\\"
|
||||
@ -423,8 +424,15 @@ proc OverviewDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
|
||||
if {$verboseMode == "YES"} {
|
||||
puts "INFO: Preprocessing file $TEX"
|
||||
}
|
||||
|
||||
if {![file exists $TEX]} {
|
||||
puts "file $TEX doesn't exist"
|
||||
return
|
||||
}
|
||||
|
||||
set IN_F [open "$TEX" r]
|
||||
set TMPFILENAME "$latexDir/temp.tex"
|
||||
|
||||
set OUT_F [open $TMPFILENAME w]
|
||||
|
||||
while {1} {
|
||||
@ -521,13 +529,13 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
|
||||
}
|
||||
|
||||
# Prepare a list of TeX files, generated by Doxygen
|
||||
puts "go to $LATEXDIR"
|
||||
cd $LATEXDIR
|
||||
|
||||
set TEXFILES [glob $LATEXDIR -type f -directory $LATEXDIR -tails "*.tex" ]
|
||||
set REFMAN_IDX [lsearch $TEXFILES "refman.tex"]
|
||||
set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
|
||||
set REFMAN_IDX [lsearch $TEXFILES "index.tex"]
|
||||
set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
|
||||
|
||||
|
||||
set IDX [lsearch $TEXFILES "$LATEXDIR"]
|
||||
while { $IDX != -1} {
|
||||
@ -535,10 +543,10 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
|
||||
set IDX [lsearch $TEXFILES "$LATEXDIR"]
|
||||
}
|
||||
|
||||
# Preprocess generated TeX files
|
||||
puts "Preprocess generated TeX files"
|
||||
OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode
|
||||
|
||||
# Generate PDF files from
|
||||
puts "Generate PDF files from"
|
||||
foreach TEX $TEXFILES {
|
||||
# Rewrite existing REFMAN.tex file...
|
||||
set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]]
|
||||
@ -548,6 +556,7 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
|
||||
puts "INFO: Generating PDF file from $TEX"
|
||||
}
|
||||
# ...and use it to generate PDF from TeX...
|
||||
puts "execute $LATEXDIR/make$PREFIX"
|
||||
set RESULT [catch {eval exec [auto_execok $LATEXDIR/make$PREFIX] > "$OUTDIR/pdflatex_out.log"} LaTeX_ERROR]
|
||||
if {$RESULT != 0} {
|
||||
if {[llength [split $LaTeX_ERROR "\n"]] > 1} {
|
||||
@ -563,6 +572,12 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
|
||||
if { [file exists $PDFDIR/$TEX.pdf] == 1 } {
|
||||
file delete -force $PDFDIR/$TEX.pdf
|
||||
}
|
||||
|
||||
if {![file exists "$LATEXDIR/refman.pdf"]} {
|
||||
puts "file $LATEXDIR/refman.pdf doesn't exist"
|
||||
return
|
||||
}
|
||||
|
||||
file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf"
|
||||
}
|
||||
if {$verboseMode == "YES"} {
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 7.5 KiB After Width: | Height: | Size: 6.5 KiB |
@ -16,7 +16,8 @@ From a programming standpoint, Open CASCADE Technology is designed to enhance yo
|
||||
|
||||
To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image001.png
|
||||
@image latex /overview/tutorial/images/tutorial_image001.png
|
||||
|
||||
In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
|
||||
|
||||
@ -32,7 +33,8 @@ We first define the bottle specifications as follows:
|
||||
|
||||
In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image002.png
|
||||
@image latex /overview/tutorial/images/tutorial_image002.png
|
||||
|
||||
This modeling requires four steps:
|
||||
|
||||
@ -48,7 +50,8 @@ This modeling requires four steps:
|
||||
|
||||
To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image003.png
|
||||
@image latex /overview/tutorial/images/tutorial_image003.png
|
||||
|
||||
There are two classes to describe a 3D Cartesian point from its X, Y and Z coordinates in Open CASCADE Technology:
|
||||
|
||||
@ -81,7 +84,8 @@ Standard_Real xValue1 = aPnt1.X();
|
||||
@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
|
||||
With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image004.png
|
||||
@image latex /overview/tutorial/images/tutorial_image004.png
|
||||
|
||||
To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
|
||||
In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
|
||||
@ -137,7 +141,8 @@ Referring to the previous table, to build the profile, you will create:
|
||||
* Three edges out of the previously computed curves.
|
||||
* One wire with these edges.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image005.png
|
||||
@image latex /overview/tutorial/images/tutorial_image005.png
|
||||
|
||||
However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
|
||||
To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
|
||||
@ -175,7 +180,8 @@ Once the first part of your wire is created you need to compute the complete pro
|
||||
* compute a new wire by reflecting the existing one.
|
||||
* add the reflected wire to the initial one.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image006.png
|
||||
@image latex /overview/tutorial/images/tutorial_image006.png
|
||||
|
||||
To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
|
||||
In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
|
||||
@ -258,7 +264,8 @@ To compute the main body of the bottle, you need to create a solid shape. The si
|
||||
| Face | Solid |
|
||||
| Shell | Compound of Solids |
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image007.png
|
||||
@image latex /overview/tutorial/images/tutorial_image007.png
|
||||
|
||||
Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
|
||||
To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
|
||||
@ -295,7 +302,8 @@ For our purposes, we will specify that fillets must be:
|
||||
* applied on all edges of the shape
|
||||
* have a radius of *myThickness* / 12
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image008.png
|
||||
@image latex /overview/tutorial/images/tutorial_image008.png
|
||||
|
||||
To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
|
||||
|
||||
@ -351,7 +359,8 @@ Once this is done, you perform the last step of the procedure by asking for the
|
||||
|
||||
To add a neck to the bottle, you will create a cylinder and fuse it to the body. The cylinder is to be positioned on the top face of the body with a radius of *myThickness* / 4. and a height of *myHeight* / 10.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image009.png
|
||||
@image latex /overview/tutorial/images/tutorial_image009.png
|
||||
|
||||
To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
|
||||
To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
|
||||
@ -393,7 +402,8 @@ In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is
|
||||
* Create a parallel wall W2 from W1 at a distance D. If D is positive, W2 will be outside the initial solid, otherwise it will be inside.
|
||||
* Compute a solid from the two walls W1 and W2.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image010.png
|
||||
@image latex /overview/tutorial/images/tutorial_image010.png
|
||||
|
||||
To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
|
||||
|
||||
@ -496,7 +506,8 @@ As a first step, you compute these cylindrical surfaces. You are already familia
|
||||
|
||||
Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image011.png
|
||||
@image latex /overview/tutorial/images/tutorial_image011.png
|
||||
|
||||
Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
|
||||
|
||||
@ -521,7 +532,8 @@ P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where :
|
||||
* R is the radius of the cylindrical surface.
|
||||
* U range is [0, 2PI] and V is infinite.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image012.png
|
||||
@image latex /overview/tutorial/images/tutorial_image012.png
|
||||
|
||||
The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
|
||||
|
||||
@ -530,7 +542,8 @@ The advantage of having such parameterized geometries is that you can compute, f
|
||||
|
||||
There is another advantage of these parametric equations: you can consider a surface as a 2D parametric space defined with a (U, V) coordinate system. For example, consider the parametric ranges of the neck's surface:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image013.png
|
||||
@image latex /overview/tutorial/images/tutorial_image013.png
|
||||
|
||||
Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
|
||||
|
||||
@ -545,14 +558,16 @@ The helicoidal curve type is exactly what you need. On the neck's surface, the e
|
||||
* In V parameter: between 0 and myHeighNeck for the height description
|
||||
* In U parameter: between 0 and 2PI for the angle description. But, since a cylindrical surface is U periodic, you can decide to extend this angle evolution to 4PI as shown in the following drawing:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image014.png
|
||||
@image latex /overview/tutorial/images/tutorial_image014.png
|
||||
|
||||
In this (U, V) parametric space, you will create a local (X, Y) coordinate system to position the curves to be created. This coordinate system will be defined with:
|
||||
|
||||
* A center located in the middle of the neck's cylinder parametric space at (2*PI, myNeckHeight / 2) in U, V coordinates.
|
||||
* A X direction defined with the (2*PI, myNeckHeight/4) vector in U, V coordinates, so that the curves occupy half of the neck's surfaces.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image015.png
|
||||
@image latex /overview/tutorial/images/tutorial_image015.png
|
||||
|
||||
To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
|
||||
|
||||
@ -568,7 +583,8 @@ To use 2D primitive geometry types of Open CASCADE Technology for defining a poi
|
||||
|
||||
You will now define the curves. As previously mentioned, these thread profiles are computed on two cylindrical surfaces. In the following figure, curves on the left define the base (on *aCyl1* surface) and the curves on the right define the top of the thread's shape (on *aCyl2* surface).
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image016.png
|
||||
@image latex /overview/tutorial/images/tutorial_image016.png
|
||||
|
||||
You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
|
||||
|
||||
@ -624,7 +640,8 @@ As you did when creating the base profile of the bottle, you can now:
|
||||
* compute the edges of the neck's threading.
|
||||
* compute two wires out of these edges.
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image017.png
|
||||
@image latex /overview/tutorial/images/tutorial_image017.png
|
||||
|
||||
Previously, you have built:
|
||||
|
||||
@ -664,7 +681,8 @@ You have computed the wires of the threading. The threading will be a solid shap
|
||||
There are always faster ways to build a solid when the base topology is defined. You would like to create a solid out of two wires. Open CASCADE Technology provides a quick way to do this by building a loft: a shell or a solid passing through a set of wires in a given sequence.
|
||||
The loft function is implemented in the *BRepOffsetAPI_ThruSections* class, which you use as follows:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image018.png
|
||||
@image latex /overview/tutorial/images/tutorial_image018.png
|
||||
|
||||
* Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
|
||||
* Add the successive wires using the AddWire method.
|
||||
@ -694,7 +712,8 @@ You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Bui
|
||||
|
||||
Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
|
||||
|
||||
|
||||
@image html /overview/tutorial/images/tutorial_image019.png
|
||||
@image latex /overview/tutorial/images/tutorial_image019.png
|
||||
|
||||
We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
|
||||
If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.org/support. Our professional services can maximize the power of your Open CASCADE Technology applications.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -3,7 +3,7 @@ Modeling Data {#user_guides__modeling_data}
|
||||
|
||||
@section occt_modat_1 Introduction
|
||||
|
||||
Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
|
||||
|
||||
|
||||
@ -28,15 +28,16 @@ The class *PEquation* from *GProp* package allows analyzng a collection or clou
|
||||
|
||||
Packages *Geom2dAPI* and *GeomAPI* provide simple methods for approximation and interpolation with minimal programming
|
||||
|
||||
2D Interpolation
|
||||
----------------
|
||||
#### 2D Interpolation
|
||||
|
||||
The class *Interpolate* from *Geom2dAPI* package allows building a constrained 2D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
|
||||
|
||||
3D Interpolation
|
||||
----------------
|
||||
#### 3D Interpolation
|
||||
|
||||
The class *Interpolate* from *GeomAPI* package allows building a constrained 3D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image003.jpg "Approximation of a BSpline from scattered points"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image003.jpg "Approximation of a BSpline from scattered points"
|
||||
|
||||
This class may be instantiated as follows:
|
||||
~~~~~
|
||||
@ -48,12 +49,12 @@ From this object, the BSpline curve may be requested as follows:
|
||||
Handle(Geom_BSplineCurve) C = Interp.Curve();
|
||||
~~~~~
|
||||
|
||||
2D Approximation
|
||||
----------------
|
||||
#### 2D Approximation
|
||||
|
||||
The class *PointsToBSpline* from *Geom2dAPI* package allows building a 2DBSpline curve, which approximates a set of points. You have to define the lowest and highest degree of the curve, its continuity and a tolerance value for it.The tolerance value is used to check that points are not too close to each other, or tangential vectors not too small. The resulting BSpline curve will beC2 or second degree continuous, except where a tangency constraint is defined on a point through which the curve passes. In this case, it will be only C1continuous.
|
||||
|
||||
3D Approximation
|
||||
---------------
|
||||
#### 3D Approximation
|
||||
|
||||
The class *PointsToBSpline* from GeomAPI package allows building a 3D BSplinecurve, which approximates a set of points. It is necessary to define the lowest and highest degree of the curve, its continuity and tolerance. The tolerance value is used to check that points are not too close to each other,or that tangential vectors are not too small.
|
||||
|
||||
The resulting BSpline curve will be C2 or second degree continuous, except where a tangency constraint is defined on a point, through which the curve passes. In this case, it will be only C1 continuous. This class is instantiated as follows:
|
||||
@ -68,23 +69,24 @@ From this object, the BSpline curve may be requested as follows:
|
||||
Handle(Geom_BSplineCurve) K = Approx.Curve();
|
||||
~~~~~
|
||||
|
||||
Surface Approximation
|
||||
---------------------
|
||||
#### Surface Approximation
|
||||
|
||||
The class **PointsToBSplineSurface** from GeomAPI package allows building a BSpline surface, which approximates or interpolates a set of points.
|
||||
|
||||
@subsubsection occt_modat_1_1_3 Advanced Approximation
|
||||
|
||||
Packages *AppDef* and *AppParCurves* provide low-level functions, allowing more control over the approximations.
|
||||
|
||||
Approximation by multiple point constraints
|
||||
-------------------------------------------
|
||||
#### Approximation by multiple point constraints
|
||||
|
||||
*AppDef* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curves using multiple point constraints.
|
||||
|
||||
The following low level services are provided:
|
||||
* Definition of an array of point constraints:
|
||||
The class *MultiLine* allows defining a given number of multipoint constraints in order to build the multi-line, multiple lines passing through ordered multiple point constraints.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image004.jpg "Definition of a MultiLine using Multiple Point Constraints"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image004.jpg "Definition of a MultiLine using Multiple Point Constraints"
|
||||
|
||||
In this image:
|
||||
* *Pi*, *Qi*, *Ri* ... *Si* can be 2D or 3Dpoints.
|
||||
@ -103,8 +105,8 @@ The class **BSplineCompute** allows making an approximation of a set of points t
|
||||
* Definition of Variational Criteria:
|
||||
The class *TheVariational* allows fairing the approximation curve to a given number of points using a least squares method in conjunction with a variational criterion, usually the weights at each constraint point.
|
||||
|
||||
Approximation by parametric or geometric constraints
|
||||
----------------------------------------------------
|
||||
#### Approximation by parametric or geometric constraints
|
||||
|
||||
|
||||
*AppParCurves* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curve with parametric or geometric constraints, such as a requirement for the curve to pass through given points, or to have a given tangency or curvature at a particular point.
|
||||
|
||||
@ -178,7 +180,6 @@ Each class from *gp* package, such as *Circ, Circ2d, Mirror, Mirror2d*, etc., ha
|
||||
|
||||
It is possible to create a point using a *gce* package class, then question it to recover the corresponding *gp* object.
|
||||
|
||||
**Example **
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
gp_Pnt2d Point1,Point2;
|
||||
...
|
||||
@ -188,9 +189,8 @@ It is possible to create a point using a *gce* package class, then question it t
|
||||
gp_Lin2d l = L.Value();
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This is useful if you are uncertain as to whether the arguments can create the *gp* object without raising an exception. In the case above, if *Point1* and *Point2* are closer than the tolerance value required by *MakeLin2d*, the function *Status* will return the enumeration *gce_ConfusedPoint*. This tells you why the *gp* object cannot be created. If you know that the points *Point1* and *Point2*are separated by the value exceeding the tolerance value, then you may create the *gp* object directly, as follows:
|
||||
|
||||
**Example **
|
||||
This is useful if you are uncertain as to whether the arguments can create the *gp* object without raising an exception. In the case above, if *Point1* and *Point2* are closer than the tolerance value required by *MakeLin2d*, the function *Status* will return the enumeration *gce_ConfusedPoint*. This tells you why the *gp* object cannot be created. If you know that the points *Point1* and *Point2* are separated by the value exceeding the tolerance value, then you may create the *gp* object directly, as follows:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
gp_Lin2d l = gce_MakeLin2d(Point1,Point2);
|
||||
@ -254,18 +254,18 @@ The following characteristic points exist on parameterized curves in 3d space:
|
||||
- *UniformAbscissa* calculates a set of points at a given abscissa on a curve.
|
||||
- *UniformDeflection* calculates a set of points at maximum constant deflection between the curve and the polygon that results from the computed points.
|
||||
|
||||
Example: Visualizing a curve.
|
||||
-----------------------------
|
||||
### Example: Visualizing a curve.
|
||||
|
||||
|
||||
Let us take an adapted curve **C**, i.e. an object which is an interface between the services provided by either a 2D curve from the package Geom2d (in case of an Adaptor_Curve2d curve) or a 3D curve from the package Geom (in case of an Adaptor_Curve curve), and the services required on the curve by the computation algorithm. The adapted curve is created in the following way:
|
||||
|
||||
**case 2D:**
|
||||
**2D case :**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
Handle(Geom2d_Curve) mycurve = ... ;
|
||||
Geom2dAdaptor_Curve C (mycurve) ;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**case 3D:**
|
||||
**3D case :**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
Handle(Geom_Curve) mycurve = ... ;
|
||||
GeomAdaptor_Curve C (mycurve) ;
|
||||
@ -281,7 +281,7 @@ The algorithm is then constructed with this object:
|
||||
{
|
||||
Standard_Integer nbr = myAlgo.NbPoints() ;
|
||||
Standard_Real param ;
|
||||
for ( Standard_Integer i = 1 ; i = nbr ; i++ )
|
||||
for ( Standard_Integer i = 1 ; i = nbr ; i++ )
|
||||
{
|
||||
param = myAlgo.Parameter (i) ;
|
||||
...
|
||||
@ -383,10 +383,10 @@ A surface (for two parameters U and V) has the following local properties:
|
||||
- Gaussian curvature
|
||||
|
||||
The following methods are available:
|
||||
* *CLProps* - calculates the local properties of a curve (tangency, curvature,normal);
|
||||
* *CurAndInf2d* - calculates the maximum and minimum curvatures and the inflection points of 2d curves;
|
||||
* *SLProps* - calculates the local properties of a surface (tangency, the normal and curvature).
|
||||
* *Continuity* - calculates regularity at the junction of two curves.
|
||||
* *CLProps* - calculates the local properties of a curve (tangency, curvature,normal);
|
||||
* *CurAndInf2d* - calculates the maximum and minimum curvatures and the inflection points of 2d curves;
|
||||
* *SLProps* - calculates the local properties of a surface (tangency, the normal and curvature).
|
||||
* *Continuity* - calculates regularity at the junction of two curves.
|
||||
|
||||
Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen.
|
||||
|
||||
@ -413,7 +413,8 @@ A local coordinate system can be viewed as either of the following:
|
||||
- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation.
|
||||
- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image005.jpg "Structure of TopLoc_Location"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image005.jpg "Structure of TopLoc_Location"
|
||||
|
||||
Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates.
|
||||
|
||||
@ -459,7 +460,8 @@ TopAbs contains the *TopAbs_ShapeEnum* enumeration,which lists the different top
|
||||
A topological model can be considered as a graph of objects with adjacency relationships. When modeling a part in 2D or 3D space it must belong to one of the categories listed in the ShapeEnum enumeration. The TopAbspackage lists all the objects, which can be found in any model. It cannot be extended but a subset can be used. For example, the notion of solid is useless in 2D.
|
||||
|
||||
The terms of the enumeration appear in order from the most complex to the most simple, because objects can contain simpler objects in their description. For example, a face references its wires, edges, and vertices.
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image006.jpg "ShapeEnum"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image006.jpg "ShapeEnum"
|
||||
|
||||
@subsubsection occt_modat_5_2_2 Orientation
|
||||
|
||||
@ -478,21 +480,23 @@ For a space limited by a face the default region is found on the negative side o
|
||||
|
||||
Based on this default region the orientation allows definition of the region to be kept, which is called the *interior* or *material*. There are four orientations defining the interior.
|
||||
|
||||
|FORWARD | The interior is the default region.|
|
||||
|REVERSED | The interior is the region complementary to the default.|
|
||||
|INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid.|
|
||||
|EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model.|
|
||||
| FORWARD | The interior is the default region. |
|
||||
| REVERSED | The interior is the region complementary to the default. |
|
||||
| INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid. |
|
||||
| EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model. |
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image007.jpg "Four Orientations"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image007.jpg "Four Orientations"
|
||||
|
||||
The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions - exterior and interior - with the intersection vertex as the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
|
||||
|
||||
|FORWARD | Entering |
|
||||
|REVERSED | Exiting |
|
||||
|INTERNAL | Touching from inside |
|
||||
|EXTERNAL | Touching from outside |
|
||||
| FORWARD | Entering |
|
||||
| REVERSED | Exiting |
|
||||
| INTERNAL | Touching from inside |
|
||||
| EXTERNAL | Touching from outside |
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image008.jpg "Four orientations of intersection vertices"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image008.jpg "Four orientations of intersection vertices"
|
||||
|
||||
|
||||
Along with the Orientation enumeration the *TopAbs* package defines four methods:
|
||||
@ -500,17 +504,21 @@ Along with the Orientation enumeration the *TopAbs* package defines four methods
|
||||
@subsubsection occt_modat_5_2_3 State
|
||||
|
||||
The **TopAbs_State** enumeration described the position of a vertex or a set of vertices with respect to a region. There are four terms:
|
||||
|IN | The point is interior. |
|
||||
|OUT | The point is exterior. |
|
||||
|ON | The point is on the boundary(within tolerance). |
|
||||
|UNKNOWN | The state of the point is indeterminate. |
|
||||
|
||||
|IN | The point is interior. |
|
||||
|OUT | The point is exterior. |
|
||||
|ON | The point is on the boundary(within tolerance). |
|
||||
|UNKNOWN | The state of the point is indeterminate. |
|
||||
|
||||
The UNKNOWN term has been introduced because this enumeration is often used to express the result of a calculation, which can fail. This term can be used when it is impossible to know if a point is inside or outside, which is the case with an open wire or face.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image009.jpg "The four states"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image009.jpg "The four states"
|
||||
|
||||
The State enumeration can also be used to specify various parts of an object. The following figure shows the parts of an edge intersecting a face.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image010.jpg "State specifies the parts of an edge intersecting a face"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image010.jpg "State specifies the parts of an edge intersecting a face"
|
||||
|
||||
@subsection occt_modat_5_3 Manipulating shapes and sub-shapes
|
||||
|
||||
@ -534,11 +542,13 @@ The **TopoDS_Shape** class describes a reference to a shape. It contains a refer
|
||||
|
||||
The class representing the underlying abstract shape is never referenced directly. The *TopoDS_Shape* class is always used to refer to it.
|
||||
|
||||
The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**.The following figures show the example of a shell formed from two faces connected by an edge.
|
||||
The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**. The following figures show the example of a shell formed from two faces connected by an edge.
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image011.jpg "Structure of a shell formed from two faces"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image011.jpg "Structure of a shell formed from two faces"
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image012.jpg "Data structure of the above shell"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image012.jpg "Data structure of the above shell"
|
||||
|
||||
In the previous diagram, the shell is described by the underlying shape TS, and the faces by TF1 and TF2. There are seven edges from TE1 to TE7 and six vertices from TV1 to TV6.
|
||||
|
||||
@ -555,7 +565,8 @@ The compact data structure avoids the loss of information associated with copy o
|
||||
The following figure shows a data structure containing two versions of a solid. The second version presents a series of identical holes bored at different positions. The data structure is compact and yet keeps all information on the sub-elements.
|
||||
|
||||
The three references from *TSh2* to the underlying face *TFcyl* have associated local coordinate systems, which correspond to the successive positions of the hole.
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image013.jpg "Data structure containing two versions of a solid"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image013.jpg "Data structure containing two versions of a solid"
|
||||
|
||||
Classes inheriting TopoDS_Shape
|
||||
------------------------------
|
||||
@ -578,7 +589,6 @@ There are no constructors for the classes inheriting from the *TopoDS_Shape* cla
|
||||
The following example shows a routine receiving an argument of the *TopoDS_Shape* type, then putting it into a variable V if it is a vertex or calling the method ProcessEdge if it is an edge.
|
||||
|
||||
|
||||
**Example**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
#include TopoDS_Vertex.hxx
|
||||
#include TopoDS_Edge.hxx
|
||||
@ -621,7 +631,7 @@ The TopExp package provides the class *TopExp_Explorer* to find all sub-objects
|
||||
|
||||
The Explorer visits the whole structure in order to find the shapes of the requested type not contained in the type to avoid. The example below shows how to find all faces in the shape *S*:
|
||||
|
||||
**Example**
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
void test() {
|
||||
TopoDS_Shape S;
|
||||
@ -632,19 +642,16 @@ The Explorer visits the whole structure in order to find the shapes of the reque
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To find all the vertices which are not in an edge:
|
||||
Find all the vertices which are not in an edge
|
||||
|
||||
**Example **
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
for (Ex.Init(S,TopAbs_VERTEX,TopAbs_EDGE); ...)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
To find all the faces in a SHELL, then all the faces not in a SHELL:
|
||||
Find all the faces in a SHELL, then all the faces not in a SHELL:
|
||||
|
||||
|
||||
**Example **
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
void test() {
|
||||
TopExp_Explorer Ex1, Ex2;
|
||||
@ -665,7 +672,7 @@ To find all the faces in a SHELL, then all the faces not in a SHELL:
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Explorer presumes that objects contain only objects of an equal or inferior type. For example, if searching for faces it does not lookat wires, edges, or vertices to see if they contain faces.
|
||||
The Explorer presumes that objects contain only objects of an equal or inferior type. For example, if searching for faces it does not look at wires, edges, or vertices to see if they contain faces.
|
||||
|
||||
The *MapShapes* method from *TopExp* package allows filling a Map. An exploration using the Explorer class can visit an object more than once if it is referenced more than once. For example, an edge of a solid is generally referenced by two faces. To process objects only once, they have to be placed in a Map.
|
||||
|
||||
@ -686,10 +693,10 @@ The *MapShapes* method from *TopExp* package allows filling a Map. An exploratio
|
||||
In the following example all faces and all edges of an object are drawn in accordance with the following rules:
|
||||
- The faces are represented by a network of *NbIso* iso-parametric lines with *FaceIsoColor* color.
|
||||
- The edges are drawn in a color, which indicates the number of faces sharing the edge:
|
||||
1. FreeEdgeColor for edges, which do not belong to a face (i.e. wireframe element).
|
||||
2. BorderEdgeColor for an edge belonging to a single face.
|
||||
3. SharedEdgeColor for an edge belonging to more than one face.
|
||||
- The methods **DrawEdge** and **DrawFaceIso** are also available to display individual edges and faces.
|
||||
- *FreeEdgeColor* for edges, which do not belong to a face (i.e. wireframe element).
|
||||
- *BorderEdgeColor* for an edge belonging to a single face.
|
||||
- *SharedEdgeColor* for an edge belonging to more than one face.
|
||||
- The methods *DrawEdge* and *DrawFaceIso* are also available to display individual edges and faces.
|
||||
|
||||
The following steps are performed:
|
||||
1. Storing the edges in a map and create in parallel an array of integers to count the number of faces sharing the edge. This array is initialized to zero.
|
||||
@ -697,8 +704,6 @@ The following steps are performed:
|
||||
3. Exploring the edges and for each of them increment the counter of faces in the array.
|
||||
4. From the Map of edges, drawing each edge with the color corresponding to the number of faces.
|
||||
|
||||
|
||||
**Example **
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
void DrawShape ( const TopoDS_Shape& aShape,
|
||||
const Standard_Integer nbIsos,
|
||||
@ -754,10 +759,10 @@ The following steps are performed:
|
||||
| *TopTools_MapOfShape* | Instantiation of the *TCollection_Map*. Allows the construction of sets of shapes. |
|
||||
| *TopTools_IndexedMapOfShape* | Instantiation of the *TCollection_IndexedMap*. Allows the construction of tables of shapes and other data structures. |
|
||||
|
||||
With a **TopTools_Map**, a set of references to Shapes can be kept without duplication.
|
||||
The following example program counts the size of a data structure as a number of TShapes.
|
||||
With a *TopTools_Map*, a set of references to Shapes can be kept without duplication.
|
||||
The following example counts the size of a data structure as a number of *TShapes*.
|
||||
|
||||
|
||||
**Example **
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
#include TopoDS_Iterator.hxx
|
||||
Standard_Integer Size(const TopoDS_Shape& aShape)
|
||||
@ -774,11 +779,10 @@ The following example program counts the size of a data structure as a number of
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This program is incorrect if there is sharing in the data structure.
|
||||
Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices
|
||||
with the result 9, but as the vertices are each shared by two edges this program will return 13.
|
||||
One solution is to put all the Shapes in a Map so as to avoid counting them twice, as in the following example:
|
||||
|
||||
**Example **
|
||||
Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices with the result 9, but as the vertices are each shared by two edges this program will return 13. One solution is to put all the Shapes in a Map so as to avoid counting them twice, as in the following example:
|
||||
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
#include TopoDS_Iterator.hxx
|
||||
#includeTopTools_MapOfShape.hxx
|
||||
@ -805,15 +809,13 @@ One solution is to put all the Shapes in a Map so as to avoid counting them twic
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**Note** For more details about Maps see the TCollection documentation.(Foundation Classes Reference Manual)
|
||||
**Note** For more details about Maps please, refer to the TCollection documentation. (Foundation Classes Reference Manual)
|
||||
|
||||
The following example is more ambitious and writes a program which copies a data structure using an IndexedMap. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows:
|
||||
- All Shapes in the structure are put into an IndexedMap.
|
||||
The following example is more ambitious and writes a program which copies a data structure using an *IndexedMap*. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows:
|
||||
- All Shapes in the structure are put into an *IndexedMap*.
|
||||
- A table of Shapes is created in parallel with the map to receive the copies.
|
||||
- The structure is copied using the auxiliary recursive function,which copies from the map to the array.
|
||||
|
||||
**Example **
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
#include TopoDS_Shape.hxx
|
||||
#include TopoDS_Iterator.hxx
|
||||
@ -847,11 +849,11 @@ The following example is more ambitious and writes a program which copies a data
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
In the above example, the index *i* is that of the first object not treated in the Map. When *i* reaches the same size as the Map this means that everything has been treated. The treatment consists of inserting in the Map all the sub-objects, if they are not yet in the Map, they are inserted with an index greater than *i*.
|
||||
In the above example, the index *i* is that of the first object not treated in the Map. When *i* reaches the same size as the Map this means that everything has been treated. The treatment consists in inserting in the Map all the sub-objects, if they are not yet in the Map, they are inserted with an index greater than *i*.
|
||||
|
||||
**Note** that the objects are inserted with a local reference set to the identity and a FORWARD orientation. Only the underlying TShape is of great interest.
|
||||
|
||||
**Example **
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
//Create an array to store the copies.
|
||||
TopTools_Array1OfShapetheCopies(1,theMap.Extent());
|
||||
@ -873,7 +875,7 @@ In the above example, the index *i* is that of the first object not treated in t
|
||||
|
||||
Below is the auxiliary function, which copies the element of rank *i* from the map to the table. This method checks if the object has been copied; if not copied, then an empty copy is performed into the table and the copies of all the sub-elements are inserted by finding their rank in the map.
|
||||
|
||||
**Example **
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
void AuxiliaryCopy(Standard_Integer index,
|
||||
const TopTools_IndexedMapOfShapes&sources,
|
||||
@ -904,12 +906,11 @@ BRepTools_WireExplorer class can access edges of a wire in their order of connec
|
||||
|
||||
For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} :
|
||||
|
||||
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image014.jpg "A wire composed of 6 edges."
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image014.jpg "A wire composed of 6 edges.
|
||||
|
||||
TopExp_Explorer, however, recuperates the lines in any order.
|
||||
*TopExp_Explorer*, however, recuperates the lines in any order.
|
||||
|
||||
**Example **
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
TopoDS_Wire W = ...;
|
||||
BRepTools_WireExplorer Ex;
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,10 +1,11 @@
|
||||
TObj Package {#user_guides__tobj}
|
||||
==================
|
||||
|
||||
@section occt_1746122829_591811643 Introduction
|
||||
@section occt_tobj_1 Introduction
|
||||
|
||||
This document describes the package TObj, which is an add-on
|
||||
to the Open CASCADE Application Framework (OCAF).
|
||||
|
||||
This package provides a set of classes and auxiliary tools facilitating
|
||||
the creation of object-oriented data models on top of low-level OCAF data structures.
|
||||
This includes:
|
||||
@ -17,42 +18,36 @@ This includes:
|
||||
This document describes basic principles of logical and physical organization
|
||||
of TObj-based data models and typical approaches to implementation of classes representing model objects.
|
||||
|
||||
@subsection occt_1746122829_5918116431 Applicability
|
||||
@subsection occt_tobj_1_1 Applicability
|
||||
|
||||
The main purpose of the *TObj* data model is rapid development
|
||||
of the object-oriented data models for applications, using the existing
|
||||
functionality provided by OCAF (Undo/Redo and persistence)
|
||||
without the necessity to re-develop such functionality from scratch.
|
||||
|
||||
As opposed to using bare OCAF (at the level of labels and attributes),
|
||||
TObj facilitates dealing with higher level abstracts, which are closer
|
||||
to the application domain. It works best when the application data are naturally
|
||||
organized in hierarchical structures, and is especially useful for complex data
|
||||
models with dependencies between objects belonging to different parts of the model.
|
||||
|
||||
It should be noted that *TObj* is efficient for representing data structures containing
|
||||
a limited number of objects at each level of the data structure (typically less than 1000).
|
||||
A greater number of objects causes performance problems due to list-based organization of OCAF documents.
|
||||
Therefore, other methods of storage, such as arrays, are advisable for data models or their
|
||||
sub-parts containing a great number of uniform objects. However, these methods
|
||||
A greater number of objects causes performance problems due to list-based organization of OCAF documents. Therefore, other methods of storage, such as arrays, are advisable for data models or their sub-parts containing a great number of uniform objects. However, these methods
|
||||
can be combined with the usage of *TObj* to represent the high-level structure of the model.
|
||||
|
||||
@section occt_1746122829_361293797 *TObj* Model
|
||||
@section occt_tobj_2 *TObj* Model
|
||||
|
||||
@subsection occt_1746122829_3612937971 *TObj* Model structure
|
||||
@subsection occt_tobj_2_1 *TObj* Model structure
|
||||
|
||||
In the *TObj* data model the data are separated from the interfaces that manage them.
|
||||
It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects,
|
||||
while the actual contents and structure of the model of a particular application
|
||||
are defined by its specific classes inherited from *TObj* classes. The
|
||||
implementation can add its own features or even change the default behaviour
|
||||
and the data layout, though this is not recommended. Logically the *TObj* data model is represented as a tree of model
|
||||
objects, with upper-level objects typically being collections of other objects
|
||||
(called *partitions*, represented by the class *TObj_Partition*). The root object of the model
|
||||
is called the *Main partition* and is maintained by the model itself. This partition contains a list
|
||||
of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
|
||||
|
||||
|
||||
It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects, while the actual contents and structure of the model of a particular application are defined by its specific classes inherited from *TObj* classes. The implementation can add its own features or even change the default behaviour and the data layout, though this is not recommended.
|
||||
|
||||
Picture 1 *TObj* Data Model
|
||||
Logically the *TObj* data model is represented as a tree of model objects, with upper-level objects typically being collections of other objects (called *partitions*, represented by the class *TObj_Partition*). The root object of the model is called the *Main partition* and is maintained by the model itself. This partition contains a list of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
|
||||
@image latex /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
|
||||
|
||||
As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology,
|
||||
it stores its data in the underlying OCAF document. The OCAF document consists of a tree of
|
||||
@ -65,11 +60,11 @@ of the label, which uniquely identifies its position in the document.
|
||||
Generally the structure of the OCAF tree of the *TObj* data
|
||||
model corresponds to the logical structure of the model and can be presented as in the following picture:
|
||||
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image004.jpgb "TObj Data Model mapped on OCAF document"
|
||||
@image latex /user_guides/tobj/images/tobj_image004.jpg "TObj Data Model mapped on OCAF document"
|
||||
|
||||
Picture 2 *TObj* Data Model mapped on OCAF document
|
||||
All data of the model are stored in the root label (0:1) of the OCAF document.
|
||||
An attribute TObj_TModel is located in this root label. It
|
||||
An attribute *TObj_TModel* is located in this root label. It
|
||||
stores the object of type *TObj_Model*. This object serves as a main interface tool
|
||||
to access all data and functionalities of the data model.
|
||||
|
||||
@ -83,7 +78,7 @@ where the objects of the child models can refer to the objects of the parent
|
||||
models, not vice-versa. Provided that the correct order of loading and closing
|
||||
of the models is ensured, the *TObj* classes will maintain references between the objects automatically.
|
||||
|
||||
@subsection occt_1746122829_3612937972 Data Model basic features
|
||||
@subsection occt_tobj_2_2 Data Model basic features
|
||||
|
||||
The class *TObj_Model* describing the data model provides the following functionalities:
|
||||
|
||||
@ -97,7 +92,7 @@ The class *TObj_Model* describing the data model provides the following function
|
||||
* Interface to check and update the model if necessary (method *Update*)
|
||||
* Support of several data models in one application. For this feature use OCAF multi-transaction manager, unique names and GUIDs of the data model (methods *GetModelName*, *GetGUID*)
|
||||
|
||||
@subsection occt_1746122829_3612937973 Model Persistence
|
||||
@subsection occt_tobj_2_3 Model Persistence
|
||||
|
||||
The persistent representation of any OCAF model is contained in an XML or a binary file,
|
||||
which is defined by the format string returned by the method *GetFormat*.
|
||||
@ -105,18 +100,18 @@ The default implementation works with a binary OCAF document format (*BinOcaf*).
|
||||
The other available format is *XmlOcaf*. The class **TObj_Model** declares and provides a default
|
||||
implementation of two virtual methods:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
virtual Standard_Boolean Load (const char* theFile);
|
||||
virtual Standard_Boolean SaveAs (const char* theFile);
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
which retrieve and store the model from or
|
||||
in the OCAF file. The descendants
|
||||
should define the following protected method to support Load and Save operations:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
virtual Standard_Boolean initNewModel (const Standard_Boolean IsNew);
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
This method is called by *Load* after creation of a new model
|
||||
or after its loading from the file; its purpose is to perform
|
||||
@ -139,6 +134,7 @@ Such fields can be stored into OCAF attributes for saving into persistent storag
|
||||
|
||||
To avoid memory leaks, the *TObj_Model* class destructor invokes *Close* method
|
||||
which clears the OCAF document and removes all data from memory before the model is destroyed.
|
||||
|
||||
For XML and binary persistence of the *TObj* data model the corresponding drivers are implemented
|
||||
in *BinLDrivers*, *BinMObj* and *XmlLDrivers*, *XmlMObj* packages.
|
||||
These packages contain retrieval and storage drivers for the model, model objects and custom attributes
|
||||
@ -148,39 +144,39 @@ in some cases it can be reasonable to add specific OCAF attributes to
|
||||
facilitate the storage of the data specific to the application.
|
||||
In this case the schema should be extended using the standard OCAF mechanism.
|
||||
|
||||
@subsection occt_1746122829_3612937974 Access to the objects in the model
|
||||
@subsection occt_tobj_2_4 Access to the objects in the model
|
||||
|
||||
All objects in the model are stored in the main partition and accessed by iterators.
|
||||
To access all model objects use:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
virtual Handle(TObj_ObjectIterator) GetObjects () const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
This method returns a recursive iterator on all objects stored in the model.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
virtual Handle(TObj_ObjectIterator) GetChildren () const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
This method returns an iterator on child objects of the main partition.
|
||||
Use the following method to get the main partition:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
Handle(TObj_Partition) GetMainPartition() const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
To receive the iterator on objects of a specific type *AType* use the following call:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
GetMainPartition()->GetChildren(STANDARD_TYPE(AType) );
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
The set of protected methods is provided for descendant classes to deal with partitions:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean theHidden) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~{.cpp}
|
||||
virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean theHidden) const;
|
||||
~~~~~
|
||||
|
||||
This method returns (creating if necessary) a partition in the specified label of the document.
|
||||
The partition can be created as hidden (*TObj_HiddenPartition* class).
|
||||
@ -191,19 +187,19 @@ The following two methods allow getting (creating) a partition
|
||||
in the sub-label of the specified label in the document
|
||||
(the label of the main partition for the second method) and with the given name:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
|
||||
virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~{.cpp}
|
||||
virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
|
||||
virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
|
||||
~~~~~
|
||||
|
||||
If the default object naming and the name register mechanism
|
||||
is turned on, the object can be found in the model by its unique name:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
Handle(TObj_Object) FindObject (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
@subsection occt_1746122829_3612937975 Own model data
|
||||
@subsection occt_tobj_2_5 Own model data
|
||||
|
||||
The model object can store its own data in the Data label
|
||||
of its main partition, however, there is no standard API for
|
||||
@ -212,7 +208,7 @@ their own data using standard OCAF methods. The enumeration DataTag is defined
|
||||
in *TObj_Model* to avoid conflict of data labels used by this class
|
||||
and its descendants, similarly to objects (see below).
|
||||
|
||||
@subsection occt_1746122829_3612937976 Object naming
|
||||
@subsection occt_tobj_2_6 Object naming
|
||||
|
||||
The basic implementation of *TObj_Model* provides the default
|
||||
naming mechanism: all objects must have unique names,
|
||||
@ -226,31 +222,31 @@ To ignore name registering it is necessary to redefine the methods *SetName*,
|
||||
*AfterRetrieval* of the *TObj_Object* class and skip the registration of the object name.
|
||||
Use the following methods for the naming mechanism:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
Standard_Boolean IsRegisteredName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
Returns **True** if the object name is already registered in the indicated (or model) dictionary.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
void RegisterName (const Handle(TCollection_HExtendedString)& theName, const TDF_Label& theLabel, const Handle(TObj_TNameContainer)& theDictionary ) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
Registers the object name with the indicated label where the object
|
||||
is located in the OCAF document. Note that the default implementation
|
||||
of the method *SetName* of the object registers the new name automatically
|
||||
(if the name is not yet registered for any other object)
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
void UnRegisterName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~
|
||||
|
||||
Unregisters the name from the dictionary. Ther names of *TObj* model
|
||||
objects are removed from the dictionary when the objects are deleted from the model.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
~~~~~{.cpp}
|
||||
Handle(TObj_TNameContainer) GetDictionary() const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~
|
||||
|
||||
Returns a default instance of the model dictionary (located at the model root label).
|
||||
The default implementation works only with one dictionary.
|
||||
@ -258,7 +254,7 @@ If there are a necessity to have more than one dictionary for the model objects,
|
||||
it is recommended to redefine the corresponding virtual method of TObj_Object
|
||||
that returns the dictionary where names of objects should be registered.
|
||||
|
||||
@subsection occt_1746122829_3612937977 API for transaction mechanism
|
||||
@subsection occt_tobj_2_7 API for transaction mechanism
|
||||
|
||||
Class *TObj_Model* provides the API for transaction mechanism (supported by OCAF):
|
||||
|
||||
@ -299,7 +295,7 @@ Returns True if the model document has a modified status (has changes after the
|
||||
Changes the modified status by force. For synchronization of transactions
|
||||
within several *TObj_Model* documents use class *TDocStd_MultiTransactionManager*.
|
||||
|
||||
@subsection occt_1746122829_3612937978 Model format and version
|
||||
@subsection occt_tobj_28 Model format and version
|
||||
|
||||
Class *TObj_Model* provides the descendant classes with a means to control
|
||||
the format of the persistent file by choosing the schema used to store or retrieve operations.
|
||||
@ -355,7 +351,7 @@ for the changes of data stored in the model, not for the changes of
|
||||
low-level format of data files (such as the storage format of a specific OCAF attribute).
|
||||
If the format of data files changes, a specific treatment on a case-by-case basis will be required.
|
||||
|
||||
@subsection occt_1746122829_3612937979 Model update
|
||||
@subsection occt_tobj_2_9 Model update
|
||||
|
||||
The following methods are used for model update to ensure its consistency
|
||||
with respect to the other models in case of cross-model dependencies:
|
||||
@ -381,7 +377,7 @@ This method is called from the previous method to update back references
|
||||
of the indicated object after the retrieval of the model from file
|
||||
(see data model - object relationship chapter for more details)
|
||||
|
||||
@subsection occt_1746122829_36129379710 Model copying
|
||||
@subsection occt_tobj_2_10 Model copying
|
||||
|
||||
To copy the model between OCAF documents use the following methods:
|
||||
|
||||
@ -405,7 +401,7 @@ Redefines a pure virtual method to create a new empty instance of the model.
|
||||
|
||||
Copies the references from the current model to the target model.
|
||||
|
||||
@subsection occt_1746122829_36129379711 Messaging
|
||||
@subsection occt_tobj_2_11 Messaging
|
||||
|
||||
The messaging is organised using Open CASCADE Messenger from the package Message.
|
||||
The messenger is stored as the field of the model instance
|
||||
@ -425,38 +421,40 @@ All message keys are stored in a special resource file TObj.msg.
|
||||
This file should be loaded at the start of the application
|
||||
by call to the appropriate method of the class *Message_MsgFile*.
|
||||
|
||||
@section occt_1746122829_87267338 Model object
|
||||
@section occt_tobj_3 Model object
|
||||
|
||||
Class *TObj_Object* provides basic interface and default implementation
|
||||
of important features of *TObj* model objects. This implementation defines
|
||||
basic approaches that are recommended for all descendants,
|
||||
and provides tools to facilitate their usage.
|
||||
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
|
||||
@image latex /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
|
||||
|
||||
Picture 3 *TObj* objects hierarchy
|
||||
|
||||
@subsection occt_1746122829_872673381 Separation of data and interface
|
||||
@subsection occt_tobj_3_1 Separation of data and interface
|
||||
|
||||
In the *TObj* data model, the data are separated from the interfaces that manage them.
|
||||
The data belonging to a model object are stored in its root label and sub-labels
|
||||
in the form of standard OCAF attributes. This allows using standard OCAF mechanisms
|
||||
for work with these data, and eases the implementation of the persistence mechanism.
|
||||
|
||||
The instance of the interface which serves as an API for managing object data
|
||||
(e.g. represents the model object) is stored in the root label of the object,
|
||||
and typically does not bring its own data. The interface classes are organized in a hierarchy
|
||||
corresponding to the natural hierarchy of the model objects according to the application.
|
||||
|
||||
In the text below the term 'object' is used to denote either the instance
|
||||
of the interface class or the object itself (both interface and data stored in OCAF).
|
||||
|
||||
The special type of attribute *TObj_TObject* is used for storing instances of objects interfaces
|
||||
in the OCAF tree. *TObj_TObject* is a simple container for the object of type *TObj_Object*.
|
||||
All objects (interfaces) of the data model inherit this class.
|
||||
All objects (interfaces) of the data model inherit this class.
|
||||
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image006.png "*TObj* object stored on OCAF label"
|
||||
@image latex /user_guides/tobj/images/tobj_image006.png "*TObj* object stored on OCAF label"
|
||||
|
||||
Picture 4 *TObj* object stored on OCAF label
|
||||
|
||||
@subsection occt_1746122829_872673382 Basic features
|
||||
@subsection occt_tobj_3_2 Basic features
|
||||
|
||||
The *TObj_Object* class provides some basic features that can be inherited (or, if necessary, redefined) by the descendants:
|
||||
|
||||
@ -464,12 +462,12 @@ The *TObj_Object* class provides some basic features that can be inherited (or,
|
||||
* Supports references (and back references) to other objects in the same or in another model (methods *getReference*, *setReference*, *addReference*, *GetReferences*, *GetBackReferences*, *AddBackReference*, *RemoveBackReference*, *ReplaceReference*)
|
||||
* Provides the ability to contain child objects, as it is actual for partition objects (methods *GetChildren*, *GetFatherObject*)
|
||||
* Organizes its data in the OCAF structure by separating the sub-labels of the main label intended for various kinds of data and providing tools to organize these data (see <a href="../../../../Documents%20and%20Settings/TEMP/obj-inher">below</a>). The kinds of data stored separately are:
|
||||
* Child objects stored in the label returned by the method *GetChildLabel*
|
||||
* References to other objects stored in the label returned by the method* GetReferenceLabel*
|
||||
* Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel*
|
||||
* Child objects stored in the label returned by the method *GetChildLabel*
|
||||
* References to other objects stored in the label returned by the method* GetReferenceLabel*
|
||||
* Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel*
|
||||
* Provides unique names of all objects in the model (methods *GetDictionary*, *GetName*, *SetName*)
|
||||
* Provides unified means to maintain persistence (implemented in descendants with the help of macros *DECLARE_TOBJOCAF_PERSISTENCE* and *IMPLEMENT_TOBJOCAF_PERSISTENCE*)
|
||||
* Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the back references (method *Detach*)
|
||||
* Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the back references (method *Detach*)
|
||||
* Implements methods for identification and versioning of objects
|
||||
* Manages the object interaction with OCAF Undo/Redo mechanism (method *IsAlive*, *AfterRetrieval*, *BeforeStoring*)
|
||||
* Allows make a clone (methods *Clone*, *CopyReferences*, *CopyChildren*, *copyData*)
|
||||
@ -483,7 +481,7 @@ An object can be received from the model by the following methods:
|
||||
static Standard_Boolean GetObj ( const TDF_Label& theLabel, Handle(TObj_Object)& theResObject, const Standard_Boolean isSuper = Standard_False );
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Returns **True** if the object has been found in the indicated label (or in the upper level label if isSuper is **True)**.
|
||||
Returns *True* if the object has been found in the indicated label (or in the upper level label if *isSuper* is *True*).
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
Handle(TObj_Object) GetFatherObject ( const Handle(Standard_Type)& theType = NULL ) const;
|
||||
@ -492,13 +490,14 @@ Returns **True** if the object has been found in the indicated label (or in the
|
||||
Returns the father object of the indicated type
|
||||
for the current object (the direct father object if the type is NULL).
|
||||
|
||||
@subsection occt_1746122829_872673383 Data layout and inheritance
|
||||
@subsection occt_tobj_3_3 Data layout and inheritance
|
||||
|
||||
As far as the data objects are separated from the interfaces and stored in the OCAF tree,
|
||||
the functionality to support inheritance is required. Each object has its own data
|
||||
and references stored in the labels in the OCAF tree. All data are stored in the sub-tree
|
||||
of the main object label. If it is necessary to inherit a class from the base class,
|
||||
the descendant class should use different labels for data and references than its ancestor.
|
||||
|
||||
Therefore each *TObj* class can reserve the range of tags in each of
|
||||
*Data*, *References*, and *Child* sub-labels.
|
||||
The reserved range is declared by the enumeration defined
|
||||
@ -522,6 +521,7 @@ The second argument, theRank2, allows accessing the next level of hierarchy
|
||||
(theRank2-th sub-label of theRank1-th data label).
|
||||
This is useful when the data to be stored are represented by multiple OCAF attributes
|
||||
of the same type (e.g. sequences of homogeneous data or references).
|
||||
|
||||
The get/set methods allow easily accessing the data located in the specified data label
|
||||
for the most widely used data types (*Standard_Real*, *Standard_Integer*, *TCollection_HExtendedString*,
|
||||
*TColStd_HArray1OfReal*, *TColStd_HArray1OfInteger*, *TColStd_HArray1OfExtendedString*).
|
||||
@ -549,13 +549,14 @@ Note that while references to other objects should be defined by descendant clas
|
||||
individually according to the type of object, *TObj_Object* provides methods
|
||||
to manipulate (check, remove, iterate) the existing references in the uniform way, as described below.
|
||||
|
||||
@subsection occt_1746122829_872673384 Persistence
|
||||
@subsection occt_tobj_3_4 Persistence
|
||||
|
||||
The persistence of the *TObj* Data Model is implemented with the help
|
||||
of standard OCAF mechanisms (a schema defining necessary plugins, drivers, etc.).
|
||||
This implies the possibility to store/retrieve all data that are stored
|
||||
as standard OCAF attributes., The corresponding handlers are added
|
||||
to the drivers for *TObj*-specific attributes.
|
||||
|
||||
The special tool is provided for classes inheriting from *TObj_Object*
|
||||
to add the new types of persistence without regeneration of the OCAF schema.
|
||||
The class *TObj_Persistence* provides basic means for that:
|
||||
@ -589,9 +590,9 @@ its persistence handler stores the runtime type of the object class.
|
||||
When the type is restored the handler dynamically recognizes the type
|
||||
and creates the corresponding object using mechanisms provided by *TObj_Persistence*.
|
||||
|
||||
@subsection occt_1746122829_872673385 Names of objects
|
||||
@subsection occt_tobj_35 Names of objects
|
||||
|
||||
All *TObj* model objects have names by which the user can refer to the object.
|
||||
All *TObj* model objects have names by which the user can refer to the object.
|
||||
Upon creation, each object receives a default name, constructed
|
||||
from the prefix corresponding to the object type (more precisely, the prefix is defined
|
||||
by the partition to which the object belongs), and the index of the object in the current partition.
|
||||
@ -600,7 +601,8 @@ by the naming mechanism (if the name is already used, it cannot be attributed to
|
||||
This default implementation of *TObj* package works with a single instance of the name container (dictionary)
|
||||
for name registration of objects and it is enough in most simple projects.
|
||||
If necessary, it is easy to redefine a couple of object methods
|
||||
(for instance *GetDictionary*()) and to take care of construction and initialization of containers.
|
||||
(for instance *GetDictionary*()) and to take care of construction and initialization of containers.
|
||||
|
||||
This functionality is provided by the following methods:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
@ -620,33 +622,36 @@ Returns the object name. The methods with in / out argument return False if the
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual Standard_Boolean SetName ( const Handle(TCollection_HExtendedString)& theName ) const;
|
||||
Standard_Boolean SetName ( const Handle(TCollection_HAsciiString)& theName ) const;
|
||||
Standard_Boolean SetName ( const Standard_CString theName ) const;
|
||||
Standard_Boolean SetName ( const Handle(TCollection_HAsciiString)& theName ) const;
|
||||
Standard_Boolean SetName ( const Standard_CString theName ) const;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Attributes a new name to the object and returns **True** if the name has been attributed successfully.
|
||||
Returns False if the name has been already attributed to another object.
|
||||
The last two methods are short-cuts to the first one.
|
||||
|
||||
@subsection occt_1746122829_872673386 References between objects
|
||||
@subsection occt_tobj_36 References between objects
|
||||
|
||||
Class *TObj_Object* allows creating references to other objects in the model.
|
||||
Such references describe relations among objects which are not adequately reflected
|
||||
by the hierarchical objects structure in the model (parent-child relationship).
|
||||
|
||||
The references are stored internally using the attribute TObj_TReference.
|
||||
This attribute is located in the sub-label of the referring object (called *master*)
|
||||
and keeps reference to the main label of the referred object.
|
||||
At the same time the referred object can maintain the back reference to the master object.
|
||||
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image007.png "Objects relationship"
|
||||
@image latex /user_guides/tobj/images/tobj_image007.png "Objects relationship"
|
||||
|
||||
|
||||
Picture 5 Objects relationship
|
||||
|
||||
The back references are stored not in the OCAF document but as a transient field
|
||||
of the object; they are created when the model is restored from file,
|
||||
and updated automatically when the references are manipulated.
|
||||
The class *TObj_TReference* allows storing references between objects
|
||||
from different *TObj* models, facilitating the construction of complex relations between objects.
|
||||
|
||||
The most used methods for work with references are:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
@ -682,14 +687,14 @@ Returns an iterator on the object back references.
|
||||
The argument theType restricts the types of master objects, or does not if it is NULL.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual void ReplaceReference ( const Handle(TObj_Object)& theOldObject, const Handle(TObj_Object)& theNewObject );
|
||||
virtual void ReplaceReference ( const Handle(TObj_Object)& theOldObject, const Handle(TObj_Object)& theNewObject );
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Replaces the reference to theOldObject by the reference to *theNewObject*.
|
||||
The handle theNewObject may be NULL to remove the reference.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual Standard_Boolean RelocateReferences ( const TDF_Label& theFromRoot, const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True );
|
||||
virtual Standard_Boolean RelocateReferences ( const TDF_Label& theFromRoot, const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True );
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Replaces all references to a descendant label of *theFromRoot*
|
||||
@ -708,21 +713,24 @@ This affects the behaviour of objects removal from the model – if the referenc
|
||||
either the referred object will not be removed, or both the referred
|
||||
and the master objects will be removed (depends on the deletion mode in the method **Detach**)
|
||||
|
||||
@subsection occt_1746122829_872673387 Creation and deletion of objects
|
||||
@subsection occt_tobj_3_7 Creation and deletion of objects
|
||||
|
||||
It is recommended that all objects inheriting from *TObj_Object*
|
||||
should implement the same approach to creation and deletion.
|
||||
|
||||
The object of the *TObj* data model cannot be created independently
|
||||
of the model instance, as far as it stores the object data in OCAF data structures.
|
||||
Therefore an object class cannot be created directly as its constructor is protected.
|
||||
|
||||
Instead, each object should provide a static method *Create*(), which accepts the model,
|
||||
with the label, which stores the object and other type-dependent parameters
|
||||
necessary for proper definition of the object. This method creates a new object with its data
|
||||
(a set of OCAF attributes) in the specified label, and returns a handle to the object's interface.
|
||||
|
||||
The method *Detach*() is provided for deletion of objects from OCAF model.
|
||||
Object data are deleted from the corresponding OCAF label; however,
|
||||
the handle on object remains valid. The only operation available after object deletion
|
||||
is the method *IsAlive*() checking whether the object has been deleted or not,
|
||||
is the method *IsAlive*() checking whether the object has been deleted or not,
|
||||
which returns False if the object has been deleted.
|
||||
|
||||
When the object is deleted from the data model, the method checks
|
||||
@ -754,9 +762,9 @@ Removes the object from the document if possible
|
||||
Unlinks references from removed objects.
|
||||
Returns **True** if the objects have been successfully deleted.
|
||||
|
||||
@subsection occt_1746122829_872673388 Transformation and replication of object data
|
||||
@subsection occt_tobj_3_8 Transformation and replication of object data
|
||||
|
||||
*TObj_Object* provides a number of special virtual methods to support replications of objects. These methods should be redefined by descendants when necessary.
|
||||
*TObj_Object* provides a number of special virtual methods to support replications of objects. These methods should be redefined by descendants when necessary.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
virtual Handle(TObj_Object) Clone (const TDF_Label& theTargetLabel, Handle(TDF_RelocationTable) theRelocTable = 0);
|
||||
@ -787,11 +795,11 @@ Adds to the copy of the original object its references.
|
||||
|
||||
Copies the children of an object to the target child label.
|
||||
|
||||
@subsection occt_1746122829_872673389 Object flags
|
||||
@subsection occt_tobj_3_9 Object flags
|
||||
|
||||
Each instance of TObj_Object stores a set of bit flags,
|
||||
Each instance of *TObj_Object* stores a set of bit flags,
|
||||
which facilitate the storage of auxiliary logical information assigned to the objects
|
||||
(object state). Several typical state flags are defined in the enumeration ObjectState:
|
||||
(object state). Several typical state flags are defined in the enumeration *ObjectState*:
|
||||
|
||||
* ObjectState_Hidden – the object is marked as hidden
|
||||
* ObjectState_Saved – the object has (or should have) the corresponding saved file on disk
|
||||
@ -818,11 +826,11 @@ Type flags can be received by the method:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The default implementation returns the flag **Visible**
|
||||
defined in the enumeration TypeFlags. This flag is used to define visibility
|
||||
of the object for the user browsing the model (see class TObj_HiddenPartition).
|
||||
defined in the enumeration *TypeFlags*. This flag is used to define visibility
|
||||
of the object for the user browsing the model (see class *TObj_HiddenPartition*).
|
||||
Other flags can be added by the applications.
|
||||
|
||||
@subsection occt_1746122829_8726733810 Partitions
|
||||
@subsection occt_tobj_310 Partitions
|
||||
|
||||
The special kind of objects defined by the class *TObj_Partition*
|
||||
(and its descendant *TObj_HiddenPartition*) is provided for partitioning
|
||||
@ -830,6 +838,7 @@ the model into a hierarchical structure. This object represents the container
|
||||
of other objects. Each *TObj* model contains the main partition that is placed
|
||||
in the same OCAF label as the model object, and serves as a root of the object's tree.
|
||||
A hidden partition is a simple partition with a predefined hidden flag.
|
||||
|
||||
The main partition object methods:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
@ -839,7 +848,7 @@ The main partition object methods:
|
||||
Allocates and returns a new label for creation of a new child object.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
void SetNamePrefix ( const Handle(TCollection_HExtendedString)& thePrefix);
|
||||
void SetNamePrefix ( const Handle(TCollection_HExtendedString)& thePrefix);
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Defines the prefix for automatic generation of names of the newly created objects.
|
||||
@ -868,37 +877,37 @@ Returns the last reserved child index.
|
||||
|
||||
Sets the last reserved index.
|
||||
|
||||
@section occt_1746122829_819520128 Auxiliary classes
|
||||
@section occt_tobj_4 Auxiliary classes
|
||||
|
||||
Apart from the model and the object, package *TObj* provides a set of auxiliary classes:
|
||||
|
||||
* TObj_Application - defines OCAF application supporting existence and operation with *TObj* documents.
|
||||
* TObj_Assistant – class provides an interface to the static data to be used during save and load operations on models. In particular, in case of cross-model dependencies it allows passing information on the parent model to the OCAF loader to correctly resolve the references when loading a dependent model.
|
||||
* TObj_TReference - OCAF attribute describes the references between objects in the *TObj* model(s). This attribute stores the label of the referred model object, and provides transparent cross-model references. At runtime, these references are simple Handles; in persistence mode, the cross-model references are automatically detected and processed by the persistence mechanism of TObj_TReference attribute.
|
||||
* Other classes starting with TObj_T... - define OCAF attributes used to store TObj-specific classes and some types of data on OCAF labels.
|
||||
* Iterators – a set of classes implementing TObj_ObjectIterator interface, used for iterations on *TObj* objects:
|
||||
* TObj_ObjectIterator – a basic abstract class for other *TObj* iterators. Iterates on TObj_Object instances.
|
||||
* TObj_LabelIterator – iterates on object labels in the *TObj* model document
|
||||
* TObj_ModelIterator – iterates on all objects in the model. Works with sequences of other iterators.
|
||||
* TObj_OcafObjectIterator – Iterates on *TObj* data model objects. Can iterate on objects of a specific type.
|
||||
* TObj_ReferenceIterator – iterates on object references.
|
||||
* TObj_SequenceIterator – iterates on a sequence of *TObj* objects.
|
||||
* TObj_CheckModel - a tool that checks the internal consistency of the model. The basic implementation checks only the consistency of references between objects.
|
||||
* *TObj_Application* - defines OCAF application supporting existence and operation with *TObj* documents.
|
||||
* *TObj_Assistant* – class provides an interface to the static data to be used during save and load operations on models. In particular, in case of cross-model dependencies it allows passing information on the parent model to the OCAF loader to correctly resolve the references when loading a dependent model.
|
||||
* *TObj_TReference* - OCAF attribute describes the references between objects in the *TObj* model(s). This attribute stores the label of the referred model object, and provides transparent cross-model references. At runtime, these references are simple Handles; in persistence mode, the cross-model references are automatically detected and processed by the persistence mechanism of *TObj_TReference* attribute.
|
||||
* Other classes starting with *TObj_T...* - define OCAF attributes used to store TObj-specific classes and some types of data on OCAF labels.
|
||||
* Iterators – a set of classes implementing *TObj_ObjectIterator* interface, used for iterations on *TObj* objects:
|
||||
* *TObj_ObjectIterator* – a basic abstract class for other *TObj* iterators. Iterates on *TObj_Object* instances.
|
||||
* *TObj_LabelIterator* – iterates on object labels in the *TObj* model document
|
||||
* *TObj_ModelIterator* – iterates on all objects in the model. Works with sequences of other iterators.
|
||||
* *TObj_OcafObjectIterator* – Iterates on *TObj* data model objects. Can iterate on objects of a specific type.
|
||||
* *TObj_ReferenceIterator* – iterates on object references.
|
||||
* *TObj_SequenceIterator* – iterates on a sequence of *TObj* objects.
|
||||
* *TObj_CheckModel* - a tool that checks the internal consistency of the model. The basic implementation checks only the consistency of references between objects.
|
||||
|
||||
The structure of *TObj* iterators hierarchy is presented below:
|
||||
|
||||
|
||||
@image html /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
|
||||
@image latex /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
|
||||
|
||||
Picture 6: Hierarchy of iterators
|
||||
|
||||
@section occt_1746122829_579029274 Packaging
|
||||
@section occt_tobj_5 Packaging
|
||||
|
||||
The *TObj* sources are distributed in the following packages:
|
||||
|
||||
* TObj - defines basic classes that implement *TObj* interfaces for OCAF-based modelers.
|
||||
* BinLDrivers, XmlLDrivers – binary and XML driver of *TObj* package
|
||||
* BinLPlugin, XmlLPlugin – plugin for binary and XML persistence
|
||||
* BinMObj, XmlMObj – binary and XML drivers to store and retrieve specific *TObj* data to or from OCAF document
|
||||
* TKBinL, TKXmlL – toolkits of binary and XML persistence
|
||||
* *TObj* - defines basic classes that implement *TObj* interfaces for OCAF-based modelers.
|
||||
* *BinLDrivers, XmlLDrivers* – binary and XML driver of *TObj* package
|
||||
* *BinLPlugin, XmlLPlugin* – plugin for binary and XML persistence
|
||||
* *BinMObj, XmlMObj* – binary and XML drivers to store and retrieve specific *TObj* data to or from OCAF document
|
||||
* *TKBinL, TKXmlL* – toolkits of binary and XML persistence
|
||||
|
||||
|
||||
|
||||
@ -1,23 +1,57 @@
|
||||
User Guides {#user_guides}
|
||||
===========
|
||||
|
||||
\subpage user_guides__foundation_classes "user_guides__foundation_classes"
|
||||
## Foundation Classes
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__modeling_data "user_guides__modeling_data"
|
||||
\subpage user_guides__foundation_classes
|
||||
|
||||
\subpage user_guides__modeling_algos "user_guides__modeling_algos"
|
||||
## Modeling Data
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__visualization "user_guides__visualization"
|
||||
\subpage user_guides__modeling_data
|
||||
|
||||
\subpage user_guides__iges "user_guides__iges"
|
||||
\subpage user_guides__step "user_guides__step"
|
||||
\subpage user_guides__xde "user_guides__xde"
|
||||
## Modeling Algorithms
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__ocaf "user_guides__ocaf"
|
||||
\subpage user_guides__tobj "user_guides__tobj"
|
||||
\subpage user_guides__modeling_algos
|
||||
|
||||
\subpage user_guides__shape_healing "user_guides__shape_healing"
|
||||
## Visualization
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__test_harness "user_guides__test_harness"
|
||||
\subpage user_guides__visualization
|
||||
|
||||
\subpage user_guides__wok "user_guides__wok"
|
||||
## IGES Support
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__iges
|
||||
|
||||
## STEP processor
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__step
|
||||
|
||||
## Extended Data Exchange (XDE)
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__xde
|
||||
|
||||
## OCAF
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__ocaf
|
||||
|
||||
## TObj Package
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__tobj
|
||||
|
||||
## Shape Healing
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__shape_healing
|
||||
|
||||
## Draw Test Harness
|
||||
**short description**
|
||||
|
||||
\subpage user_guides__test_harness
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
x
Reference in New Issue
Block a user