Introduction

With the release of version 3.0, Rhino introduced support to ActiveX Automation. Using Rhino 3.0, it was possible to control, or automate, Rhino from an external application written in a language that supported COM, such as Microsoft Visual Basic.

The Rhino 3.0 implementation was not without shortcomings. If a copy of Rhino 3.0 was already running, it was not possible to create new instances of the Application object using CreateObject (VB) or CreateDispatch (C++). For developers writing utilities that were intended to hook onto a running copy of Rhino, this was more of a feature than a problem. But, for developers using Rhino as an “invisible” file conversion engine, this could be problematic. Especially if Rhino was already running and had a model opened for editing.

Rhino4.Application

In Rhino 4.0, we have changed what happens when you create the Application object (Rhino4.Application). When automating Rhino 3.0, when you created the Application object, if an instance of Rhino was already running, you were given a reference to this existing object. According to Microsoft, this is incorrect behavior for applications that only process a single document at a time. Now, when you automate Rhino 4.0, creating the Application object will always result in a new running instance of Rhino.

 Dim objRhino As Object
 Set objRhino = CreateObject(“Rhino4.Application")

Rhino4.Interface

For those developers who want to hook onto a running instance of Rhino, the new Application object behavior found in Rhino 4.0 is going to cause problems. Thus, we have added a new Interface object (Rhino4.Interface) that works like Rhino 3.0’s Application object. When you create the Interface object, if an instance of Rhino is already running, you will be given a reference to this existing Interface object. If Rhino is not running, it will be launched and you be given a reference to this newly created object.

 Dim objRhino As Object
 Set objRhino = CreateObject(“Rhino4.Interface")

What To Use?

If you are planning on writing an application that will automate Rhino 4.0, you will have to decide which automation object to use.

• If your application will be using Rhino as a file conversion engine or to create geometry without displaying the interface, you will want to use Rhino's Application object.
• If your application must always create a new running instance of Rhino, then you will want to use Rhino's Application object.
• If your application contains tools to automate tasks or to assist the Rhino user in generating geometry, then you will want to use Rhino's Interface object.

Connecting to RhinoScript

Like Rhino 3.0, the RhinoScript object for Rhino 4.0 resides in a plug-in (DLL). Having the RhinoScript object reside in a plug-in allows us to fix bug and add additional features between Rhino releases.

But, this flexibility can also cause some problems when trying to get this object from an automation-aware application. As is often the case, by the time your application has created the Automation (or Interface) object and is ready to ask that object for RhinoScript, Rhino has not had sufficent time to load the RhinoScript plug-in. Thus, you get a runtime error.

The solution to this problem is to make your application to wait, after creating the Application (or Interface) object, before attempting to get RhinoScript. This delay can be performed by using the Win32 API Sleep() function. For example:

 [GLOBAL.BAS]
 Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)


 [TESTFORM.FRM]
 Private Sub Form_Load()


   ' Create Application or Interface object
   On Error Resume Next
   ‘Set objRhino = CreateObject("Rhino4.Interface")
   Set objRhino = CreateObject("Rhino4.Application")
   If (Err.Number <> 0) Then
     MsgBox “Failed to create Rhino4 object”
     Exit Sub
   End If


   ' Make attempts to get RhinoScript.
   ' Sleep between each attempt.
   Dim nCount As Integer
   nCount = 0
   Do While (nCount < 10)
     On Error Resume Next
     Set objRhinoScript = objRhino.GetScriptObject()
     If Err.Number <> 0 Then
       Err.Clear
       Sleep 500
       nCount = nCount + 1
     Else
       Exit Do
     End If
   Loop


   If (objRhinoScript Is Nothing) Then
     MsgBox “Failed to get RhinoScript”
   End If


 End Sub

Schemes

Rhino Schemes are different sets of Rhino Options that are stored in the Windows Registry. Everything in the Options section of Rhino can be stored in a scheme. In this way, Rhino can be started with different combinations of workspaces, languages, colors, etc. depending on the need or the user, just by starting Rhino from the appropriate desktop shortcut. The schemes exist independently of each other, and can be modified as desired.

If Rhino is launched via ActiveX automation, there is no way to specify an alternate scheme (being that you cannot pass command line arguments when creating COM objects). But, we have provided a super-sneaky registry key that you can use to specify an alternate scheme. Note, this registry key only works if Rhino is launched via ActiveX automation. The super-sneaky registry key is:

  HKEY_CURRENT_USER\Software\McNeel\Rhinoceros\4.0\Global Options\Automation
  Name: Scheme
  Type: REG_SZ
  Value: <scheme_name>