Obsolete:Contributions:BCI2000Automation - Revision history

Mellinger: Mellinger moved page Contributions:BCI2000Automation to Obsolete:Contributions:BCI2000Automation

2025-06-19T20:41:09Z

Mellinger moved page Contributions:BCI2000Automation to Obsolete:Contributions:BCI2000Automation

← Older revision		Revision as of 20:41, 19 June 2025
(No difference)

Mellinger: /* Visual Basic */

2023-03-31T16:07:43Z

Visual Basic

← Older revision		Revision as of 16:07, 31 March 2023
Line 205:		Line 205:
	bci.delete;		bci.delete;

	===Visual Basic===		===Visual Basic .NET (not Visual Basic for Applications)===
	Before running the following example, you need to add the BCI2000Automation object library to your VB project's references (Project->References).		Before running the following example, you need to add the BCI2000Automation object library to your VB project's references (Project->References).
	' Instantiate a BCI2000Remote object		' Instantiate a BCI2000Remote object
Line 250:		Line 250:
	' Release and delete the BCI2000Remote object		' Release and delete the BCI2000Remote object
	Set bci = Nothing		Set bci = Nothing



	==See also==		==See also==

Mellinger: /* Running a 32 bit version on a 64 bit system */

2023-03-31T11:03:45Z

Running a 32 bit version on a 64 bit system

← Older revision		Revision as of 11:03, 31 March 2023
Line 148:		Line 148:

	===Running a 32 bit version on a 64 bit system===		===Running a 32 bit version on a 64 bit system===
	Using BCI2000Automation with a 32 bit client requires a 32 bit version ~~of BCI2000PresentationLink~~.dll, and execution of the 32 bit version of the regsvr32 program inside the SysWOW64 directory:		Using BCI2000Automation with a 32 bit client requires a 32 bit version BCI2000Automation32.dll, and execution of the 32 bit version of the regsvr32 program inside the SysWOW64 directory:
	%SystemRoot%\SysWOW64\regsvr32 /n /i:<option> ~~BCI2000Automation~~.dll		%SystemRoot%\SysWOW64\regsvr32 /n /i:<option> BCI2000Automation32.dll
	Note that the 32 and 64 bit registration processes are completely independent on a 64 bit system, and transparent for each other.		Note that the 32 and 64 bit registration processes are completely independent on a 64 bit system, and transparent for each other.

Mellinger: /* 32 vs 64 bit systems */

2023-03-31T11:02:54Z

32 vs 64 bit systems

← Older revision		Revision as of 11:02, 31 March 2023
Line 144:		Line 144:

	===32 vs 64 bit systems===		===32 vs 64 bit systems===
	When compiling BCI2000Automation in 64 bit mode, the resulting DLL is called ~~BCI2000Automation64~~.dll and must be named		When compiling BCI2000Automation in 32 bit mode, the resulting DLL is called BCI2000Automation32.dll and must be named
	as such in the commands above.		as such in the commands above.

Mellinger: /* Installation options */

2023-03-31T11:02:29Z

Installation options

← Older revision		Revision as of 11:02, 31 March 2023
Line 131:		Line 131:
	===Installation options===		===Installation options===
	BCI2000Automation may be installed or deinstalled for all users of a machine, or only for the user who runs the installation script. Selection between the two is done automatically, by determining whether the user has administrator rights. If so, installation is performed per-machine; if not, installation is done per-user. To manually choose the type of installation, you will need to execute the following command from the command prompt, inside the BCI2000/prog directory:		BCI2000Automation may be installed or deinstalled for all users of a machine, or only for the user who runs the installation script. Selection between the two is done automatically, by determining whether the user has administrator rights. If so, installation is performed per-machine; if not, installation is done per-user. To manually choose the type of installation, you will need to execute the following command from the command prompt, inside the BCI2000/prog directory:
	regsvr32 /n /i:<option> ~~BCI2000Automation~~.dll		regsvr32 /n /i:<option> BCI2000Automation64.dll
			(or BCI2000Automation32 for a 32-bit installation).
	There, <option> may be one of the following:		There, <option> may be one of the following:
	*''user'' to install for the current user only,		*''user'' to install for the current user only,
Line 138:		Line 139:
	*''both'' to install both for all users, and the current user (this option only makes sense for deinstallation).		*''both'' to install both for all users, and the current user (this option only makes sense for deinstallation).
	Note that per-user installation overrides system-wide installation. This may lead to confusing behavior of BCI2000Automation when switching between multiple users, and executing the installation program for those users, or when granting a certain user administrative privileges at one time, and later removing those privileges. To completely remove all references to BCI2000Automation from your machine under such circumstances, execute		Note that per-user installation overrides system-wide installation. This may lead to confusing behavior of BCI2000Automation when switching between multiple users, and executing the installation program for those users, or when granting a certain user administrative privileges at one time, and later removing those privileges. To completely remove all references to BCI2000Automation from your machine under such circumstances, execute
	regsvr32 /n /u /s /i:both ~~BCI2000Automation~~.dll		regsvr32 /n /u /s /i:both BCI2000Automation64.dll
			(or BCI2000Automation32 for a 32-bit installation)
	under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.		under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.

Mellinger: /* Functional Description */

2021-08-24T16:11:48Z

Functional Description

← Older revision		Revision as of 16:11, 24 August 2021
Line 33:		Line 33:
	Alternatively, you may specify the path to a BCI2000 batch file in the BCI2000/batch directory. An appropriate batch file should start up Operator and core modules, and needs to forward its command line arguments to the Operator module. All batch files coming with BCI2000 fulfil this condition. When a batch file is specified, there is no need to call the StartupModules() method.		Alternatively, you may specify the path to a BCI2000 batch file in the BCI2000/batch directory. An appropriate batch file should start up Operator and core modules, and needs to forward its command line arguments to the Operator module. All batch files coming with BCI2000 fulfil this condition. When a batch file is specified, there is no need to call the StartupModules() method.

	As yet another option, you may connect to an Operator module that is already running, e.g., on a remote machine on the network. In this case, set the BCI2000Remote object's OperatorPath property to an empty string, and its TelnetAddress property to the address that the remote Operator module is listening on, i.e. the remote machine's IP address, followed with a colon, and the port specified when starting up the remote Operator module. The remote Operator module must have been started with the --Telnet command line option, followed with the address to listen on. On the remote machine, this would typically be "~~localhost~~:3999". Don't use any of the ports between 4000 and 4002, as this will interfere with the communication between the Operator module, and BCI2000 core modules. Depending on whether the remote Operator module has been started up together with its core modules, or not, you may then call the StartupModules() method in order to start up BCI2000 core modules on the remote machine.		As yet another option, you may connect to an Operator module that is already running, e.g., on a remote machine on the network. In this case, set the BCI2000Remote object's OperatorPath property to an empty string, and its TelnetAddress property to the address that the remote Operator module is listening on, i.e. the remote machine's IP address, followed with a colon, and the port specified when starting up the remote Operator module. The remote Operator module must have been started with the --Telnet command line option, followed with the address to listen on. On the remote machine, this would typically be "<machine'ip>:3999". Don't use any of the ports between 4000 and 4002, as this will interfere with the communication between the Operator module, and BCI2000 core modules. Depending on whether the remote Operator module has been started up together with its core modules, or not, you may then call the StartupModules() method in order to start up BCI2000 core modules on the remote machine.

	Once all BCI2000 modules are running, you may load parameter files locally or remotely using the LoadParametersLocal() and LoadParametersRemote() methods. Subject ID, Session ID, and data directory are set using the respective BCI2000Remote properties.		Once all BCI2000 modules are running, you may load parameter files locally or remotely using the LoadParametersLocal() and LoadParametersRemote() methods. Subject ID, Session ID, and data directory are set using the respective BCI2000Remote properties.
Line 41:		Line 41:
	To run BCI2000 in a different configuration (i.e., with different core modules), it is not necessary to terminate the Operator module. Rather, you may execute StartupModules() multiple times in order to terminate currently running core modules, and start different ones.		To run BCI2000 in a different configuration (i.e., with different core modules), it is not necessary to terminate the Operator module. Rather, you may execute StartupModules() multiple times in order to terminate currently running core modules, and start different ones.

	Once you are done using BCI2000, you may close the connection by calling the Disconnect() method, or by deleting the BCI2000Remote interface. Depending on whether the Operator module was started up by the ~~previous~~ Connect() call, this will terminate the Operator module as well. When connection was made to an already running Operator module, local or remote, the connection will be closed but the Operator module will remain running.		Once you are done using BCI2000, you may close the connection by calling the Disconnect() method, or by deleting the BCI2000Remote interface. Depending on whether the Operator module was started up by the initial Connect() call, this will terminate the Operator module as well. When connection was made to an already running Operator module, local or remote, the connection will be closed but the Operator module will remain running.

	===BCI2000Remote Members===		===BCI2000Remote Members===

Mellinger: /* Troubleshooting */

2021-08-24T16:01:55Z

Troubleshooting

← Older revision		Revision as of 16:01, 24 August 2021
Line 140:		Line 140:
	regsvr32 /n /u /s /i:both BCI2000Automation.dll		regsvr32 /n /u /s /i:both BCI2000Automation.dll
	under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.		under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.

			===32 vs 64 bit systems===
			When compiling BCI2000Automation in 64 bit mode, the resulting DLL is called BCI2000Automation64.dll and must be named
			as such in the commands above.

			===Running a 32 bit version on a 64 bit system===
			Using BCI2000Automation with a 32 bit client requires a 32 bit version of BCI2000PresentationLink.dll, and execution of the 32 bit version of the regsvr32 program inside the SysWOW64 directory:
			%SystemRoot%\SysWOW64\regsvr32 /n /i:<option> BCI2000Automation.dll
			Note that the 32 and 64 bit registration processes are completely independent on a 64 bit system, and transparent for each other.

	===Troubleshooting===		===Troubleshooting===

Mellinger: /* Installation options */

2021-08-24T15:57:49Z

Installation options

← Older revision		Revision as of 15:57, 24 August 2021
Line 138:		Line 138:
	*''both'' to install both for all users, and the current user (this option only makes sense for deinstallation).		*''both'' to install both for all users, and the current user (this option only makes sense for deinstallation).
	Note that per-user installation overrides system-wide installation. This may lead to confusing behavior of BCI2000Automation when switching between multiple users, and executing the installation program for those users, or when granting a certain user administrative privileges at one time, and later removing those privileges. To completely remove all references to BCI2000Automation from your machine under such circumstances, execute		Note that per-user installation overrides system-wide installation. This may lead to confusing behavior of BCI2000Automation when switching between multiple users, and executing the installation program for those users, or when granting a certain user administrative privileges at one time, and later removing those privileges. To completely remove all references to BCI2000Automation from your machine under such circumstances, execute
	~~rgsvr32~~ /n /u /s /i:both BCI2000Automation.dll		regsvr32 /n /u /s /i:both BCI2000Automation.dll
	under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.		under all user accounts that may have executed the installation script, and make sure that at least one of those accounts has administrative privileges.

	===Troubleshooting===		===Troubleshooting===
	If BCI2000Automation does not work as expected, execute BCI2000/prog/InstallAutomation under the user account that is going to run your automation client.		If BCI2000Automation does not work as expected, execute BCI2000/prog/InstallAutomation under the user account that is going to run your automation client.

Mellinger: /* Synopsis */

2013-05-09T18:55:49Z

Synopsis

← Older revision		Revision as of 18:55, 9 May 2013
Line 1:		Line 1:
	==Synopsis==		==Synopsis==
	BCI2000Automation is a Windows scripting interface to the BCI2000 Operator. It allows remote control of BCI2000 from any environment that provides access to Windows automation components. These environments comprise ~~MATLAB,~~ VisualBasic, C#, and ~~others. It wraps up~~ the ~~functionality of the [[Programming Reference:BCI2000Remote Class\|BCI2000Remote]] C++ class. When writing C++ code~~, ~~you should consider using that class directly rather than BCI2000Automation~~.		BCI2000Automation is a Windows scripting interface to the BCI2000 Operator. It wraps up the functionality of the [[Programming Reference:BCI2000Remote Class\|BCI2000Remote]] C++ class. It allows remote control of BCI2000 from any environment that provides access to Windows automation components. These environments comprise .NET languages such as VisualBasic and C#, but also Windows-specific scripting languages such as VBScript and JScript, which may run in the Windows Scripting Host environment, or within Microsoft Internet Explorer.

			Multi-platform programming languages/environments such as C++, Python, or MATLAB often allow interfacing with Windows automation components when run on Windows systems. In these cases, using BCI2000Automation is discouraged, as it will not provide any benefit over the platform-independent means available to interface with BCI2000, but it will make it impossible for your developed application to run on non-Windows systems.

	Before you can use it, BCI2000Automation must be installed on your system. This is possible even if your user account has no administrative privileges. For details, see the [[#Installation\|Installation]] section below.		Before you can use it, BCI2000Automation must be installed on your system. This is possible even if your user account has no administrative privileges. For details, see the [[#Installation\|Installation]] section below.

			===C++ note===
			When writing C++ code, you should consider using the [[Programming Reference:BCI2000Remote Class\|BCI2000Remote]] class directly rather than BCI2000Automation. Detailed information on how to use the BCI2000Remote class in a C++ project may be found at [[Programming Reference:BCI2000Remote Class#Dependencies]].

			===MATLAB note===
			MATLAB is able to interface with dynamic libraries (.dll, .so, .dylib) if a header file is available (http://www.mathworks.com/help/matlab/using-c-shared-library-functions-in-matlab-.html). Thus, you may use the [[Programming Reference:BCI2000Remote Class#BCI2000RemoteLib\|BCI2000RemoteLib]] library from within MATLAB, by specifying <tt>src/core/Operator/BCI2000Remote/BCI2000RemoteLib.h</tt> as header file when calling MATLAB's <tt>loadlibrary</tt> function. When using BCI2000RemoteLib this way, your MATLAB code will run on all platforms supported by BCI2000, and no COM registration will be required on Windows systems.

			If you still decide to use MATLAB's ability to interface with Windows automation components, you may run into problems when trying to use BCI2000Automation functions that have additional output arguments (declared as ''ByRef''). MATLAB syntax prescribes that output arguments are listed to the left of an assignment, and that input arguments are listed in the argument list of a function. Thus, for ''ByRef'' arguments to automation functions, an initial value must appear to the right, and a variable to hold the final value must appear to the left of the assignment, as in:
			[success, value] = bci.GetParameter( 'MyParameter', 'ignored' );

	==Location==		==Location==

Mellinger: /* int Execute( string command ) */

2013-03-10T13:50:17Z

int Execute( string command )

← Older revision		Revision as of 13:50, 10 March 2013
Line 96:		Line 96:

	====Scripting methods====		====Scripting methods====
	=====~~int~~ Execute( string command )=====		=====bool Execute( string command, [variant exitCode] )=====
	Execute an arbitrary BCI2000 scripting command. ~~The meaning of its~~ return value ~~depends on which~~ command ~~has been executed~~, so it ~~is necessary to be aware of a command's possible responses.~~		Execute an arbitrary BCI2000 scripting command. A return value of "true" does not indicate successful execution of the command; rather, it indicates that the command was sent, and its result was received. In general, the '''Result''' property needs to be examined in order to determine whether the command was executed successfully.
	~~In detail, Execute()'s return value is determined as follows:~~
	* When Execute() is used to execute a SYSTEM command, its return value will match the exit code of the program that ~~was run through~~ the ~~SYSTEM~~ command~~. By convention, such exit codes are nonzero on failure~~, and ~~zero on success~~.
	* For other commands, ~~some interpretation of~~ the ~~command response takes place.~~
	** If the command'~~s response may be interpreted as a single floating point number, the Execute() method will return 0 for a nonzero number, and 1 if the number is zero.~~
	** If the command'~~s response is literal "true" or "false" (without considering case), the exit code will be 0 for "true", and 1 for "false".~~
	** If the command'~~s response is empty, Execute() will return 0.~~
	* If the command'~~s response is not empty, Execute() will return -2~~ to ~~indicate that the result could not~~ be ~~interpreted~~ in ~~an obvious manner.~~
	* If a communication error occurs, the ~~exit code will be -1~~.

	~~This scheme~~ is ~~chosen to simplify client code for the most common cases~~:		Documentation of BCI2000 Operator scripting commands is available under [[User Reference:Operator Module Scripting]].
	* external programs run through the SYSTEM command,
	* commands which do not have an output except in case of failure,
	* functions returning binary values, such as the test command,
	* expressions evaluated as logical conditions.
	~~In all these cases Execute() will return 0 on success, and 1 on failure.~~
	~~When executing a command that may return an arbitrary string (e.g., EXECUTE SCRIPT, or ECHO), either of 0, 1 and -2 should be treated as indicating successful execution~~.

	~~A full documentation~~ of ~~BCI2000 Operator scripting commands is available under~~ [[~~User Reference~~:~~Operator Module Scripting~~]].		Optionally, a variable of type ''variant'' may be specified as a second argument. This variable will receive the command's exit code, as described in the [[Programming_Reference:BCI2000Remote_Class#bool_Execute.28_string_command.2C_int.2A_exitCode_.3D_0_.29\|BCI2000Remote Class Document]].
			Note that the ''exitCode'' variable must be declared as being of type ''variant'' in order to receive the exit code. For other types, such as ''int'', the call may appear to succeed, but no value will be written into the variable.

	=====bool SetScript( string event, string commands )=====		=====bool SetScript( string event, string commands )=====