| **Navigation:**  [[introduction.htm|Language Reference]] > 9 -  Window and Report Attributes > Window and Report Attributes >====== CREATE (create OLE control object) ====== | [[compatibility  set ole control compatibility .htm|{{btn_prev_n.gif|Previous page}}]][[introduction.htm|{{btn_home_n.gif|Return to chapter overview}}]][[cursor  set mouse cursor type .htm|{{btn_next_n.gif|Next page}}]] |
|  ||

{{newc7.jpg|NewC7.jpg}}

**CREATE( **//server//** **[, //object// ]** )**

{{blk2blue.jpg|blk2blue.jpg}}

| **CREATE** | Specifies creating a new object for the OLE control. |
| //server// | A string constant containing the name of an OLE Server application, as it appears in the operating system's registry. |
| //object// | A string constant containing the name of the OLE Compound Storage file and the object within it to open. |

The **CREATE** attribute (PROP:CREATE, write-only) specifies the OLE control creates a new OLE or .OCX object. The //server// value is the object name as it appears in the Operating System's Registry Settings (in Win95, this information is available in REGEDIT.EXE under HKEY_CLASSES_ROOT, or in the Microsoft System Information program that comes with Microsoft Office--MSINFO32.EXE).

When the //object// parameter is present, CREATE operates just as the OPEN attribute does, opening the saved //object// for the OLE control from an OLE Compound Storage file (and ignoring the //server// parameter). When the object is opened, the saved version of the container properties are re-loaded, so properties do not need to be specified on an object opened. The //object// parameter syntax must take the form: //Filename\!ObjectName//.

**Considerations when working with OLE objects**

There are several potential problems if you CREATE an OLE control in the window for one thread and attempt to work with it from a different thread. This is because the Windows Operating System can load additional DLLs into process memory on creation of an OLE object. This creates several potential problems:

·The initialization code for the OLE control can be executed in the context of the current thread and the initialized data would not be available for the control when it is running in the thread of its host window.

·Extra DLLs can be unloaded from the process memory after closing the thread that created the OLE control, so the Virtual Memory Tables of interfaces used by the OLE control will point to deallocated memory.

As a result, //it's impossible to guarantee correct operation of OLE controls if they are created//

//in a window other than the current thread.//

**Example:**

**WinOne WINDOW,AT(0,0,200,200)**

**        OLE,AT(10,10,160,100),USE(?OLEObject),****CREATE****('Excel.Sheet.5')**

**        END**

**       END**