Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

Changes

Jump to navigation Jump to search
no edit summary
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]]

Navigation menu