Line 41: |
Line 41: |
| by the base part. If you're interested, see the source code on this issue's CD. | | by the base part. If you're interested, see the source code on this issue's CD. |
| <p> | | <p> |
− | If you want to write OpenDoc extensions, you'll have to dive into SOM, so this | + | If you want to write [[OpenDoc]] extensions, you'll have to dive into SOM, so this |
| article is a good starting point for you, too. | | article is a good starting point for you, too. |
| <ul> | | <ul> |
− | <b>OpenDoc developer releases</b> are available at http://www.opendoc.apple.com on the | + | <b>OpenDoc developer releases</b> are available at www.opendoc.apple.com on the |
| Web and on CD through a number of different sources. These releases include the | | Web and on CD through a number of different sources. These releases include the |
| OpenDoc Programmer's Guide, the IBM SOM manual, and the SOMobjects for Mac OS | | OpenDoc Programmer's Guide, the IBM SOM manual, and the SOMobjects for Mac OS |
Line 52: |
Line 52: |
| LOOK AT THE BASE PART | | LOOK AT THE BASE PART |
| </h3> | | </h3> |
− | We'll start with a look at the process of building an OpenDoc part, which is | + | We'll start with a look at the process of building an [[OpenDoc]] part, which is |
| really a SOM object. Since we currently don't have a direct-to-SOM compiler on | | really a SOM object. Since we currently don't have a direct-to-SOM compiler on |
| the Macintosh, the process consists of two steps:<p> | | the Macintosh, the process consists of two steps:<p> |
Line 63: |
Line 63: |
| <p><li> We write in C++ the body of the methods described in the .idl source | | <p><li> We write in C++ the body of the methods described in the .idl source |
| file. </ul>We then have all the necessary files to build the whole project and | | file. </ul>We then have all the necessary files to build the whole project and |
− | get the OpenDoc part. Because the first step is always the same for simple | + | get the [[OpenDoc]] part. Because the first step is always the same for simple |
| parts, most developers never bother with it themselves, but instead use | | parts, most developers never bother with it themselves, but instead use |
| PartMaker to automatically generate the files associated with this step (.idl, | | PartMaker to automatically generate the files associated with this step (.idl, |
Line 205: |
Line 205: |
| OBJECTS VS. C++ OBJECTS | | OBJECTS VS. C++ OBJECTS |
| </h3> | | </h3> |
− | An OpenDoc part is really a SOM object (in our example, | + | An [[OpenDoc]] part is really a SOM object (in our example, |
− | ACF_DevServ_som_ListPart) and is known to OpenDoc as such. The C++ object | + | ACF_DevServ_som_ListPart) and is known to [[OpenDoc]] as such. The C++ object |
| generated by PartMaker (in our example, ListPart) is a wrapper that serves to | | generated by PartMaker (in our example, ListPart) is a wrapper that serves to |
| simplify the data management and the code writing in the absence of a | | simplify the data management and the code writing in the absence of a |
Line 218: |
Line 218: |
| som_ListPart.cpp and ListPart.cpp) points, in this case, to the | | som_ListPart.cpp and ListPart.cpp) points, in this case, to the |
| ACF_DevServ_som_ListPart SOM object. <p> | | ACF_DevServ_som_ListPart SOM object. <p> |
− | What happens in response to an OpenDoc call when a SOM object inherits from our | + | What happens in response to an [[OpenDoc]] call when a SOM object inherits from our |
| SOM base class? Say our SOM object of class ACF_DevServ2_som_ListEx1Part, | | SOM base class? Say our SOM object of class ACF_DevServ2_som_ListEx1Part, |
| inheriting from ACF_DevServ_som_ListPart, contains no data and only two methods | | inheriting from ACF_DevServ_som_ListPart, contains no data and only two methods |
Line 596: |
Line 596: |
| class, inheriting from nothing. Remember, the SOM objects are real, while the | | class, inheriting from nothing. Remember, the SOM objects are real, while the |
| C++ objects are there only to simplify the coding and aren't known by | | C++ objects are there only to simplify the coding and aren't known by |
− | OpenDoc.<p> | + | [[OpenDoc]].<p> |
| The modifications made to som_ListEx2Part.cpp, ListEx2Part.h, and | | The modifications made to som_ListEx2Part.cpp, ListEx2Part.h, and |
| ListEx2Part.cpp are very similar to those made in the previous example, so I | | ListEx2Part.cpp are very similar to those made in the previous example, so I |
Line 779: |
Line 779: |
| NOTE ON USING GLOBALS | | NOTE ON USING GLOBALS |
| </h4> | | </h4> |
− | Let's not forget that if OpenDoc is based on SOM, SOM is based on the Code | + | Let's not forget that if [[OpenDoc]] is based on SOM, SOM is based on the [[Code Fragment Manager (CFM)]], and this greatly simplifies such programming aspects as |
− | Fragment Manager (CFM), and this greatly simplifies such programming aspects as | |
| management of globals. Indeed, with the CFM architecture, there's no more need | | management of globals. Indeed, with the CFM architecture, there's no more need |
| for SetUpA5, SetCurrentA5, SetA5 (or even SetUpA4, provided by some | | for SetUpA5, SetCurrentA5, SetA5 (or even SetUpA4, provided by some |
Line 787: |
Line 786: |
| library, but that doesn't prevent us from declaring and using the string | | library, but that doesn't prevent us from declaring and using the string |
| globals found in ListEx3Part.cpp, for example. The only trick we've got to pay | | globals found in ListEx3Part.cpp, for example. The only trick we've got to pay |
− | attention to is this: since OpenDoc loads the library fragment only once when | + | attention to is this: since [[OpenDoc]] loads the library fragment only once when |
| the first part is instantiated, with the kLoadLib flag set and not the | | the first part is instantiated, with the kLoadLib flag set and not the |
| kLoadNewCopy flag, globals declared in the library will be shared by all | | kLoadNewCopy flag, globals declared in the library will be shared by all |
Line 795: |
Line 794: |
| REMARKS | | REMARKS |
| </h3> | | </h3> |
− | I hope you now have a better understanding of the workings of OpenDoc, SOM, and | + | I hope you now have a better understanding of the workings of [[OpenDoc]], SOM, and |
| PartMaker. Dynamic inheritance is a powerful tool. You can easily construct | | PartMaker. Dynamic inheritance is a powerful tool. You can easily construct |
| your own useful base parts to be inherited from by yourself and by others. The | | your own useful base parts to be inherited from by yourself and by others. The |
Line 825: |
Line 824: |
| triangle symbol pointing to the next level).<p> | | triangle symbol pointing to the next level).<p> |
| You get the idea. Why not give SOM dynamic inheritance a try yourself? Then | | You get the idea. Why not give SOM dynamic inheritance a try yourself? Then |
− | spread the word that OpenDoc isn't just for desktop publishing.<p> | + | spread the word that [[OpenDoc]] isn't just for desktop publishing.<p> |
| + | |
| + | =See Also= |
| + | * [[OpenDoc]] |
| + | * [[Apple Computer]] |
| | | |
| [[Category:Apple]][[Category:Programming]] | | [[Category:Apple]][[Category:Programming]] |
| + | [[Category:OpenDoc]] |