In Manual 1 we start by showing you how to start your App from ActiveDeveloper, forming a network development session so you can script with your App in Objective-C and control it from ActiveDeveloper while it's running.
To script your App from ActiveDeveloper we will introduce you to a new ActiveDeveloper document type called the Workspace (with extension *.wsp). A Workspace is a runtime scripting Editor for native Objective-C objects. Workspaces will quickly become the main place where you grow your Objective-C code with immediate feedback whether it works or not. Then, as your code segments start to work you can move them over to your classes and methods - now with a new ActiveDeveloper confidence.
Then you will learn how to write Objective-C code snips in a Workspace to script, build and re-build your running application.
If you don't have a registered license, you will be presented with the Demo
registration screen,
press the demo button and the ActiveDeveloper Project Window will appear.
In the ActiveDeveloper Project Window you choose which Application to start a development session
with using the PopUp button on top. By Default you have two options, the ActiveAppKitExplorer and
the ActiveIBPalette:
ActiveDeveloper will start an instance of the ActiveAppKitExplorer application and form a network connection to it - make it the context for any object browsing, inspecting or coding you will perform later. The ActiveAppKitExplorer application has two info panels, where the first one is displayed when you press start.
Clicking "Start" from within ActiveDeveloper is the only way to enter into an interactive session. Launching an app linked with libActiveDeveloper.a from Finder.app or from the Xcode build panel does NOT connect to ActiveDeveloper. This allows you to have a number of apps under development in your environment that you can run both in and out of session with ActiveDeveloper. depending whether you "Start" them or launch them from Finder or Xcode.
As a newcomer to ActiveDeveloper it's important to understand that everything in an ActiveDeveloper
session happens via networking inside either one of the default apps - or later inside one of your
own applications.
To view this for yourself - use Cmd-Shift-o to open the Object Browser. You should now see the root
NSApp object inside the sessions application, and be able to browse around it's live object structure.
That's all you need to do to get started with ActiveDeveloper. You now have an object level development session with the default Cocoa app exposing all of the Cocoa classes
The advantage of using networked sessions is that, if or when you manage to kill your application under development - you won't loose all the windows you have open in ActiveDeveloper too.
In order to investigate the active instance you need a Workspace to write your code. Two workspaces are provided that contain code for you to experiment with. Dismiss the AppKitExplorer apps Info panel, return to ActiveDeveloper and open the workspace-1.wsp file in the Manual1-API-Experiments directory.
There are multiple ways to open the workspace-1.wsp file. Locate it in Finder.app and double-click, or bring up the open panel and locate the file in there, and finally the easier choice. If you want to work in concert with Xcode, open the CocoaDemos Xcode project and simply Drag the workspace-1.wsp file icon out of Xcode and drop it on the ActiveDeveloper's applications icon in your Dock.
A Workspace consists of two panes, the top import pane and the lower coding pane. The import pane allows you to import additional classes, other than those implicit in the running application. You can then refer to these imported classes in the lower coding pane. You can view the coding pane as having the context of AppKit and Foundation plus the classes you explicitly imported.
The three buttons (Eval, Display and Inspect) can be clicked when compound statements are highlighted in the coding pane.
In the following screen shots you will see the difference between these three execution models.
Before continuing, ensure that the info panel for the ActiveAppKitExplorer is closed.
Returning to the contents of Workspace-1.wsp.
When you Evaluate the first statement in the Evaluate Section, the result is that the info panel of ActiveAppKitExplorer is being shown again, as you can see below.
Note that no other action was taken by ActiveDeveloper, it simply brought your selected Objective-C statement to evaluation inside the running AppKitExplorer application.
Close the info panel and highlight the first statement again, this time click the Display button.
Again the info panel is displayed but in addition ActiveDeveloper displays the textual representation the object returned by the selected statement in the transcript tab. In this case it is the delegate for NSApp, because -showInfoPanel: returns self.
Again, close the info panel and select the first statement and this time we want to inspect the resulting object.
When we issue an inspect command we are requesting ActiveDeveloper to evaluate the statements and present us with an object inspector on the resulting Object (see image below). The inspector displays the root context, NSApp and the resulting object from the highlighted statement (one controller). We can browse the various attributes that have been instantiated. The lower view displays the textual representation of the right most selected attribute, in this case the _contentView attribute.
We can also write code in this lower pane of the Object Browser and have it evaluated, displayed or inspected. The binding of self inside the coding pane is the selected object in the browser. In the image below any code written in the lower pane would be executed by the NSView instance referenced by _contentView. We will see examples shortly.
Close the info panel and move onto the next two statements, these will present a font browser window when evaluated together. (if you don't see the Font panel appear - just activate the AppKitExplorer app)
The next statement displays what happens when ActiveDeveloper evaluates code with runtime errors. When you evaluate this snippet, nothing happens. If you display it nothing gets displayed and when you inspect it, nothing gets returned to be inspected - and ActiveDeveloper survive your errors.
When the next three statements gets displayed (individually), your Transcript pane should contain text similar to the following
The last set of statements illustrates the coding within Object browsers. Highlight the first statement in the last Inspect section of the Workspace and inspect it.
The runtime object inspector will reappear with an additional object.
We can see from the textual representation that the two elements are First and Second. Highlight the textual representation, copy and paste the following code from the webbrowser or the workspace over to the Object Browser.
[self addObject: @"Third"];
Highlight this code and evaluate it.
To allow the inspector to refresh itself, click on one NSCFArray. You should now see a third element in this array.
(If you haven't yet registrered ActiveDeveloper, please quit and restart)
Open the second workspace residing in the Manual1-API-Experiments directory.
(If you don't have a registered license key, you might want to Quit the ActiveDeveloper IDE,
restart it again and relaunch the application before moving on to the Workspace 2)
This Workspace has more examples of coding with objects, both within Workspace and within the runtime Object Browser. Highlight the first statement and inspect. The inspector should look similar to
We have created an instance of NSWindow, it doesn't appear on screen, at the moment it resides only in memory and is visible to us via the reference in the inspector. We can send messages to this instance from within the inspector, because as we seen earlier, the context of the lower coding pane, is the currently selected object in the browser. To demonstrate this, copy
[self orderFront: self];
and paste it in the lower coding pane, making sure that one NSWindow is selected and Evaluate it.
This results in a small empty window appearing on the screen
Repeating this with the second statement gives it the title - "My Window".
The next three statements need to be copied and pasted as a unit for the code to be successful. If we were to copy and paste them individually we lose the Color variable because it is a temporary variable for the duration of the execution. If you want to execute them individually, you will see compiler errors appear on the Transcript.
This does not cause any problems the context is left consistent and we can proceed as intended. After executing the three statements as a unit we see that our new window has changed color
The next sample statement positions our window at (400, 800).
We leave it as an exercise to close this window - in Objective-C coding of course.
The last set of statements can be executed within the workspace. The statements create an alert panel. Use this example to learn how to use the NSAlertPanel API.
If we inspect this code we see the alert panel appear. The inspector will appear with an instance of NSConstantString, depending on which button we pressed, this will have the value First or Second.
Using a Workspace like this - you can use ActiveDeveloper to explore all the other options of using an NSAlertPanel or all the other Cocoa API's - without having to create a new Xcode test project.
At this point we should step back and appreciate what we have just done. ActiveDeveloper provides us with the ability to inspect, query and manipulate application objects while the application is executing. It also allows via the workspace to incrementally develop and test code segments. When inspecting Objects we now have the ability (via the inspector coding pane) to send messages to those instances. These are all very powerful tools to have at our disposal during development and debugging.