 | Managing IVI-C Driver Functionality |
When IVI-C wrapper generation is enabled on the IVI-C Page of the Driver Settings Editor, Nimbus creates a complete IVI-C driver that is based on functionality in the underlying IVI-COM core driver. This topic introduces important concepts in understanding how the IVI-C driver functionality is defined and managed.
 Important |
|---|
This topic only applies to IVI-COM driver projects that have enabled IVI-C wrapper generation on the IVI-C Page of the Driver Settings Editor. |
The IVI-COM and IVI-C DesignersThe Nimbus user interface offers two independent views of the functionality in a driver project -- one for the hierarchy of IVI-COM methods and properties and another for the hierarchy of IVI-C functions and attributes. Both designers are accessed by double-clicking the Driver Designer node under the Nimbus node in Solution Explorer. The Driver Designer that appears as a tabbed document window displays separate tabs for the IVI-COM Designer and the IVI-C Designer.
 Tip |
|---|
The terminology used to describe IVI-C driver functionality is slightly different than that used to describe IVI-COM functionality. A method in IVI-COM is referred to as a function when speaking in the context of IVI-C. Similarly, a property in IVI-COM corresponds to an attribute in IVI-C. This terminology is used throughout the IVI specifications and is followed in this documentation as much as possible. |
The IVI-COM Designer is referred to as the master view because it "pushes" changes made in it to the IVI-C hierarchy. For instance, when a method is added to the IVI-COM driver, a corresponding IVI-C function is also added to the driver project. Nimbus maintains the association between the IVI-COM method and the IVI-C function so that it can automatically generate the appropriate code to implement the IVI-C function in terms of the IVI-COM method.
When Nimbus automatically creates IVI-C items, such as IVI-C functions, attributes, and parameters, based on changes made in the IVI-COM Designer, various "transforms" may be required, such as translating IVI-COM data types like long and double to IVI-C data types like ViInt32 and ViReal64. The topic Linking IVI-COM and IVI-C Methods and Properties provides details on these automatic transforms.
Using the IVI-C Designer
It is critical to understand the difference in behavior when working from the IVI-COM Designer versus the IVI-C Designer. Since the IVI-COM Designer is the master view, changes made there typically affect both the IVI-COM and IVI-C hierarchies. By contrast, editing the IVI-C driver via the IVI-C Designer only affects the IVI-C hierarchy.
| Important |
|---|
The IVI-C Designer does not push changes to the IVI-COM hierarchy. |
As an example, using the IVI-C Designer renaming an IVI-C function from Configure to ConfigureTrigger will only rename the IVI-C function. The IVI-COM method will still be named Configure and the IVI-COM method and IVI-C function will still be linked with one another. Similarly, adding a function using the IVI-C Designer only adds the function to the IVI-C hierarchy -- a corresponding method is NOT added to the IVI-COM hierarchy. In fact, this is how IVI-C-only functions are created. IVI-C-only functions are discussed below.
Some changes made in the IVI-C Designer can be accommodated while maintaining the association between the IVI-COM item and the IVI-C item. The example of renaming a Configure function is one such situation. Another example is changing an IVI-C data type to a compatible type -- such as changing a parameter type from ViInt16 to ViInt32. Other changes, however, cannot be performed while the IVI-COM and IVI-C items are linked. For instance, if a function parameter data type is changed from ViReal64 to ViString, then there is no way to maintain the association between the IVI-C function and the IVI-COM method because Nimbus has no way to determine how the IVI-C function should be implemented in terms of the IVI-COM method. In such circumstances, Nimbus requires that the IVI-C function and IVI-COM method be unlinked from one another -- thereby creating an IVI-COM-only method and an IVI-C-only function that must be managed separately. The topic Linking IVI-COM and IVI-C Methods and Properties explains how IVI-C items can be unlinked and how IVI-C-only functions are implemented.
Navigating Between the IVI-COM and IVI-C Hierarchies
Nimbus offers two convenient ways to navigate between items in the IVI-COM hierarchy and their linked items in the IVI-C hierarchy:
From the tree view, right-click the desired item, such as an IVI-COM method, and choose Go to IVI-C .... The IVI-C Designer is immediately opened and linked item is selected. Correspondingly, a Go to IVI-COM... context menu command is available when working in the IVI-C Designer.
The Info Panel shows the linked IVI-COM or IVI-C item name as a hyperlink. Clicking it navigates to the linked item in the alternate view.
IVI-COM-only and IVI-C-only Methods and PropertiesAs discussed above, IVI-COM methods are initially created with an linked IVI-C function. Changes made to the IVI-COM method in the IVI-COM Designer, such as adding parameters, are "pushed" to the IVI-C function so that the two items stay in sync. Most of the time, this is the desired behavior. However, there are some instances where it is not possible or desirable to expose an IVI-COM method in the IVI-C driver. Such an IVI-COM method has no linked IVI-C function and is termed and IVI-COM-only method. Correspondingly, there are occaisions where an IVI-C function serves no useful purpose in the IVI-COM hierarchy. This requires IVI-C functions that have no IVI-COM counterpart -- these are termed IVI-C-only functions.
Nimbus fully supports the ability to create IVI-COM-only methods and IVI-C-only functions. In addition, other items, such as properties, function parameters, and enums can all be exposed in one of the hierarchies and not exposed in the others. The topic Linking IVI-COM and IVI-C Methods and Properties discusses how IVI-COM-only and IVI-C-only items are created and managed.
See Also