GetBusContext

What this function tells you

GetBusContext returns the bus context currently associated with the CAPL block. This matters when a configuration contains several buses or several instances of a node-layer module: a function call that looks identical in the source may operate on a different bus depending on the active context.

Treat the returned value as a context handle. Do not assume it is the same thing as a CAN channel number, a database message ID or a value that will remain meaningful after you change the configuration.

Syntax and result

dword GetBusContext();

There are no parameters. The result describes the context at the point where the call runs. It does not change that context, resolve a bus name, transmit a frame or bring a controller online.

Choose the right operation

In a node-layer callback, inspect the context inside that callback. A value logged from a separate keyboard event describes the keyboard handler's context, not necessarily the context of the callback you are investigating.

Diagnostic example

This small simulation-node example logs the current context when you press c. It is an inspection aid, not a test of which physical channel received a frame. The example has not been compiled in your CANoe configuration; check the API in your installed version before use.

on key 'c'
{
  dword activeContext;
  activeContext = GetBusContext();
  write("Current CAPL bus context: %u", activeContext);
}

For a multi-bus problem, place equivalent logging immediately before the context-dependent call and at the entry of the relevant callback. Record the bus names in Simulation Setup alongside the values. This gives you evidence about the execution path instead of relying on a number printed at an unrelated point in the program.

A useful check when switching contexts

Save the original context before switching to another bus. After the operation, restore it and compare GetBusContext() with the saved value. If the values differ, inspect early returns and branches between the switch and restoration. The SetBusContext example shows this pattern.

For a test module, do not assume a value captured during simulation startup survives test-module initialization. The supplied reference notes that test-module global variables are cleared at module start; obtain the needed context in the module's initialization flow, such as Main(), before using it.

Source and validation boundary

API behavior is based on the Vector GetBusContext reference reproduced under the site's authorization. The comparisons and diagnostic workflow above are explanatory guidance. See sources and permissions. No execution result is claimed for the example.