TweetFollow Us on Twitter

September 93 - OSL Scripting Components

OSL Scripting Components

Bo Klintberg

A Generic Scripting Architecture for Standalone and Client/Server-based MacApp Applications.
Part 1: The Client Side.

If you're desperately seeking scripting and recording source code to incorporate into your own MacApp programs, you might want to check out a new product called Developer's C++ Source Code Library: OSL Scripting Components.

This product provides the developer with well over 100 carefully designed and documented classes for scripting, recording, and Apple events communication. This full-fledged library of extensible building blocks also helps you to implement other related features such as the management of client and server applications in computer networks. And all this without having to modify a single line of the original MacApp 3.0.x source code!

Using the classes in the OSL Scripting Components package will radically decrease the time it takes to learn what Apple events really is all about. In fact, to guarantee you the quickest possible learning curve, I designed a couple of classes that produces a Sourcebug-like log window, so that you easily can monitor what's really happening inside your application. The ScriptSender and ScriptServer demos (included in the OSL Scripting Components package) both use log windows to let you see what's happening (see Figure 1). Here's how the OSL Scripting Components can be used to communicate with itself, both over the network (as seen here) and within the same application. Since both the client and the server send and handle standard Apple events according to the Required and the Core suites defined by Apple, they can communicate with any other application that also uses the same protocol, for example the ScriptEditor shown in Figure 2.

Note that the client's log window reports that the menu command has been handled and that the Apple event is sent away to its server destination. A moment later the server application's log window reports that it has handled the Apple event, resolved the object specifiers and reached its final goal: for example to get the data we wanted. Then the server sends back the result to the client, thus producing a new line in the client's log window, confirming the result. The last action in a log window is always autoscrolled and highlighted for maximum convenience.)


Scripting can be implemented in an application in a variety of ways. The three basic mechanisms are sending, receiving and recording. All of these are supported by the OSL Scripting Components package, which enables you to smoothly and easily attach scripting functionality to your existing or up-coming product.

Script-sending Applications

Some of you might like to create client applications that send scripting Apple events to server applications like FileMaker, Excel, Canvas, or the ScriptServer. With the OSL Scripting Components source code in your hands, you can easily select a server application and then send standard core suite events to it. Thus, you can mimic the sending behavior of, for example, Apple Computer's Script Editor (previously called Toy Surprise), or you could create a script-sending application named Updater that:
  • Retrieves the data from all of John's currently open Excel documents;
  • Processes that retrieved data inside your Updater application;
  • Sends away the processed data to the "Results" FileMaker file on Anne's Macintosh.

Script-receiving Applications

Some developers may like to create applications that can handle the receiving and replying of standard suite scripting events. Such events could come from script-sending applications like the ScriptEditor or the ScriptSender. A good script-receiving application can handle requests from many clients simultaneously (see Figure 2). Using the OSL Scripting Components package as a server, you can receive and properly handle standard scripting Apple events from any other script-sending application that implements the Core suite protocol. An example of such an application is Apple Computer's Script Editor as seen above.)

Script-recordable Applications

Some developers would want to develop recordable applications-that is, applications that can send and receive scripting events within themselves. In this case, the application acts both as a sender and a receiver and sends the events to itself.


Don't "Fix" MacApp

One of the main design objectives was to leave the MacApp original code untouched. This has been achieved, and you can use the OSL Scripting Components package without modifying the original MacApp code.

Since we don't rely on having to modify MacApp itself, this package should also be compatible, direct out of the box, with the forthcoming MacApp 3.0.2 / 3.1. Also, if Bedrock can't/won't implement scripting in its first release, it should be no great obstacle to convert it to that platform, if necessary.

"Fix" MacApp

The OSL Scripting Components is designed to leave the MacApp code untouched (see the section above). But, of course, there's nothing stopping you from copying and pasting the code from the TOSLObject, TOSLObjectDescription, and TObjectResolver classes in the OSL Scripting Components package into MacApp's TObject and nearby. In fact, it's designed to be able to do that too, if you really want it. Also, you would have to provide support for the generation of TOSLObject-Descriptions and TObjectResolvers, but again, you can copy the same thing I did in TOSLApplication, TOSLWindow, and TOSLFileBasedDocument.

And, don't forget to recompile MacApp!

Should Work BETWEEN Applications as Well as WITHIN Applications

Another really important matter was the need to streamline the sending and receiving of Apple events so that the packing and the unpacking of Apple events would be done in exactly the same way when using a client app-server app configuration as when using a client-side/server-side configuration. This is an important matter, because you really can REUSE code this way. This has been achieved with asynchronous Apple events.

Example: If you have posted a TGetBooleanDataFromServer command in the client, it doesn't matter where the server is (it could be the same application as the client or another application on another machine on the network), as long as you have a valid address to that server.

Please note that I whenever I say "server" or "client" in this article (and don't specify it further) this means it's applicable both in a client-side/server-side configuration within one application as well as in a client app/server app setup.

The Server Should Report Errors to its Client(s)

Sending and receiving Apple events is not all that hard to do, especially when doing it only within one application. But at the moment when you're deciding to use a client application/server application setup, you have to give the error handling just a little bit more attention.

One of the most important issues is the one about letting the server application respond with an error code and error string whenever an error occurs in the server. Just issuing a FailOSErr() is unfortunately not good enough-this doesn't send a reply error to the client. Instead I had to add a couple of extra lines of code on the server side for proper and timely responding to the client.


Very soon after I started with the OSL and Apple events coding, I realized that I had some major design and modeling issues to investigate in order to make the creation, sending, and receiving of OSL Apple events easy, flexible, and secure to use (and reuse) for the end programmer. My primary goal was to be able to create an architecture so that I, with a handful of lines of code, could administrate the whole packing, sending, and receiving process, without ever worrying about all those boring details underneath. Here's how I wanted the code to look like in a typical client's DoMenuCommand:
case cSetCellData: this->DoSetCellData();

OK, that was real easy, I admit. Now let's look at what happens inside the DoSetCellData method.

pascal void DoSetCellData()
    TOSLObjectDescription* cellDescription =
    CStr255 newStringData = GetStringDataFromUser();    
        // or from somewhere else…
    TSetServerCellDataCmd* aSetServerCellDataCmd = 
        new TSetServerCellDataCmd;
    aSetServerCellDataCmd ->ISetServerCellDataCmd 
        (cellDescription,   newStringData );
    gApplication->PostCommand(aSetServerCellDataCmd );

On the first line I call the BuildCellDescription method, which creates a TOSLObjectDescription object. The TOSLObject-Description object contains a full description of a standard Apple Event Registry cCell object.

On the second line I get the data I want to put into the cell in the server application.

On the third, fourth and fifth lines I create the client command, initiate it and post it to the client application's event queue, which immediately performs the command, thus sending the kAESetDataApple event to the server. We'll look at the details in just a minute.


OSL Object Descriptions

A central class in the OSL Scripting Components package is the TOSLObjectDescription class, which is used to universally describe an object. This means that you, the programmer, can more easily manage the sending and receiving of Apple events according to the OSL standards.

Since Apple events are verb-oriented (each event is a verb like Create, Delete or Open), it made sense to me to define a set of standard event-sending commands that corresponded to each and every one of these verbs. Each such command could have an object description as a parameter, telling the verb which object it should perform its actions on.

The TOSLObjectDescription is a class descending directly from TObject. As you can see in the more detailed description below, it contains a generic description of an object and its "outer" containers.

OSL Objects

Now that we have an universal way of describing objects (the TOSLObjectDescription), it is time to define one of the other main components of this library, the TOSLObject. Any object that you would want to be scriptable must inherit from TOSLObject. This could be, for instance, an application, a window, or a file. The TOSLObject provides a dozen methods, of which you must override only a few. Also, the OSLObject has a strong relation to the TOSLObjectDescription, since you may want to generate object descriptions for any "live" object you can have.

OSL Object Resolvers

These are almost without exception used on the server side of the application. Their mission in life is to resolve the incoming Apple events and their stuffed object descriptions into something the server can understand. TOSLObjectResolvers will be discussed in greater detail in an upcoming article here in FrameWorks.

Client and Server Commands

An important part of the OSL Scripting Components library is the commands that send and receive all those Apple events. On the server side we use subclasses of MacApp's TServer-Command to handle an incoming event and to generate a reply to the client. On the client side we use a subclass of TClient Command (also a MacApp class) to send it and handle the reply from the server.


When it comes to understanding how the OSL and scripting really works, we have to talk about how to describe objects in a generic way. The OSL uses a concept that's called "object specifier" to describe an object. Simply put it's a full path to the object, much like a Macintosh file's path in HFS.

If we're describing only one object (for example an application object) we have what's called a simple object specifier: application "ScriptSender". However, if one object is put into another object, we have what's called a complex object specifier: window "Client Log" of application "ScriptSender".

An object specifier can be constructed in different ways. Some of these different ways, called reference forms, are:

  • by index ("car 23")
  • by absolute position ("last car")
  • by relative position ("next car")
  • by name ("the car with the name of BMW")

What Exactly is a TOSLObjectDescription?

The object that we are describing doesn't actually have to exist in the application as an object instance; instead, it's enough that the application understands the description of the object so that it can instantiate it on the fly, if the application finds that it represents something tangible. If the server can't locate the object (it might not be a valid reference like the third window in application, but there are only two windows right now in the application) it sends an error message back to the client saying that it couldn't find the object.

Since object specifiers are somewhat hard to handle properly (have you ever seen one of Apple's non-object oriented source code examples?), I decided to build a class around them. The benefits of using a TOSLObjectDescription class are many: easy to create, easy to send, and easy to garbage collect.

Easy to Create Descriptions Even Without the "Real" Object.

You'll quickly create a description of the object of your choice totally from scratch. Here's how you would create a description of the last table in the document "my doc":
TOSLFileBasedDocumentDescription* docDecription;
TOSLTableDescription* tableDescription;

docDecription = new TOSLFileBasedDocumentDescription;
docDecription->IOSLFileBasedDocumentDescriptionByName("my doc");
tableDescription = new TOSLTableDescription;
    (docDecription, kAELast);

Use this strategy any time you want, especially when you want to describe an object that's somewhere on the server side but has no "live" object instance on the client side.

Sometimes, however, you may have object instances on the client side that are not of the same class as the objects on the server side. A typical example could be to have a TOSLFile-BasedDocument object in the server application, which you represent in the client application with a TMyDocument object. In your TMyDocument your could define a method called GetDescriptionOfMyServerDocument which would do this:

pascal TOSLObjectDescription* TMyDocument::
    // Get the doc's name:
    CStr255 name;       // Assuming your client's doc representation
                        // has the this->GetTitle(name);    
                        // same name as the TFileBasedDocument 
                        // in the server

    //Synthesize the document description:
    TOSLFileBasedDocumentDescription* docDecription;
    docDecription = new TOSLFileBasedDocumentDescription;

    return docDecription;   // return the description

An even better way to do it would be to let the TMyDocument class inherit from TOSLDocument instead of from TDocument and to define a GetDescriptionOfMe method, similar to the one shown in the next section.

Easy-to-create Descriptions When You Already Have an Object

The OSL Scripting and Recording library also supports automatic generation of a full description of any valid object that is a subclass from the TOSLApplication, TOSLWindow, and so on. Each TOSLObject has a method called GetDescription-OfMeAndMyContainers(), which returns each TOSLObject's "best" and usually, most complete description, containing all of its containers too. The method GetDescriptionOfMeAnd-MyContainers is defined in the TOSLObjectClass and need not be overridden:
pascal TOSLObjectDescription* TOSLObject::
    TOSLObjectDescription* myContainers = 
    TOSLObjectDescription* meAndMyContainers = 
    return meAndMyContainers;

The GetDescriptionOfMe method that gets called above must be overridden by its direct subclass. Here's an example of how I do just that when I define a TOSLTable, which inherits directly from TOSLObject:

pascal TOSLObjectDescription* TOSLTable::GetDescriptionOfMe(
        TOSLObjectDescription* theOSLObjectDescription) // override
    CStr255 theTableName = this->GetName();
    TOSLTableDescription* anOSLTableDescription = 
        new TOSLTableDescription;
        (theOSLObjectDescription, theTableName);
    return anOSLTableDescription;

Using this strategy is very convenient, both in the client and in the server. A typical situation is this: the client prepares an object description from a "live" object and puts the result into an Apple event and sends it away to the server. Normally, the server resolves the request and returns some data without using object descriptions at all. The only events that return typeObjectSpecifiers (which means that you should use a TOSLObjectDescription) are the kAECreateElement and the kAEClone events.

Easy to Send

All client commands that are subclassed from TAbstract-OSLObjectDescriptionCommand class take a TOSLObject-Description object as a parameter. This command object administrates the sending of the Apple event to the server and handles the response sent from the server in a generic way-it prints the result to the built-in log window (if you have not defined the compile-time variable qWantLogWindow then the window is displayed). If you actually want to put the result of the command inside your own data field, then that's OK too. Then you just have to override two methods to achieve that result: the I-method and the ProcessResult-method. For example, override the IGetServerTableNameCommand to be able to provide your command with a field that is some pointer to a place where you want to store the command's resulting data. Then you override the ProcessResult method to actually use that field to put the data into the client.

So, sending for example a kAEGetData command to the server in order to retrieve the name of the last table in the document "my doc" is no harder than this:

TGetServerTableNameCommand* aGetServerTableNameCommand;

Easy to Garbage Collect

Since we put the AEDescs inside a container (the TOSLObject-Description) we can dispose of them in a controlled manner. And since we actually put the TOSLObjectDescriptions inside the command that we're sending, the command can be (and actually is) responsible for the disposal. So when the command has finished its sending (and the handling of the reply, if necessary), then it's time for it to say "farewell" to the TOSL-ObjectDescription and its contained AEDescs.


Now, let's inspect the TOSLObjectDescription class a little closer. As you can see from the declaration in the interface of the class below, there are seven magic data members that we want to keep track of.
class TOSLObjectDescription: public TObject
    DescType                fObjectSpecifierClass;
    DescType                fPropertyID;
    DescType                fKeyForm;
    AEDesc                  fKeyData;
    AEDesc                  fObjectSpecifier;
    AEDesc                  fPropertySpecifier;
    TOSLObjectDescription*  fItsContainer;

// Construction/Destruction:
    virtual pascal void Initialize();   // override
    virtual pascal void IOSLObjectDescription(
        DescType theObjectSpecifierClass,
        TOSLObjectDescription* itsContainer);   
    virtual pascal void IOSLObjectDescriptionByAbsoluteIndex(
        DescType theObjectSpecifierClass,
        TOSLObjectDescription* itsContainer,
        long theIndex); 
    virtual pascal void IOSLObjectDescriptionByAbsolutePosition(
        DescType theObjectSpecifierClass,
        TOSLObjectDescription* itsContainer,
        DescType theAbsolutePosition);  
    virtual pascal void IOSLObjectDescriptionByRelativePosition(
        DescType theObjectSpecifierClass,
        TOSLObjectDescription* itsContainer,
        DescType theRelativePosition);  
    virtual pascal void IOSLObjectDescriptionByName(
        DescType theObjectSpecifierClass,
        TOSLObjectDescription* itsContainer,
        const CStr255& theName);    

    virtual pascal void Free();     // override

// Access:
    virtual pascal TOSLObjectDescription* GetItsContainer();
    virtual pascal AEDesc GetObjectSpecifier();
    virtual pascal DescType GetPropertyID();
    virtual pascal AEDesc GetPropertySpecifier();
    virtual pascal void SetObjectSpecifierClass(
        DescType theObjectSpecifierClass);
    virtual pascal void SetItsContainer(
        TOSLObjectDescription*  itsContainer);
    virtual pascal void SetObjectSpecifier(
        AEDesc theObjectSpecifier);
    virtual pascal void SetPropertyID(DescType thePropertyID);
    virtual pascal void SetPropertySpecifier(
        AEDesc  thePropertySpecifier);
// Action:
    virtual pascal AEDesc DuplicateObjectSpecifier();
    virtual pascal AEDesc DuplicatePropertySpecifier();
    virtual pascal AEDesc DuplicateKeyData();
    virtual pascal void PrepareObjectSpecifierByName(
        const CStr255& theName);
    virtual pascal void PrepareObjectSpecifierByAbsoluteIndex(
        long theIndex);
    virtual pascal void CreateObjectSpecifier();
    virtual pascal void CreatePropertySpecifier(
        DescType thePropertyID);

Only three fields are filled with data during the "inner" initialization phase (in the IOSLObjectDescription method) of the object: fObjectSpecifierClass, fPropertyID and fItsContainer. The fObjectSpecifierClass is the object's Apple event registry object class (for example cWindow, cApplication, or cTable). The property ID is the ID of the property we are interested in, for example a pName property. The fItsContainer is this object's outer container. For example, a window description's fItsContainer is very likely an application description.

What about the rest of the fields in the TOSLObject-Description class? Well, they are initialized by the "outer" initialization phase, which is, as seen by the method names, more specific in its nature. For example, the IOSLObject-DescriptionByAbsoluteIndex initialization method requests an absolute index as an extra parameter. Since we specify "absolute index" and supply a value of type long, we can start the actual preparing of the object specifier description. The preparing is (in this case) done in the method PrepareObjectSpecifier-ByAbsoluteIndex, which loads the fields fKeyData with an pure fresh AEDesc of type typeLongInteger and the field fKeyForm gets the constant formAbsolutePosition.

Other examples of "outer" initialization methods are IOSLObjectDescriptionByName, IOSLObjectDescriptionBy-AbsolutePosition, and IOSLObjectDescriptionByRelative-Position.


OK, so now you want create your own TOSLTableDescription class. What do you have to do? Again, it's quite simple. Say that you would want to describe a table description either by its name or its index. All you would have to do would be to create two I-methods in your new table describer-class, which you would probably name TOSLTableDescription. Each reference form (by name, by index) demands its own I-method.

In the implementation part of IOSLTableDescription-ByAbsoluteIndex you'll only do one thing: call the IOSLObject-DescriptionByAbsoluteIndex method. And the only thing that you do in the IOSLTableDescriptionByName method is to call IOSLObjectDescriptionByName. Here's the class declaration:

class TOSLTableDescription: public TOSLObjectDescription
// Construction/Destruction
    virtual pascal void IOSLTableDescriptionByAbsoluteIndex(
        TOSLObjectDescription* itsContainer, long theIndex);
    virtual pascal void IOSLTableDescriptionByName(
        TOSLObjectDescription* itsContainer,
        const CStr255& theName);

and here 's the definition:

pascal void TOSLTableDescription::
    TOSLObjectDescription* itsContainer, long theIndex)
pascal void TOSLTableDescription::IOSLTableDescriptionByName(
    TOSLObjectDescription* itsContainer, const CStr255& theName)


Any object in your application that you want to be scriptable must inherit from TOSLObject. What exactly does a TOSL-Object do?

Well, investigating the interface for the TOSLObject might enlighten you a bit (see below). Here you'll see that a TOSLObject always stores a reference to its parent object in the fContainerObject field. Reading the Apple Event Registry gives you detailed information on how you should arrange your object hierarchies in your application. Looking for example at the object cApplication in the Apple Event Registry, this tells you that cApplication has two element classes: cDocument and cWindow. Thus, if you should define your own TOSLWindow (but you don't have to, since it's already supplied with the product), you would know that it should be initialized with an application object in the itsContainer parameter.

class TOSLObject : public TObject
private :
TObject* fContainerObject;
public :
// Create / delete
    virtual pascal void Initialize();
    virtual pascal void IOSLObject(TObject* itsContainer);
    virtual pascal void Free();

    virtual pascal TObject* GetContainerObject();
// TOSLObjectDescription support:
    virtual pascal TOSLObjectDescription*
    virtual pascal TOSLObjectDescription*
    virtual pascal TOSLObjectDescription* GetDescriptionOfMe(
                TOSLObjectDescription* theOSLObjectDescription); 
    //subclass this one

Another important feature of the TOSLObject class is its close relationship with TOSLObjectContainer class. It has three methods which all return a TOSLObjectDescription object. The one that you will be calling yourself in your code is the GetDescriptionOfMeAndMyContainers, which calls the other two methods to construct an up-to-date description of the object in question:

pascal TOSLObjectDescription* TOSLObject::
    TOSLObjectDescription* myContainers = 
    TOSLObjectDescription* meAndMyContainers = 
    return meAndMyContainers;

You will, however, have to override the GetDescriptionOfMe() method, since I cannot decide for you what the "best" description of a generic object should be. Some objects might be better off by being described with an index, and others may want to be described with names instead (or colors, sounds, IDs, whatever). Since I didn't put any extra fields in the TOSLObject class to minimize the overhead, I simply can't describe the object.

Here's my override of GetDescriptionOfMeAndMyContainers from the TOSLTable class:

pascal TOSLObjectDescription* TOSLTable::GetDescriptionOfMe(
            TOSLObjectDescription* theOSLObjectDescription)
    CStr255 theTableName = this->GetName();
    TOSLTableDescription* anOSLTableDescription = 
        new TOSLTableDescription;
    return anOSLTableDescription;

An alternative in the implementation of the OSL Scripting Components library could have been to define a fName or/and a fIndex field in the TOSLObject class and to provide a fully functional GetDescriptionOfMe method which by default returns for example a description by index.

To give you the best of two worlds, I decided to override TOSLObject with a new class called TOSLSearchableObject, which has these two fields inside. By default I have implemented the GetDescriptionOfMe method, so that it uses its name to describe it. Of course, there's nothing stopping you from overriding this method anyway. But before you do, take a look at TSearchableObject: it works together with a list object and supplies basic functionality of objects in small lists and includes searching and sorting the objects with their name and their index. And since these objects are TOSLObjects, you'll get immediate scriptability. And which application hasn't the need for objects in small lists?


When you're in the mood for switching to scriptability you want to get it done with-fast. And fast it is: the only thing you have to do is to change the inheritance of those of your classes that you want to have scriptable. If it inherits from TObject then you should change that to TOSLObject instead. If it inherits from TApplication, TDocument, TFile, or any other of the "major" classes of MacApp, then you should inherit your classes from TOSLApplication, TOSLWindow, and TOSL-Document instead.

This way, you immediately can enjoy scriptability in your own application, without writing any new lines!


If you started like me, you might have experimented with just using MacApp's TAppleEvent class on its own to fire off an event or two. The problem with using the TAppleEvent class on its own, however, is that there's no coordination whatsoever between the TAppleEvent and the MacApp's event handling mechanism-if you send a TAppleEvent to a server destination, and the server sends back a TAppleEvent reply, you're still not sure if the event you receive in the client actually is the reply or a completely different and unrelated event.

TClientCommand, however, uses some features in MacApp's TApplication class to correctly dispatch the reply that is coming back from the server. In fact, MacApp has defined its own commando-constant called cAppleEventReply to be able to dispatch it in its own way, instead of letting the event "get in the programmer's way" into the DoAppleCommand method. When MacApp receives such an event it tries to match it with the events in TApplication's fPendingReplyList, which is a list of all commands that are sent but not yet received. If the incoming event's keyReturnIDAttr is the same as one in the fPending-ReplyList, then MacApp considers it to actually be the reply.

Using TClientCommand and TServerCommand

The idea of command objects is great-a housing for actions that has to be performed, and possibly, undone. In user interface-heavy MacApp programs, you normally use commands because you want to be able to undo user actions. This is not, however, the only time when you would want to work with commands.

Another place where they really fit in is when we're administrating the communication in client/server-based systems. These systems tend to be rather complex: all of the commands that are sent between the client and the server can have different numbers and types of sending and replying parameters. So, to be able to create a simple-to-use but yet powerful Apple event communications architecture, I decided to build it around MacApp's TClientCommand and TServerCommand.

The nice thing about TClient-Command and TServer-Command is that they identify the need to administrate the sending and receiving of a command in just one single place. This way, you'll get the benefit of having one method in the class handling the sending parameters and another method in the same class handling the replies.

The Layers Of Communication

Just as in any communications architecture, the communication is divided into several layers, which handle different things. In the AppleTalk communication there are for example the ADSP, ATP, ASP, and DDP. Here, I have implemented a set of classes that are built on each other to separate the responsibilities for a cleaner design. In the example below, I've just walked through one of the possible ways through the framework-see the simplified class diagram for a more complete picture (see Figure 3). Here's a class diagram for some of the commands in the OSL Scripting Components library. Note that the layers are oriented from left to right, with each column a little bit more "powerful" than its column to the left.):
  • TOSLClientCommand
  • TOSLClientReplyCommand
  • TAbstractOSLObjectDescription
  • TAbstractAEGetDataCommand
  • TStringAEGetDataCommand
  • TGetServerApplicationNameCommand

The TOSLClientCommand is responsible for seeing to it that the command can handle TOSLAppleEvents instead of TAppleEvents.

TOSLClientReplyCommand makes the command into an asynchronous command (if you want that).

The TAbstractOSLDescription uses an objectDescription as a parameter and detaches and frees it when ready.

The TAbstractAEGetDataCommand identifies that it is a kAEGetData core suite command, but leaves it to its subclasses to actually coerce the reply correctly.

TStringAEGetDataCommand gets a string from the server and processes it as a CStr255.

TheGetServerApplicationNameCommand builds a TOSLApplicationDescription automatically and passes along the pName property to the TStringAEGetData command. You should actually use an override of this command to be able to store the retrieved data in a field or wherever is convenient for you.


Community Search:
MacTech Search:

Software Updates via MacUpdate

Dash 4.1.6 - Instant search and offline...
Dash is an API documentation browser and code snippet manager. Dash helps you store snippets of code, as well as instantly search and browse documentation for almost any API you might use (for a full... Read more
OfficeTime 1.8.2 - Easy time and expense...
OfficeTime is time and expense tracking that is easy, elegant and focused. Other time keepers are clumsy or oversimplified. OfficeTime balances features and ease of use, allowing you to easily track... Read more
OmniOutliner Essentials 5.3 - Organize y...
OmniOutliner Essentials (was OmniOutliner) is a flexible program for creating, collecting, and organizing information. Give your creativity a kick start by using an application that's actually... Read more
OmniOutliner Essentials 5.3 - Organize y...
OmniOutliner Essentials (was OmniOutliner) is a flexible program for creating, collecting, and organizing information. Give your creativity a kick start by using an application that's actually... Read more
OfficeTime 1.8.2 - Easy time and expense...
OfficeTime is time and expense tracking that is easy, elegant and focused. Other time keepers are clumsy or oversimplified. OfficeTime balances features and ease of use, allowing you to easily track... Read more
Dash 4.1.6 - Instant search and offline...
Dash is an API documentation browser and code snippet manager. Dash helps you store snippets of code, as well as instantly search and browse documentation for almost any API you might use (for a full... Read more
Civilization VI 1.1.0 - Next iteration o...
Sid Meier’s Civilization VI is the next entry in the popular Civilization franchise. Originally created by legendary game designer Sid Meier, Civilization is a strategy game in which you attempt to... Read more
Network Radar 2.3.3 - $17.99
Network Radar is an advanced network scanning and managing tool. Featuring an easy-to-use and streamlined design, the all-new Network Radar 2 has been engineered from the ground up as a modern Mac... Read more
Quicken 5.5.6 - Complete personal financ...
Quicken makes managing your money easier than ever. Whether paying bills, upgrading from Windows, enjoying more reliable downloads, or getting expert product help, Quicken's new and improved features... Read more
Civilization VI 1.1.0 - Next iteration o...
Sid Meier’s Civilization VI is the next entry in the popular Civilization franchise. Originally created by legendary game designer Sid Meier, Civilization is a strategy game in which you attempt to... Read more

Latest Forum Discussions

See All

Construction Simulator 2 reaches its fir...
Construction Simulator 2 debuted iOS and Android devices exactly one year ago, and publisher Astragon is marking the game’s first anniversary with a range of time-limited discounts. It’s been a successful debut for the civil engineering sim, which... | Read more »
All the best games on sale for iPhone an...
This week's list of games on sale for the iPhone and iPad isn't too bad really. There's some gems on here, as well as some games that have had their prices cut low enough that you can look past the rough edges and questionable decisions. [Read... | Read more »
The best games that came out for iPhone...
It's not a huge surprise that there's not a massive influx of new, must-buy games on the App Store this week. After all, GDC is happening, so everyone's busy at parties and networking and dying from a sinister form of jetlag. That said, there are... | Read more »
Destiny meets its mobile match - Everyth...
Shadowgun Legends is the latest game in the Shadowgun series, and it's taking the franchise in some interesting new directions. Which is good news. The even better news is that it's coming out tomorrow, so if you didn't make it into the beta you... | Read more »
How PUBG, Fortnite, and the battle royal...
The history of the battle royale genre isn't a long one. While the nascent parts of the experience have existed ever since players first started killing one another online, it's really only in the past six years that the genre has coalesced into... | Read more »
Around the Empire: What have you missed...
Oh hi nice reader, and thanks for popping in to check out our weekly round-up of all the stuff that you might have missed across the Steel Media network. Yeah, that's right, it's a big ol' network. Obviously 148Apps is the best, but there are some... | Read more »
All the best games on sale for iPhone an...
It might not have been the greatest week for new releases on the App Store, but don't let that get you down, because there are some truly incredible games on sale for iPhone and iPad right now. Seriously, you could buy anything on this list and I... | Read more »
Everything You Need to Know About The Fo...
In just over a week, Epic Games has made a flurry of announcements. First, they revealed that Fortnite—their ultra-popular PUBG competitor—is coming to mobile. This was followed by brief sign-up period for interested beta testers before sending out... | Read more »
The best games that came out for iPhone...
It's not been the best week for games on the App Store. There are a few decent ones here and there, but nothing that's really going to make you throw down what you're doing and run to the nearest WiFi hotspot in order to download it. That's not to... | Read more »
Death Coming (Games)
Death Coming Device: iOS Universal Category: Games Price: $1.99, Version: (iTunes) Description: --- Background Story ---You Died. Pure and simple, but death was not the end. You have become an agent of Death: a... | Read more »

Price Scanner via

Use your Education discount this weekend to b...
Purchase a new Mac using Apple’s Education discount, and take up to $400 off MSRP. All teachers, students, and staff of any educational institution with a .edu email address qualify for the discount... Read more
15″ 2.2GHz MacBook Pro, certified refurbished...
Apple has Certified Refurbished 15″ 2.2GHz Retina MacBook Pros available for $1699. That’s $300 off MSRP for this model, and it’s the lowest price available for a 15″ MacBook Pro currently offered by... Read more
Clearance 2016 15″ MacBook Pros, certified re...
Apple has Certified Refurbished 2016 15″ Touch Bar MacBook Pros available starting at $1849, up to $690 off original MSRP. An Apple one-year warranty is included with each model, and shipping is free... Read more
Apple restocks clearance 2016 13-inch MacBook...
Apple has Certified Refurbished 2016 13″ MacBook Airs available starting at $809. An Apple one-year warranty is included with each MacBook, and shipping is free: – 13″ 1.6GHz/8GB/128GB MacBook Air: $... Read more
Thursday roundup of the best 13″ MacBook Pro...
B&H Photo has new 2017 13″ MacBook Pros on sale for up to $200 off MSRP. Shipping is free, and B&H charges sales tax for NY & NJ residents only. Their prices are the lowest available for... Read more
Sale: 9.7-inch 2017 WiFi iPads starting at $2...
B&H Photo has 9.7″ 2017 WiFi Apple iPads on sale for $40 off MSRP for a limited time. Shipping is free, and pay sales tax in NY & NJ only: – 32GB iPad WiFi: $289, $40 off – 128GB iPad WiFi: $... Read more
Roundup of Certified Refurbished iPads, iPad...
Apple has Certified Refurbished 9.7″ WiFi iPads available for $50-$80 off the cost of new models. An Apple one-year warranty is included with each iPad, and shipping is free: – 9″ 32GB WiFi iPad: $... Read more
Back in stock! Apple’s full line of Certified...
Save $300-$300 on the purchase of a 2017 13″ MacBook Pro today with Certified Refurbished models at Apple. Apple’s refurbished prices are the lowest available for each model from any reseller. A... Read more
Wednesday deals: Huge sale on Apple 15″ MacBo...
Adorama has new 2017 15″ MacBook Pros on sale for $250-$300 off MSRP. Shipping is free, and Adorama charges sales tax in NJ and NY only: – 15″ 2.8GHz Touch Bar MacBook Pro Space Gray (MPTR2LL/A): $... Read more
Apple offers Certified Refurbished Series 3 A...
Apple has Certified Refurbished Series 3 Apple Watch GPS models available for $50, or 13%, off the cost of new models. Apple’s standard 1-year warranty is included, and shipping is free. Numerous... Read more

Jobs Board

*Apple* Solution Consultant - Apple (United...
# Apple Solution Consultant Job Number: 113569564 Williston, Vermont, United States Posted: 06-Mar-2018 Weekly Hours: 40.00 **Job Summary** Are you passionate about Read more
Lead *Apple* Solution Consultant - Apple (U...
# Lead Apple Solution Consultant New York NY Job Number: 113587309 New York City, New York, United States Posted: 13-Mar-2018 Weekly Hours: 40.00 **Job Summary** As Read more
*Apple* Inc. Is Look For *Apple* Genius Te...
Apple Inc. Is Look For Apple Genius Technical Customer Service New York Ny In New York - Apple , Inc. Apple Genius Technical Customer Service New York Ny Read more
*Apple* Geniustechnical Customer Service Alt...
Apple Geniustechnical Customer Service Altamonte Springs Fl Apple Inc. - Apple , Inc. Apple Geniustechnical Customer Service Altamonte Springs Fl - Read more
*Apple* Inc. Is Look For *Apple* Genius Te...
Apple Inc. Is Look For Apple Genius Technical Customer Service Miami Fl In Miami - Apple , Inc. Apple Genius Technical Customer Service Miami Fl - Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.