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.
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")
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")
If you are planning on writing an application that will automate Rhino 4.0, you will have to decide which automation object to use.
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") 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 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
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>