Introduction
We recently had a Tech Support request from a researcher with students who use Origin for graphing and data analysis. The researcher uses OriginC to create custom functions and makes them available for his students to use. Because he frequently updates his OriginC code, he wanted a method to ensure the latest functions are available to his students with the minimal amount of effort on his part, as well as avoiding requiring his students to get involved with OriginC file management, workspace configuration, and compilation. The students don’t have to modify the files, just use the functions provided in them.
In this blog, I will describe a method that builds on the solution given to the researcher. The goal is to provide a flexible method to centralize OriginC files and workspaces on a server and make the functions they contain available to Origin running on local PCs connected to the network. It is assumed that the reader is already comfortable with OriginC and LabTalk coding, the structure of INI files, use of a plain text editor, and basic networking.
A zip file containing example files that illustrate how this method works is available here: Centralizing-OriginC-Files.zip. It is suggested that the Zip file be downloaded and decompressed, so that the files can be referenced as you read this post.
Step 1: Organizing Source Code Files
After you have created and tested your OriginC files as usual on a development PC, make sure they are removed from any existing Workspaces in Origin Code Builder on the PC.
Then, create a folder on a network drive to contain your OriginC source code files and move the files to it. The folder must be readable by all the local PCs that need access to the files. In the example Zip file, a folder entitled “Files on Server” is already provided for you to learn with- for now, you could copy those files to your server if you wished.
Next, an Origin Workspace file (OCW) must be created in the same folder on the server. An example Workspace file, “Workspace1.ocw”, is included in the “Files on Server” folder in the example Zip file. A Workspace file is essentially a plain text INI file containing a list of source code files that are grouped (in this case) for the purpose of compiling all together. For example, the contents of “Workspace1.ocw” are:
[Workspace] File1="File 1.c" File2="File 2.c" File3="File 3.c" File4="Subfolder\File 4.c" FileCount=4
In the [Workspace] section, there is 1 line per source code file. File names are enclosed in quotes and paths are relative (important!) to the location of the OCW file (e.g. File4=”Subfolder\File 4.c” above). There is also a line in the [Workspace] section for FileCount .
While an OCW file can be generated from within Code Builder, it is frankly simpler to use a plain text editor to create the file giving it an .ocw extension. Even simpler, just copy and modify the “Workspace1.ocw” provided in the “Files on Server” folder in the example Zip file. Notepad can be used to do this, but the excellent and free plain text editor Notepad++ is even better (and is well worth installing in general).
Include a line in the [Workspace] section for each source code file you want to compile using relative paths (important!) and enclosing the entire path and file name in quotes. Also make sure to modify FileCount in the [Workspace] section to reflect the number of source code files. Then save the file.
Step 2: Create LabTalk File to Compile the Source Code Files
Next, using a plain text editor (Notepad or Notepad++), create a LabTalk Script file (OGS) in the same folder as the OCW and source code files on the server. The LabTalk run.loadOC() function can be used to load the OCW file and thus compile the source code files. An example file, “Loader.ogs” is included in the “Files on Server” folder of the example Zip file. It’s contents are:
int nErr = run.loadOC("Q:\Files on Server\Workspace1.ocw", 16);
if (1 == nErr)
type -b "Server OCW file not found.";
else if (2 == nErr)
type -b "Compiling one or more server files failed.";
// else success.
run.loadOC() returns 0 upon success, 1 if the OCW file was not found, and 2 if any source code files could not be compiled. Hence the error messages for 1 & 2 . Notice that, for this case, a quoted absolute path (important!) to the OCW file must be passed into the function.
You can either create your own OGS file or modify “Loader.ogs”. Just be sure to follow the aforementioned items about absolute paths and quotes when specifying the path to your OCW file.
Hint! You can even load multiple OCW files by repeating the above code in the OGS file pointing to the different OCW files. However, it is important to not include the same source code files in multiple OCW files if you plan to load more than one.
With the OGS file created, we can move on to the next step- configuring Origin installations on local PCs to utilize the files on the server.
Step 3: Configuring Origin on Local PCs
Origin installations on local PCs can be configured to load and compile the OriginC files on the remote server. This involves two actions: Adding an “OEvents.ogs” file to the User Files Folder (UFF) and modifying the “Origin.ini” file in the UFF. These two actions need to be done only one time however.
Adding an “OEvents.ogs” File
“OEvents.ogs” is a LabTalk script that Origin optionally uses to allow users to perform various actions when events occur in Origin. A default version of the file exists in Origin’s program folder, but one has also been provided for you in the example Zip file. This file must be copied to the UFF. Then a certain [section] of the file must be edited. The example in the Zip file is:
[AfterCompileSystem]
// This event is triggered after Origin finishes startup compilation of system folder.
// Use this event for additional customization of Origin that requires Origin C functions
// that are compiled on startup.
// %1 = 1 if compilation is successful otherwise %1 = 0.
run.file("Q:\Files on Server\Loader.ogs");
The [AfterCompileSystem] section is edited to add a call to the LabTalk run.file() function, passing it the absolute path to the OGS file created in Step 2 above. Code in this section runs immediately after Origin compiles system OriginC files, so this is a good place to make the call to compile the OriginC files on the remote server. You will, of course, need to modify the path to be correct for the location of your files on the sever. Now save the file.
Editing “Origin.ini” File
After first shutting down Origin, a plain text editor (Notepad or Notepad++) can be used to edit “Origin.ini” file in the UFF. The edit consists of uncommenting one line in the file. The semi-colon ( ; ) should be removed from the line:
; Ogs1 = OEvents
as follows:
Ogs1 = OEvents ; Ogs2 = OEvents ; Origin can trigger multiple system events ; Uncomment this line and implement event handlers in OEvents.ogs
Once the edit is complete, the file can be saved.
With these two actions complete, the final step is to test the setup.
Testing the Setup
With the above steps complete, it is time to test the setup. Simply start Origin and wait a few moments for the system Originc files to compile. If all if configured correctly, the OriginC files on the server will then compile correctly as well. If you used the files supplied in the example Zip file, you could run the following code in the Script Window to see if the functions are indeed available:
test1(); test2(); test3(); test4();
The output should be:
test1() from "File 1.c" ran. test2() from "File 2.c" ran. test3() from "File 3.c" ran. test4() from "File 4.c" ran.
But It Doesn’t Work!?!?
If the setup does not appear to work, probably the number one culprit is the paths either in the “Loader.ogs” file or in “OEvents.ogs”:
- Make sure the paths are correct;
- Make sure they are properly enclosed in double-quotes;
- Sometimes paths need to use forward slashes instead of backslashes for networks. These are known as UNC paths. To see if that is necessary, look at the path to the server in Windows File Explorer.
Otherwise, problems may include that the OriginC files themselves cannot compile due to some error. However, if one tests them on a local development PC, this should not be an issue. If you cannot isolate the problem, feel free to send an email to tech@originlab.com referencing this blog post, and we can help diagnose the issue.
Conclusion
Hopefully this system will work well for you if you want such a centralized location for OriginC files. It can, of course, be modified to suit other needs or situations. There is no obligation to perform Step 3: Configuring Origin on Local PCs. You could just as easily issue the run.file(“Q:\\Files on Server\\Loader.ogs”); LabTalk command some other way.
The flexibility of the system is best illustrated by the fact that the files on the local PCs with Origin will rarely (if ever) need to be modified; only files on the server such as “Loader.ogs” or the OCW files would need to be modified.
Really, the only limitation of this method is that it relies on the client PC being connected to the server. That is, it will not work if the local PC is disconnected from the relevant network.
Thank you for taking the time to read this post!
English 
Japanese