Introduction to EON SDK - Construction IT research at VTT

Introduction to EON SDK 

Jan 2002 

© Copyright EON Reality, Inc.2002 1

Table ofContents 

Table of Contents 

User Guide 

Table of Contents 2 

Introduction 3 

Installation 4 

EON SDK Basics 6 

Wizards 20 

Techniques 30 

Introduction 37 

Nodes 38 

Classes in EON SDK 39 

Modules 41 

Interfaces 42 

Macros 60 

Index 61 

2 

EON SDK 2.53.0

User’s Guide 

Introduction 


About this Guide 

This guide is your companion in exploring EON SDK and in implementing 

your own modules and nodes. Because EON SDK incorporates C++ 

programming extensively, a working knowledge of the C++ language is 

required. 

This guide actually combines two guides in one−the User Guide and the 

Reference Guide. The User Guide describes basic features of EON SDK, 

as well as information on system requirements and installation. 

Furthermore, instructions are provided for the two EON SDK wizards. 

The Reference Guide describes the classes and functions used by EON 

SDK. 

Introduction to EON SDK 

EON SDK is a software development kit for constructing custom EON 

nodes and modules. This is the same tool used by EON Reality to create 

standard nodes and modules. EON SDK is used from within Microsoft 

Visual C++. 

EON SDK adds two wizards to Visual C++, a few base classes that 

connect your code to the EON framework, and a number of libraries. 

Certain EON nodes are referred to as agents, indicating that these 

nodes are related to actions. EON agents may initiate operations such 

as motion control and on/off functionality. (From a purely technical 

perspective, a node is considered an agent if it implements the IAgent 

interface.) However, with the present widespread use of event-passing, 

the distinction between agents and other nodes has become rather 

insignificant. From now on we will use the general term node, if not 

agent is more precise. 

EON nodes can be grouped in modules. An EON module is an independent 

program component that expands basic EON Studio functionality. A 

module may add new menu items, toolbars and views. It may also 

communicate with the nodes that make up an EON simulation or with 

other modules. The nodes of a custom module are handled by EON Studio 

in exactly the same way as EON Studio's basic nodes. Modules—and even 

individual nodes—can be license-protected with EON SDK, permitting 

third-party developers to create specialized EON Studio plug-ins. 

2.5 3

User Guide 

Installation 


Installing EON SDK 

System Requirements 

This section describes installation of EON SDK from the CD-ROM. 

Processor Memory Disk space Operating system 

Intel Pentium 75 

16 Mb 

7Mb(minimum) 

Windows 95/98 

(minimum) 

Or 

Pentium 166 MHz 

32 Mb 

10 Mb (with examples) 

Windows NT 4.0 with Service Pack 3 or 

(recommended) 

later 

The system requirements for EON SDK are the same as for EON Studio. 

Microsoft Visual C++ ® version 6.0 or later must be installed on your 

computer. 

Because new nodes are created with Visual C++ (using wizards), it is 

strongly recommended that the user has programming experience in C++ 

and is familiar with the Visual C++ integrated development 

environment. 

Program Installation 

1. Insert the EON SDK CD-ROM. If the installation program does not 

start automatically, continue with Steps 2 through 4. 

Installing DirectX SDK 

2. Choose Run… by clicking on the Start button of the Windows taskbar. 

3. Enter d:\setup in the dialog box (d: being your CD-ROM drive). 

4. Click the OK button. 

5. The installation program will now guide you through the 

installation process. 

To work with nodes that employ graphics−such as 3D objects (meshes)−you 

will need Microsoft’s DirectX SDK. DirectX is an API that gives the 

user access to system hardware. It consists of six different 

components: DirectPlay, DirectInput, Direct3DSound, DirectSound, 

Direct3D and DirectDraw. Each is capable of emulating low-level 

functions not supported by underlayer hardware. 

Note that the DirectX runtime components included on the EON Studio 

2.5 CD are not intended for development purposes. If you want to 

install the DirectX SDK on your development system, you will find the 

latest version at: 

http://www.microsoft.com/directx/default.asp 

Setting up the Visual Studio Environment 

When you work with EON SDK, it is always from within Microsoft Visual 

Studio®. You use EON wizards to create skeleton code for new nodes and 

4 


User Guide 


modules. By changing and making additions to the generated code, you 

can modify the behavior of the nodes and modules. 

Before you start building new nodes or modules, you must set up your 

development environment correctly. To do this, choose Options from 

Visual Studio’s Tool menu. Click the Directories tab. 

Figure 1. The Directories tab, Options dialog box 

This is where you add the path to the development directory, located 

in your EON SDK folder, and its subfolders (one for each file type). 

NOTE: During the EON SDK installation you could choose to set the 

paths automatically. If you did there should be a path to the EON SDK 

for each file type. Then there is no need for you to perform the 

following steps. The added paths are not removed when uninstalling EON 

SDK. 

Figure 2. The Choose Directory dialog box 

Select Include files from the Show directories for listbox and add the 

entry "Development Files\include" to the list of directories. Then 

continue to add "Development Files\lib" to Library files, "Development 

Files\source" to Source files and "Development Files\executeable" to 

Executable files. Furthermore, move each one of these directories to 

the top of its list. You thereby force Visual Studio to always search 

those specific Development directories before the others. 

Note that all four-file types must be added. 

2.5 5

User Guide 

Techniques 

EON SDK Basics 

EON 

EON is a VR development tool that is built on an architecture that is 

highly modular, extensible and versatile. Using the EON Studio 

application you can create fully interactive 3D worlds that are 

executed and rendered in real-time by the run-time viewer EON/X. The 

viewer can be embedded in various host applications such as Web 

browsers, RAD and multimedia authoring tools. 

3rd Party 

EON Modules 

EON Studio View Modules 

(Scengraph, Butterfly, etc) 

EON Studio Application Object Model 

(IAutApp, IAutDoc, IAutSettings, etc) 

EON Studio 

(windowing, inter-module messaging, license management, etc) 

NodeBag API 

(INodeBag) 

Design Mode 

EON Simulation 

Simulation Node 

Scen Node 

Run-time Mode 

Frame Node 

Custom Node 1 

Mesh Node 

Custom Node 2 

... 

NodeBag API 

(INodeBag) 

EON/X 

(ActiveX control) 

EON Studio 

(Simulation 

Window) 

Custom 

Viewer 

(Currently not 

supported by the 

SDK) 

Legend: 

= SDK creatable component 

= EON pre-defined component 

Embedded in... 

EON Viewer 

Other ActiveX control Container 

(Internet Explorer, MS Word, VisualBasic, etc) 

Figure 3. The EON architecture 

As you can see the EON system is split into two distinct modes, and 

using the SDK you can extend both parts of the system. 

By creating EON Modules, you can extend the design mode functionality, 

inside EON Studio. You can also create custom nodes to supply or 

6 


User Guide 

Wizards 

enhance functionality in run-time mode. To let the user configure 

these nodes in design mode, you have essentially three choices: 

provide custom properties dialog for each node (most common), create a 

custom module or let EON Studio takes care of it (you will get a 

standard properties list similar to Visual Basic). 

EON uses Microsoft COM extensively to interface against both internal 

and SDK-created components. Therefore, most components in EON are COM 

objects, including nodes, modules, the run-time viewer (EON/X), etc. 

Inside EON 

As a plug-in developer, you must understand the EON architecture in a 

deeper way and need to have working knowledge of C++. On the other 

hand, you will be able to utilize the power of EON in full strength 

since you will have access to the same interface and functionality 

that are used by internal components as well. 

The kernel of an EON simulation is the Scenegraph. This is the place 

where all nodes are located. EON Studio can be seen as a tool to 

configure and insert nodes into this graph (and to make connections 

between nodes so that events can be transferred from node to node). 

To access this collection of nodes, the Nodebag component is used. 

This COM object exposes an interface named INodebag, to encapsulate 

the inner structure of the collection and to let the rest of the 

system access it in a controlled way. In most cases, the plug-in 

developer would not need to deal with the Nodebag component directly, 

unless you would like to develop your own viewer or similar. 

The real-time 3D graphics is handled by the simulation node, which is 

the root node of the scenegraph. This is where the main execution loop 

lies, to traverse and activate the rest of the nodes in the scenegraph 

to form a complete simulation. This node also handles mouse and 

keyboard input, in addition to route management. A route is a 

connection between two nodes, which will permit a node to send an 

event to another one. 

Other additional input channels (trackers, etc) and visual elements 

(shapes, lights, sounds, videos, etc) are handled by specialized 

nodes, which are added when needed. This means the run-time system can 

be very lightweight and flexible but also powerful and versatile at 

the same time. 

Using this SDK you can further enhance this system by creating and 

adding your own nodes to the system. These nodes can provide totally 

new functionality or just enhance or replace the standard ones. These 

nodes are deployed and used in the same way as the standard nodes that 

are shipped with EON. Hence, these plug-in components are truly 

integrated with the system. 

2.5 7

User Guide 

Techniques 

However, the power does not come without a price. Since each node is 

actually a COM object, there is a lot of housekeeping surrounding the 

component that is required by the COM specification. To minimize the 

inconvenience, the SDK provides wizards to generate the project files 

and a code skeleton/framework, from where you can further build up 

your node/module. The framework utilizes class sub-classing and macros 

to hide implementation details, in a way very similar to MFC (the 

framework works closely and is compatible with ATL and MFC). There is 

also a library of commonly used functions to speed up the SDK 

development. 

If you are not worried about the additional work outlined above or you 

are using another C++ development tool than Visual C++, you are left 

alone to implement them yourself. However, since COM is binary 

compatible across programming language/compiler, you should be able to 

integrate your custom nodes or modules with EON this way (although it 

is not recommended). 

Nodes 

What is a node/agent 

A node is an EON Studio object with functions and data. Nodes are of 

different types and thereby contribute varying effects to a 

simulation. Certain EON nodes are referred to as agents, indicating 

that these nodes are related to actions. EON agents may perform 

operations such as motion control and on/off functionality. A Frame 

node, on the other hand, is an example of a non-agent node—its fields 

are only used to store values. Most nodes store data and manage most 

external communication using so-called "fields". Data is sent between 

nodes by connecting their respective fields with one another. 

Note that the technical definition says that an agent is a node that 

implements the IAgent COM interface. Nowadays a node can manipulate 

other nodes not only through COM interfaces but also by sending events 

between fields. Hence, the exact meaning of the term "agent" has 

become slightly blurred. We therefore prefer to use the more general 

word "node", although we will continue to write "agent" where it is 

found appropriate according to the definition mentioned above. 

Fields 

Fields used by EON nodes are of four different types: 

• eventIn fields for receiving data. 

• eventOut fields for sending data. 

• exposedField fields that can both receive and send data. 

• field fields used to store the nodes’ internal data. 

A field of one of the four types listed above can contain either one 

or several values of a particular data type. There is a limited number 

of data types to choose from, and they are grouped into single-valued 

8 


User Guide 

Wizards 

or multiple-valued types. An example of a single-valued data type is 

the SFString, which contains a single string. Its multiple-valued 

counterpart, which is called MFString, holds an array with an 

arbitrary number of elements, all of which must be strings. 

Events 

The message sent between two fields is called an event. An event sent 

from a field is called an out-event and an event received by a field, 

an in-event. 

Nodes receive data: 

• When the user enters or changes data in a node’s properties window. 

• When data is sent from a connected node in the Route Window (for 

details about how to create routes between nodes, see the EON 

Studio 2.5 User Guide). 

• From parent nodes in the simulation tree. 

• From child nodes in the simulation tree. 

• From any connected I/O devices. (Those nodes are called sensors and 

must implement the ISensor COM interface.) 

Execution model 

The event model used in EON provides several benefits: 

• A node that sends events need not be aware of the receiver’s 

identity. 

• Conversely, a node that receives events need not be aware of the 

sender’s identity. 

• Fan-out (one sender, several receivers) and fan-in (several 

senders, one receiver) are supported automatically−new nodes may be 

added as senders or receivers with no special code required to 

implement the additional communication connections. 

• Routes, which define how events are sent and received, are 

manipulated in the Route View and hence they are independent of 

nodes' positions in the simulation tree. 

• Events are passed quickly (though not as fast as function 

invocation from within the receiving node). 

• Creating a sensor node (a node that can generate events at any 

time, independent of received events) is as easy as creating a 

standard node. 

The execution cycle of an EON simulation’s real-time loop has several 

steps. 

First of all, the OnPreUpdate() function in the 

ISimulationUpdateEvents interface is invoked, followed by calls to all 

simulation nodes’ Update() functions. The call chain is initiated at 

2.5 9

User Guide 

Techniques 

root level, with the Simulation node calling its child nodes. All 

called nodes update their children recursively. 

After that, all pending events are processed. The Route Manager 

collects pending out-events from sensor nodes and queues them 

internally. It then dispatches all queued events and creates the 

appropriate in-events. New events (if any) are once again collected 

and dispatched sequentially. This procedure continues until no events 

remain. 

If two or more nodes form a cyclic graph, they may enter an infinite 

loop of event-passing. Note that such a loop will generally be 

regarded as being a mistake on the part of the user. The Route Manager 

allows loops, but will prevent more than one event from being sent 

along each route during the same collection round. If a route has 

already been "used" by an event, then the subsequent event will be 

queued until the collection round of the next simulation frame. 

Next, the OnPostUpdate() function is invoked. Each node can implement 

EventsProcessed(), a function that is called when all events have been 

processed. The function is called only if the node has received an 

event during the previous cycle. A final event collection is made 

before the simulated scene is rendered. All nodes are executed in a 

single process. Accordingly, they share memory with each other as well 

as with the rest of the EON system. This makes it possible to use 

standard function calls between nodes. EON calls functions in each 

simulation time frame. When a simulation starts, a node’s 

OnInitialize() is called. The code in the node’s Update() function is 

executed in each time frame. When an event has been received, the 

FieldChanged() function is called. If any node fields have been 

changed, the FieldChanged() function takes appropriate action. When 

the simulation stops, EON calls OnReset(). 

Another method for communication between nodes involves connection 

points. Communication is faster but the procedure is more complex. 

Why use C++ 

Standard EON nodes are written in C++, using Microsoft’s Visual C++ 

(version 5.0 and 6.0). To obtain satisfactory results, you should use 

this development environment too. Because EON Studio already provides 

the capability to create customized nodes by writing scripts in the 

Script node, you may wonder why you should bother working with C++. 

While Script nodes have the advantage of being easy to use (you can 

create and edit them within EON Studio's Script Editor), they tend to 

be slow. This is due to the interpretive nature of the scripting 

language. Nodes created with EON SDK are written in C++ and 

subsequently compiled into machine code. The additional effort 

involved in using C++ is rewarded with higher performance. 

EON SDK gives you access to the graphics API used by EON through 

Direct3D interfaces. Additionally, you can use other interfaces to 

access hardware devices such as mice and keyboards. A node created in 

10 


User Guide 

Wizards 

EON SDK can also call all standard operating system functions, for 

example, functions that create dialog boxes, change fonts and make 

Internet connections. 

Modules 

What is a module 

Seen from a purely technical point of view, any COM object that 

implements the dual interface IEonModule is an EON module. 

Why use modules 

In order to locate its modules, EON Studio investigates the Windows 

registry database. All EON modules must be able to identify themselves 

through the registry. This is automatically taken care of in the code 

skeleton generated by the Module Wizard. 

By creating modules, it is possible to extend the user interface of 

EON Studio. An EON module can add the following functionality and GUI 

features to EON Studio: 

• command handling 

• menu items 

• toolbar buttons 

• views (even so-called split views may be created) 

• nodes 

• license handling 

• custom message passing 

A registered module is loaded automatically into EON Studio when EON 

Studio starts. In the process of loading a module, EON Studio calls a 

number of module interface functions. This allows the module to check 

and report the license status, and to inform EON Studio of the 

features it implements−features such as the above mentioned commands, 

menu items and toolbars. 

Module commands can be bound to menu items and toolbar buttons. When 

the user selects the menu item or toolbar button registered by a 

module, EON Studio will call a function in the module so that the 

module can handle the command. Some default commands, such as Copy and 

Paste, will be routed to the module automatically by EON Studio 

provided that the currently active view belongs to the module. 

A module can add an almost unlimited number of views to EON Studio. 

These views appear in the EON Studio user interface. Module views look 

and behave the same as standard EON Studio views. They remember their 

position between sessions, and they can be configured as docked or 

floating. Modules are, however, responsible for the contents of its 

views. Modules accomplish this by subclassing a window handle, 

supplied by EON Studio, when a module registers a view. Furthermore, 

2.5 11

User Guide 

Techniques 

split views may be used intstead of the standard views. Split views 

incorporate splitter bars that divide a view into several panes. A 

split view can be configured to hold both multiple rows and columns of 

panes. 

A module can communicate with the EON Studio simulation. It can also 

determine which node in the simulation tree that is currently 

selected. Furthermore, it can fully exploit the interfaces provided by 

the nodes of the simulation. 

The modules will be notified when events that could possibly affect 

their behavior occur in EON Studio. Examples of such events are those 

that occur before a simulation is closed, after a simulation is 

opened, when the simulation tree has changed and when views need to 

update themselves. It is also possible for a module to change the 

content of the simulation tree, to add and delete nodes, to change 

node properties, etc. 

How to create a module 

A module can also be used to group a number of nodes into a licenseprotected 

package. The source code for license handling is provided by 

the Module Wizard when your new module is generated (though the code 

may be enclosed by comments). 

Use the EON Module Wizard from within Visual C++ to create new 

modules. The wizard provides you with ready-made code skeletons. To 

add features to a new module, just add code to the skeleton or modify 

the code that is already written. 

Loading and unloading modules 

Open the Options>Modules… configuration dialog and mark the modules 

you would like to load initially at the start of an EON Studio 

session. 

To start EON Studio without modules, either hold down one of the shift 

keys as EON Studio starts, or use the command line argument “-C” when 

starting EON Studio from a DOS command prompt or the Start>Run… 

dialog. 

EON licensing 

General 

EON 2.5 uses the FLEXlm license managing system produced by 

Globetrotter Software Inc. to manage licensing of features. A feature 

is a single program or program object, subject to licensing. The 

licensing system in EON 2.5 is based on modules, where a module is the 

smallest unit that may be protected by the license system. This means 

that an EON module is a FLEXlm feature. 

12 


User Guide 

Wizards 

Although not features themselves, nodes may be license-protected by 

using the INodeLicense interface. This interface lets your nodes check 

if a certain module is properly checked-out. For example, EON Showroom 

nodes check to see if the EON Showroom module (feature) is checkedout. 

If it is, you can make use of all EON Showroom nodes as you 

design your simulation in EON Studio. However, if there is any problem 

with the licensing, you may not fully exploit the Showroom nodes. 

Design-time licensing applies to EON Studio and the modules, i.e., to 

the files named ModuleName.DLL, but not NodeLibrary.DLL and 

PPNodeLibrary.DLL. This means that licenses will only be required 

during the EON Studio simulation design phase, and that the final 

simulation may be run on any system that has registered the modules 

used in the simulation. 

Run-time licensing using Microsoft’s COM licensing may be implemented 

in later EON versions. To make this possible, run-time and design-time 

licensing information is included in the license keys initially 

created. 

If one or more of its modules are loaded in so-called demo mode, EON 

Studio will also run in demo mode. When EON Studio is in demo mode, 

the Save and Save As… commands are disabled. Although all installed 

modules are available, it is not possible to save the new simulations 

you create. 

To prevent a checked-out license from being checked-out indefinitely, 

heartbeat messages will be exchanged between the module and the 

license server. Heartbeat messages also prevent tampering by 

restarting the license server. When a pre-defined time-out has been 

reached and the module still hasn't answered the license server calls, 

the license is automatically checked-in. 

If for same reason, the license server is not accessible from your 

computer for a longer period, EON Studio will notify you of the 

problem and ask you if you wish to save your current work before EON 

Studio makes a transition into demo mode. 

For more information on different modules and EON license handling, 

see the EON Studio manual. 

Module licensing 

As long as a module implements the license-handling interface of 

IEonModule, it is up to the user to choose an appropriate licensing 

system. Though naturally, it is strongly recommended that FLEXlm be 

used; this avoids the problem of having two separate licensing systems 

to support one application program. The FLEXlm SDK may be downloaded 

from: 

http://www.globetrotter.com/flexlm.htm 

2.5 13

User Guide 

Techniques 

FLEXlm licensing 

The FLEXlm feature name must be the same as the module identifier in 

the registry; this is automatically the case with an EON Module Wizard 

generated module. A module (feature) name must be unique, 

alphanumerical phrase. If you plan to use a licensing system other 

than FLEXlm, the same requirements apply. 

If FLEXlm is used, the IAutApp interface (see the reference guide) may 

be used to gain access to the license server through EON Studio by 

using the CheckOutFeature() function, for example. 

A license or feature always has a version number. It is important to 

know that the license version number is not the same as the program 

version number. Changing the license version number will cause all 

older license keys to expire. The recommended procedure is to keep the 

same license version number between major EON upgrades. In other 

words, EON 2.1, 2.2 and 2.5 would all use the same license version 

number, but when EON 3.0 arrives, the license version number should be 

incremented. 

Note: the version number of any feature may not exceed 10 digits 

(floating point format) due to restrictions in the current version of 

FLEXlm. 

EON Studio and modules 

In order for EON Studio to find a module and its nodes, unique 

module/node identifiers must be placed in the registry. 

EON modules are registered as follows (note that the version key, 2.0, 

is correct, since it indicates which major version EON has reached): 

HKEY_LOCAL_MACHINE \ SOFTWARE \ Prosolvia Clarus \ Clarus EON \ 

2.0 \ 

Modules \ 

The entry in the registry shall contain the following information: 

• The name of the module should be placed as the default value. 

• Whether the module is loaded or not. “0” means not loaded, “1” 

means loaded. The registry name is LOADED. 

• Whether the module is distributable or not. “0” means not 

distributable, “1” means distributable. Use the registry name 

DISTRIBUTABLE. To protect against tampering, this information is 

double-checked against the registry. 

Nodes that are part of a module register themselves as follows: 

HKEY_LOCAL_MACHINE \ SOFTWARE \ Prosolvia Clarus \ Clarus EON \ 

2.0 \ 

Modules \ \ \ 

The entry for the node shall contain: 

• The CLSID for the node. Use the registry key name CLSID. 

14 


User Guide 

Wizards 

• The name of the DLL containing the icon for the node. Use the 

registry key name IconDLL. 

• The resource ID of the Icon. Use the registry key name IconID. 

Module registration functionality is already implemented in the code 

skeleton generated by the EON Module Wizard, but if the module 

contains nodes, macros for their registration must be added to the 

module skeleton: insert OBJECT_ENTRY(, ) 

lines between the BEGIN_OBJECT_MAP() and END_OBJECT_MAP() macros in 

the .cpp file. 

The macro DECLARE_MODULE_CLSID() will use as its 

licensing unit and should be inserted in the public area of the node's 

class declaration. 

All modules must support the IEonModule interface for—among several 

other purposes—license protection. EON Studio needs to call the 

IEonModule functions CheckOutLicense(), OnConnect(), OnDisconnect() 

and CheckInLicense() during license handling. 

How to disable licensing on your module 

If you do not wish to use license protection on your module, always 

return LICENSE_OK from your CheckOutLicense() function and a non-zero 

value from your OnConnect() function. 

The relation between EON Studio and its modules 

EON Studio consists of several components that interact with one 

another to provide the user with a working application. These 

components are often implemented as separate modules that are loaded 

automatically—and unconditionally—when you start EON Studio (for 

example, some of those modules are the ones that display the 

Butterfly, Scene graph and Component views). 

The EON Studio application follows Windows so called document–view 

object model that splits the responsibilities between a number of 

components, namely: 

• the document, which is the object that encapsulates the actual data 

(the document corresponds to a complete EON simulation), and 

• a number of views that present the data in different ways (for 

example the Routes window or the Simulation Tree window). 

When the user modifies the application's data, these modifications are 

directed towards the document. If the data has changed, some of the 

views might need to be updated. The views only display subsets of all 

the information contained in a document—the views would otherwise be 

completely cluttered with facts and figures, and thus they would be 

more or less worthless to the user. An application could host several 

documents—that is, several sets of data—but EON Studio currently 

supports only one document (simulation) at a time. (However, this 

might change in later versions of EON Studio.) 

2.5 15

User Guide 

Techniques 

Communication inside EON 

The different parts of the EON Studio application must be able to 

communicate with each other. For example, you may want to pass 

important information between two or more modules, or perhaps a node 

needs to call certain functions of its parent node. This section is 

aimed to clarify the communication issue, and to help you choose 

between different options when there are several possible ways to 

perform a given communication task. 

Communication between nodes 

The preferred way to send information between two nodes, or to let one 

node control another one, is to use events as described under one of 

the previous sections, “What is a node/agent” 

Some older nodes still use a more direct COM solution. Such a node 

first acquires an interface to the node it wishes to affect, and then 

it calls the appropriate function of that node. However, this method 

is more or less regarded as obsolete, and consequently you should try 

to avoid it. Instead, expose useful eventIn/-Out and exposedField 

fields and let the user implement a normal event-passing scheme in EON 

Studio's Routes window. 

There is actually another way of changing the values of a node; you 

could write scripts in e.g. VBScript that finds a node in the 

simulation and then reads or sets the node's field values. Refer to 

the Script node in the EON Studio Reference Guide for a thorough 

description. 

Commands 

Used to invoke command handlers in modules when user has selected a 

menu item or a toolbar button bound to a particular command previously 

registered by a module. Standard commands (such as Cut, Copy, Paste 

and Delete) will be sent to the module in this way, plus Module 

Messages. However, this doubled information provision might become 

subject of change in future releases of EON Studio. 

Module Messages 

There is an obvious need for modules to communicate with each other 

and with EON Studio. This is carried out using a concept called module 

messaging. It is based on a broadcast-subscribe strategy, where an EON 

Studio application object acts as the intermediator—modules that wish 

to inform its peers about something, make IAutApp::SendMessage() calls 

to EON Studio. A module interested in messages of a specific type 

should subscribe to those messages through an IAutApp::ListenTo() 

call. EON Studio will then add the module to its list of listeners. 

After subscribing, EON Studio will forward each received message of 

the requested type to the subscribing modules. Hence, EON Studio is 

employing a kind of point-to-point multicast technique, with send- 

16 


User Guide 

Wizards 

lists based on the message types registered by the subscribing 

modules. 

EON Module 1 

Logical messaging 

path 

Other EON Module(s) 

2. Subscribe to message (IAutApp::ListenTo ) 

3. Send message (IAutApp::SendMessage ) 

1.Register message (IAutApp::GetToken ) 

EON 

Studio 

4. Broadcast message to 

subscribed module(s), using the 

Win32 API SendMessage 

Actual 

messaging procedure 

Figure 4. Schematic view of module messaging 

The following messages types are predefined and used by EON Studio: 

• AA_GUID_CUT*: Sent by EON Studio when the user has selected the Cut 

command on the menu or the toolbar. 

• AA_GUID_COPY*: As above, but corresponding to the Copy command. 

• AA_GUID_PASTE*: As above, but corresponding to the Paste command. 

• AA_GUID_DELETE*: As above, but corresponding to the Delete command. 

• AA_GUID_NODEBAGCHANGE: Sent when a nodebag has changed due to user 

activities. 

• AA_GUID_VIEWACTIVE: Sent whenever a new view has been activated in 

EON Studio. 

• AA_GUID_ICONCHANGED: Sent when the icon of a prototype (or node) 

has been changed. 

• AA_GUID_SETNODE: Sent by a module when a new node should receive 

the focus in one of the EON Studio-specific windows, such as the 

Routes window or the Butterfly window. 

• AA_GUID_NODEFOCUS: This message is sent by EON Studio when the user 

has activated a new node. 

• AA_GUID_SHOWPROTO_PROP: Sent when the user requests the properties 

page of a specific prototype instance (mainly intended for internal 

use). 

However, some message types are defined but not yet used by EON 

Studio. They should be sent when the user selects the specific command 

either from one of the menus or on the toolbar : 

• AA_GUID_PRINT* 

• AA_GUID_PRINTPREVIEW* 

• AA_GUID_CLEAR* 

• AA_GUID_CLEARALL* 

• AA_GUID_UNDO* 

• AA_GUID_REDO* 

• AA_GUID_SELECTALL* 

Each message above is briefly commented on in the file Commands.H in 

the EON SDK Development Files folder. 

A module is only allowed to listen to the so-called menu command 

messages (denoted by asterisks in the lists above), but can both 

2.5 17

User Guide 

Techniques 

listen to and send messages of other types. A module may also freely 

define new message types that it could use when communicating with 

other modules. 

Following is a brief description of how you should work with module 

messages. 

1. To begin with, you perform module initialization. Call 

IAutApp::GetToken() once for each message type you want the module 

to recognize. Store all tokens for future use—you will need them to 

determine the type of module message when Windows messages finally 

start to arrive. 

2. Then call IAutApp::ListenTo() for all the message types you'd like 

EON Studio to forward to the module. As an argument, pass a handler 

to the window you want to be the target for the specific message 

type. The module (or rather, one of the module's windows) is now 

ready to start receiving messages. It is important to note that you 

should skip this step completely if you want to subscribe to menu 

command messages—those messages are received without calling 

IAutApp::ListenTo(). 

3. A WindowProc() message handler placed in the target window should 

first decide whether the received Windows message is a module 

message. If so, the handler must decide which type the message has— 

you should compare the message token with the ones you have 

previously stored (see Step 1). 

4. If the message belongs to the set of module messages you're 

interested in, then let the WindowProc() handler process it 

accordingly. Note that you should never change the contents of the 

message structure. There might be other modules that listen to the 

same message type. If you modify the information, those modules 

will receive corrupt messages. 

Note that you should always work on copies of the original module 

messages if you wish to modify the contents of the messages. 

5. If necessary, make your handler call the parent message handler 

CWnd::WindowsProc() and return. 

No snippets of code are included in this section. However, it is 

advisable to inspect the source code of the Sample Module, or read 

through the ModuleView.CPP file created by the EON Module Wizard. 

View handling 

One of the most exciting features of creating an EON module is the 

ability to seamlessly add custom views inside EON Studio. These views 

are treated in the same way as any standard views. In fact, some of 

the complex views (Scenegraph, Butterfly, ScriptEditor, etc) in EON 

18 


User Guide 

Wizards 

Studio are actually implemented as EON modules and using the same 

interface as described in this SDK. 

Persistent views 

A view in EON Studio can be in docked, floating or MDI state. 

Furthermore, the user can freely configure where to dock it or control 

its size and position. When the user exits EON Studio, he usually 

would like to retain the view configuration so that next time he uses 

EON Studio, he would get back the same configuration. Therefore, 

before adding a custom view to EON Studio using the SDK, you should 

consider whether the view should be persistent or not. A persistent 

view requires slightly more job but will maintain its window 

information between sessions. In EON Studio, Scenegraph and Butterfly 

are persistent views while the ScriptEditor is not. 

Implementing persistent views is accomplished by providing appropriate 

data at certain callbacks. The following figure shows the sequence of 

callbacks when EON Studio is started. It also shows what the module 

should do in each callback related to persistent views. 

2.5 19

User Guide 

Techniques 

Wizards 

The wizards delivered with EON SDK are accessed from the Projects tab of the File>New 

dialog box in Visual Studio. 

EON Node Wizard 

Figure 5. EON Node Wizard in New Project Dialog 

1. Select EON Node Wizard. 

2. Enter a project name. Note that the project name must not include 

spaces or special characters. 

3. Select the physical location for the project. 

4. Select Create new workspace to create a new node package. Use Add 

to current workspace to add nodes to an existing node package. To 

do this enter a temporary project name (for example, Added), select 

the Add to current workspace option and click OK. If Visual Studio 

was properly configured, this project will be deleted automatically 

from the workspace. If the project is not automatically deleted, 

Visual Studio will ask you to locate the project file (called 

Added.dsp, if we use the above example) when you reopen your 

workspace. If this happens, select Cancel and delete the missing 

project from your workspace. 

6. Click OK. 

Figure 6. EON Node Wizard dialog box 

7. After opening a new node project, the EON Node Wizard dialog box 

will appear. 

8. Enter the new node name. E.g. “MyNode”. 

20 


User Guide 

Wizards 

9. Select which node group the node should belong to. New node groups 

may be created. 

10. Enter your node’s property page name. If you leave this field empty 

the property page name will be the same name you gave the node with 

“PP” as a prefix. E.g. “PPMyNode”. This to avoid identical class 

names. 

11. Select the number of properties page tabs. If multiple tabs a 

number will be added to the class name. E.g. “PPMyNode”, 

“PPMyNode_2” and “PPMyNode_3” 

12. Selected or deselect methods depending on the features you want to 

add to your node. 

Node methods 

Serialize 

If the node should be able to store data types other than those 

defined by the EON standard, the Store non-field data option should be 

selected. The generated C++ skeleton code will include a Serialize() 

function, where calls to the standard CArchive() functions (Read() / 

Write()) should be specified. See the MFC documentation for more 

information. 

Update 

If the node should perform tasks once per frame, select this option. 

The generated C++ skeleton code will include an Update() function that 

will be called before each frame is drawn. This is where update code 

should be placed. 

NOTE: Use this option sparingly to avoid burdening your system. Most 

nodes need not be updated at every frame. These can be set to respond 

only when they receive events. 

EventsProcessed 

If this option is selected, an EventsProcessed() function will be 

added to the node’s C++ skeleton code. This function will be called 

once per frame if an event has been received since the previous frame 

was drawn. This is useful if data arrives at a higher rate than the 

frame rate, but when just the computed results (based on the incoming 

data) of the complex calculations are needed. 

IsSensor 

Override this function to prevent the baseclass implementation that 

returns FALSE. If your implementation returns TRUE your node is a 

sensor, i.e. it can generate out-events without first getting an inevent. 

13. Visual Studio will confirm your actions in the New Project 

Information window. Click OK to continue. 

14. Visual Studio will ask you to close and reopen your workspace. 

Click OK to continue, and go to the File menu to close and reopen 

2.5 21

User Guide 

Techniques 

the workspace. When the workspace is reopened, include the PP 

project in the created workspace. The PP project is in a node 

project sub-directory. 

Wizard-generated files 

As the wizard creates the new node’s code skeleton, it will generate 

several new files. 

EON Node Wizard generated files: 

Directory: ...\ProjectName 

• ProjectName.DSP 

Visual Studio project file. Contains project settings, e.g. linker 

directives. 

• STDAFX.H 

Include file for standard system include files and the project 

specific include files that are used frequently but changed 

infrequently. This file is included by STDAFX.CPP. 

• STDAFX.CPP 

Source file used to create the project's precompiled header file 

(.pch). 

• RESOURCE.H 

Header file containing resource symbol definitions, e.g., the 

default icon bitmap resource. This file is included by the resource 

script. 

• ProjectName.RC 

Project resource script containing version information, string 

table, dialogs, icons and bitmaps, compiled into a binary resource 

that is linked to the project output file. (ProjectName.DLL). 

• ProjectName.DEF 

Module-definition file is a text file that contains statements for 

defining ProjectName.DLL and its exports. 

• ProjectName.IDL 

The interface specification file consists of an interface header 

followed by an interface body. The interface header includes an 

attribute list describing characteristics that apply to the 

interface as a whole. The interface body contains the remote data 

types and function prototypes. This file is compiled by MIDL before 

the C++ compiler is activated. The MIDL output is ProjectName.H, 

which is included in ProjectName.CPP. 

• ProjectName.CPP 

Implementation of ProjectName.DLL exports. 

• NodeName.H 

22 


User Guide 

Wizards 

Node class definition. The inheritance and COM map specifies which 

interfaces the node supports. For example, if the IAgent interface 

is supported, the node should implement the Update method. 

The header file is more or less the same for all nodes. The main 

differences are in the class names and in the FID_… enumeration 

that supplies field identifiers. 

• NodeName.CPP 

Node implementation. Construction, destruction, initialization and 

processing field data. 

Directory: ...\ProjectName\Res 

• DEFAULTI.BMP 

Default icon linked to all created nodes. 

Directory: ...\ProjectName\PPProjectName 

• PPProjectName.DSP 

See description in previous section. 

• STDAFX.H 





Header file containing resource symbol definitions, e.g., dialog 

resources. This file is included by the resource script. 

• PPProjectName.RC 

Project resource script containing version information, string 

table, dialogs, icons and bitmaps, compiled into a binary resource 

that is linked to the project output file. (PPProjectName.DLL). 

• PPProjectName.DEF 


• PPProjectName.CPP 

Implementation of PPProjectName.DLL exports. 

• EONPE.H 

Uses the DECLARE_PPCLASS macro on the first properties page of each 

node. This macro defines a class for each node that contains all 

the properties pages used by the node. 

• EONPE.CPP 

Implements one class for each node that has an array member 

containing all the properties page objects used by the node. 

• PPNodeName.H 

2.5 23

User Guide 

Techniques 

Definition of a class derived from MFC's CpropertyPage. 

• PPNodetName.CPP 

Implements the EON properties page and the DataTransfer function. 

This function transfers data of those fields handled by the 

properties page to the appropriate node. 

Node C++ source file 

The wizard creates one source file for each node and one for the 

project, i.e., the DLL. 

Project IDL file 

The IDL file contains interface definitions and CoClass definitions. 

There is only one IDL file per DLL. All interfaces and classes 

implemented in a specific DLL are defined in the IDL file. 

Writing nodes in C++ 

Manipulating in- and out-fields by using logic operations and 

algorithms requires a minimum of programming experience. Use standard 

C++ programming to implement the desired functionality in any of the 

following functions: FieldChanged(), OnPreUpdate(), Update() or 

OnPostUpdate (), depending on when your code should execute. Remember 

that the execution model traverses all the way through the simulation 

tree when calling these functions; a child node is always called after 

its parent. 

When designing a new node, one has to decide how it shall interact 

with its surroundings. E.g., the EON Rotate node rotates its parent, 

while the KeyboardSensor uses eventOut fields and routes. 

With standard Windows programming, it is possible to incorporate 

hardware such as mice, printers or mass storage devices. If you need 

access to the graphics core of EON, you must use DirectX. 

Defining fields 

Define fields in the InitClass() function. The base class constructor calls this 

function the first time an instance of your node is created. 

Accessing field values 

Processing eventIn 

Generating events 

Loading and Saving (Serializing) 

Using DirectX 

The DirectX component that is useful when working with graphics is 

Direct3D. For example, you can get and set individual vertex positions 

by using the included mesh interface. This DirectX component also has 

several other interfaces for frames, viewports and textures. 

24 


User Guide 

Wizards 

If you use Direct3D functions within your node, you must obtain a COM 

(Component Object Model) interface using either QueryInterface() or 

CComQIPtr(). 

QueryInterface() requires you to release the interface when it is not 

needed. If you acquired an interface in the OnInitialize() function, 

release it in the OnReset() function. 

CComQIPtr() is used primarily when you will only use the interface 

temporarily, e.g., as in the OnInitialize() function below. An object 

of this class performs automatic reference counting through calls to 

AddRef and Release. 

Although all available DirectX functions are fully documented in the 

DirectX SDK, it might be worthwhile to obtain one of the many books on 

the topic. 

Interfaces 

The recommended procedure for accessing other nodes in EON Studio is 

by modifying their fields. However, some older nodes are still 

accessible via the interfaces they implement. See the Reference Guide 

for more information on how to query for a COM interface and to see a 

list of useful interfaces. A more complete description of interfaces 

is beyond the scope of this guide. 

Connection points in EON 

A connection point is a COM standard feature for sending outgoing 

events. Each connection point is exposed by an outgoing interface. Any 

client object may connect to an object exposing one or more connection 

points to receive events from that object. A client object implements 

the outgoing interface, a notify sink. 

• Implementing connection points improves simulation performance. In 

EON, a node implements a subset of all defined interfaces. 

If you use connection points with EON, use them with ATL and a help class 

CConnectionPointAdvisor; the procedure is otherwise quite complicated. 

Using the EON log 

EON’s log handling features provide the developer with improved 

functions for filtering out log messages that are irrelevant to the 

development process. Log messages can be sent from nodes (in the C++ 

code) and from Script nodes. Each log message has input arguments: 

LogType, Source, Description and Message. 

Adding an icon to a node 

You can easily add a specially designed icon to a new node created in 

Visual Studio. Choose Insert>Resource to add a new bitmap to your EON 

node project. In the resource editor, resize the drawing area to a 

16x16 square. Visual Studio will give your bitmap a default name. If 

you want to rename it, click the icon name to view its properties. 

Open your node source file and replace ”IDB_DEFAULT_ICON” inside the 

GetIconID() function with a new bitmap name, for example, IDB_NODE. 

2.5 25

User Guide 

Techniques 

EON Module Wizard 

The EON Module Wizard is used to create a code skeleton for a new 

module. 

Figure 7. EON Module Wizard 

1. Select EON SDK Module Wizard. 

2. Enter a project name. Note that the project name must not include 

spaces or special characters. 

3. Select the physical location for the project. 

4. Decide whether the project should be created in a new workspace or 

added to the current workspace. 

5. When you click OK the following dialog box will appear. 

Figure 8. EON Module Wizard dialog 

6. In the Module Wizard's first step, you fill in the Module name, 

Version, Program ID (version-independent ProgID) and Description 

fields. Then click on the Next button. 

7. In the second step, decide whether your module should support 

views. If so, do you need a standard view or perhaps split views 

Enter the number of rows and columns if you choose split views. 

8. If you selected a view, you may specify standard and proprietary 

module messages to be handled by the module's view class. 

9. Furthermore, you could choose to make the new module include 

command handlers for default and custom commands. (Commands are 

exposed to the user as menu items or via toolbar buttons.) Now 

click Next. 

10. As the third and last step, you can select whether to include 

logging of errors, and support for verbose logging. Here, you 

should also select the licensing option (providing that you already 

have a functioning license feature). Otherwise, keep it as it to 

26 


User Guide 

Wizards 

disable licensing (the licensing source code will just be commented 

out—not deleted). 

11. Always leave the EonBase2.h option as it (checked)—this selection 

is only intended for internal use, by the development team at EON 

Reality. 

12. Click Finish. The New Project information window will appear. The 

files the wizard will create are listed, along with other 

information. 

Figure 9. New Project Information window 

13. Click OK to continue. The wizard will now generate the code 

skeleton for the module. Note that you must close the project and 

reopen it before compiling the project. This is due to limitations 

in Visual Studio. 

Wizard generated files 

The EON SDK Module Wizard generates the following files: 

Directory: ...\ProjectName 

• ProjectName.DSP 

This is the normal Visual Studio project file. It keeps track of 

which files are currently included in the project, stores project 

settings, etc 

• STDAFX.H 

Include file for standard system include files and the projectspecific 

include files that are used frequently but changed 

infrequently. This file is included by STDAFX.CPP. 


This C++ source file is used to create the project's precompiled 

header file (.pch). 


This header file contains resource symbol definitions, e.g., the 

default icon bitmap resource. Visual C++ reads and updates the 

Resource.H. It is included by the resource script, ProjectName.RC. 

• ProjectName.RC 

Project resource script containing, for example, version 

2.5 27

User Guide 

Techniques 

information, string tables and bitmaps. It is compiled into a 

binary resource that is linked to the project output file. 

• Toolbar.BMP 

This bitmap exists only if you choose the Add custom command to 

toolbar option in the Module Wizard. The bitmap file contains just 

three toolbar buttons, but you can easily extend it to include as 

many buttons you'd like. 

• ProjectName.DEF 

Windows definition file. It contains the exposed entry points of 

the ProjectName.DLL. 

• ProjectName.IDL 

The IDL file of our project. You will add interface and method 

definitions here. Microsoft's MIDL compiler will process this file 

to produce the type library (.tlb) file, in addition to 

ProjectName.h, which is included in ProjectName.CPP. 

• ProjectName.H 

This file contains interface declarations for the COM object, i.e., 

EON module. The MIDL compiler produces the ProjectName.h file based 

on the project's IDL file. 

• ProjectName.CPP 

This is the main implementation file for the COM object housing. It 

contains source code for the DLL exports, and offers both ATL and 

MFC support. (Note the presence of the_Module and theApp global 

variables that are there to support the use of ATL and MFC 

classes.) 

• EONMODULE.H 

This header file contains the class declaration of your EON Studio 

module's class CEonModule, which is the class you have to modify to 

include module-specific functionality. 

• EONMODULE.CPP 

The CEonModule class is implemented in this file. It may provide 

functions for licensing, connecting new views to the EON Studio 

GUI, adding toolbars, etc. 

• MODULEVIEW.H 

This file holds the declarations of the sub-classed window used as 

the module's view. 

• MODULEVIEW.CPP 

This file contains the source code for the implementation of the 

sub-classed window that your module uses as its view (or as split 

views). This is where all displaying of GUI objects for various 

data exposure should be placed. Here, you should also add code to 

support different kinds of module messages (that is, if you have 

decided to include module message handling in your module). 

• README.TXT 

This file contains some brief information about each file inserted 

into the new project. 

28 


User Guide 

Wizards 

Writing modules in C++ 

To add features, changes to the module are made in the following 

files: 

• EonModule.CPP 

• EonModule.H 

• ModuleView.H 

• ModuleView.CPP 

The resource file may also need to be changed if you want to add or 

modify toolbars, dialog boxes, etc. 

For code samples, see the Sample Module on the EON SDK CD. 

2.5 29

User Guide 

Techniques 

Techniques 

Smart pointers 

All COM objects encapsulate an integer value that keeps track of 

object usage. Each time a client creates a COM object the AddRef 

function of that object is called. This increment the object’s 

reference counter by one and prevents the destruction of that object 

when it goes out of scope. This way separate parts of the client or 

even different clients may use the same object that will persist as 

long as its reference counter is larger than zero. When an object’s 

Release function is called its reference counter is decrement by one, 

if this result in a zero value the object deletes it self. 

Each time a new pointer is introduced AddRef should be called, 

otherwise the pointer may become invalid. And before the pointer goes 

out of scope the programmer has to call Release otherwise there will 

be a memory leak. Trouble occurs when a programmer has several 

pointers to several different COM objects, e.g.: 

#include 

#include "shlobj.h" // Shell COM components 

#include "objbase.h" 

int main(void) 

{ 

HRESULT hr = CoInitialize(NULL); 

if (FAILED(hr)) 

{ 

CoUninitialize(); 

return -1; 

} 

IUnknown* pUnk1; 

// CoCreateInstance calls AddRef 

hr = CoCreateInstance 

( 

CLSID_ShellLink, 

NULL, 

CLSCTX_INPROC_SERVER, 

IID_IUnknown, 

(void **) &pUnk1 

); 


{ 


return -1; 

} 

IUnknown* pUnk2 = pUnk1; 

ULONG lRef = pUnk2->AddRef(); 

printf("Reference counter = %d\n", lRef); 

lRef = pUnk2->Release(); 


lRef = pUnk1->Release(); 


} 


return 0; 

Obviously it is quite easy to forget ether AddRef and Release on pUnk2 

or Release on pUnk1 since CoCreateInstance did AddRef for us. To avoid 

this behavior we could encapsulate all COM pointers in a template 

class that calls AddRef when it is assigned to an object and Release 

30 


User Guide 

Techniques 

when it goes out of scope. Below you will see an example of such a 

garbage collecting class, this to make it easier to understand the ATL 

smart pointers later. 

// Unknown.h 

class CUnknown 

{ 

int m_ReferenceCount; 

public: 

}; 

CUnknown(); 

~CUnknown(); 

void AddReference(void); 

void ReleaseReference(void); 

/***********************************************************/ 

// Unknown.cpp 

#include 

#include "Unknown.h" 

CUnknown::CUnknown() 

{ 

m_ReferenceCount = 0; 

} 

CUnknown::~CUnknown() 

{ 

printf("CUnknown object destroyed!\n"); 

} 

void CUnknown::AddReference(void) 

{ 

m_ReferenceCount = m_ReferenceCount + 1; 

printf("AddReference: "); 

printf("Reference count = %d\n", m_ReferenceCount); 

} 

void CUnknown::ReleaseReference(void) 

{ 

m_ReferenceCount = m_ReferenceCount - 1; 

if (m_ReferenceCount == 0) 

{ 

printf("ReleaseReference: "); 

printf("Reference count = 0\n"); 

delete this; 

} 

else 

{ 

printf("ReleaseReference: "); 

printf("Reference count = %d\n", m_ReferenceCount); 

} 

} 

/***********************************************************/ 

// SmartPtr.h 

template 

class CSmartPtr 

{ 

T* p; 

public: 

CSmartPtr(T* p_) 

{ 

p = p_; 

p->AddReference(); 

} 

~CSmartPtr(void) 

{ 

p->ReleaseReference(); 

} 

// Type cast operator 

// from SmartPtr to T 

operator T*(void) 

{ 

return p; 

} 

// Indirection operator 

// return a reference to a T object 

T& operator*(void) 

{ 

return *p; 

2.5 31

User Guide 

Techniques 

}; 

} 

// Member-selection operator 

// return a pointer to a T object 

T* operator->(void) 

{ 

return p; 

} 

// Assignment operator 

// for CSmartPtr = CSmartPtr 

CSmartPtr& operator=(CSmartPtr &q_) 

{ 

return operator=((T *) q_); 

} 

// Assignment operator 

// for CSmartPtr = T* 

CSmartPtr& operator=(T* p_) 

{ 

p->ReleaseReference(); 

p = p_; 

p->AddReference(); 

return *this; 

} 

/***********************************************************/ 

// main.cpp 

#include 

#include "Unknown.h" 

#include "SmartPtr.h" 

class CMyClass : public CUnknown 

{ 

// This is my fake "COM-object". 

// It inherits AddReference and ReleaseReference 

// from CUnknown. The SmartPtr knows that all fake 

// "COM-objects" has these methods. 

public: 

CMyClass() {}; 

~CMyClass() {}; 

int MyMethod(void) {return 42;} 

}; 


{ 

int a, b; 

printf("Creating pointers:\n"); 

CSmartPtr pSmart1 = new CMyClass; 

CSmartPtr pSmart2 = new CMyClass; 

CMyClass* pSilly = new CMyClass; 

pSilly->AddReference(); 

printf("\nTesting pointers:\n"); 

a = pSilly->MyMethod(); 

b = pSmart1->MyMethod(); 

printf("Silly = %d, Smart1 = %d\n", a, b); 

printf("\nAssigning pointers:\n"); 

pSmart2 = pSmart1; 

pSmart1 = pSilly; 

printf("\nRelease pSilly\n"); 

pSilly->ReleaseReference(); 

// Not delete 

printf("\nOut of scope!\n"); 

} 

return 0; 

In this example the CUnknown class imitates the behavior of the 

IUnknown interface that all COM objects have, this is the interface 

that allow reference counting. CMyClass is the fake “COM object” that 

inherits its reference counting abilities from CUnknown. We must call 

AddReference and ReleaseReference on the pSilly pointer exactly as 

with the real COM pointers (pUnk) in the previous example. To get 

around that we use the SmartPtr template class. This class 

encapsulates any fake “COM object” and calls AddReference and 

ReleaseReference on that object in situations that requires such a 

call, e.g. when the SmartPtr object goes out of scope. It overrides 

32 


User Guide 

Techniques 

the * and -> operators to expose the contained object instead of the 

SmartPtr object it self. The program output should be something like 

this: 

00: Creating pointers: 

01: AddReference: Reference count = 1 



04: 

05: Testing pointers: 

06: Silly = 42, Smart1 = 42 

07: 

08: Assigning pointers: 

09: ReleaseReference: Reference count = 0 

10: CUnknown object destroyed! 




14: 

15: Release pSilly 


17: 

18: Out of scope! 





Here line 1-2 shows that the SmartPtr class calls the CMyClass 

AddReference function for us, while we have to make that call our self 

on line 3 for the pSilly standard pointer. Next, we test that it 

really is the CMyClass object that we reach with the -> operator. When 

assigning pSmart1 to pSmart2 the original object that pSmart2 points 

to is released and destroyed on line 10. Then the object that pSmart1 

points to get one more reference on line 11 when pSmart2 also is 

assigned to point towards it. Then in line 12 pSmart1 is set to point 

to the same object as pSilly. That is why the reference counter on the 

object previously pointed to by pSmart1 is decrement by one. On the 

next line the object pointed at by pSilly increments its reference 

counter when pSmart1 is assigned to it as well. On line 16 the pSilly 

pointer is released, but since pSmart1 also points to that object the 

reference count will not become zero and therefor the object will not 

be deleted. Now both SmartPtr has one object each. Both object 

reference counts are one and therefor they will be deleted when 

pSmart1 and pSmart2 goes out of scope. Since the automatic destruction 

of the SmartPtr template class objects will decrement those reference 

counts to zero. 

CComPtr and CComQIPtr 

Active Template Library (ATL) provides programmers with CComPtr and 

CComQIPtr smart pointer template classes specialized for COM-objects. 

In comparison our SmartPtr class is not really that smart. Similar to 

our class they support automatic reference counting through calls to 

the COM-objects AddRef and Release functions. Unlike our template 

class CComPtr and CComQIPtr overloads several more operators, handling 

2.5 33

User Guide 

Techniques 

every pointer operation in a safe manner. E.g. the address operator 

(&) will return the address of the encapsulated COM-object. 

Both ATL smart pointer classes support the following operators: 

T* Type cast from CComPtr or CComQIPtr to T* 

* Accesses the encapsulated object 

& Address of the encapsulated object 

-> Member access through a pointer to the encapsulated object 

= Assignment between two smart pointers or one smart pointer and one 

T object 

! Check if valid pointer. Returns TRUE if there is not an 

encapsulated COM object, otherwise FALSE 

CComPtr and CComQIPtr both has a public member “p”, that is the actual 

standard pointer to an object of the class T. They also implement a 

Release method so that direct calls to p->Release() may be avoided. 

The difference between CComPtr and CComQIPtr is that the latter can 

make QueryInterface calls for you as shown below. 

#include 

#include "shlobj.h" 

#include "objbase.h" 

#include "atlbase.h" 


{ 

HRESULT hr = CoInitialize(NULL); 


{ 


return -1; 

} 

// Start code block 

{ 

CComPtr pSLink; 

//IShellLink* pShellLink; 

// CoCreateInstance calls AddRef 

hr = CoCreateInstance 

( 

CLSID_ShellLink, 

NULL, 

CLSCTX_INPROC_SERVER, 

IID_IShellLink, 

(void **) &pSLink 

); 


{ 


return -1; 

} 

CComPtr pPF1; 

hr = pSLink->QueryInterface 

( 

IID_IPersistFile, 

(void **) &pPF1 

34 


User Guide 

Techniques 

); 


{ 

printf("Query for IPersistFile failed!\n"); 


return -1; 

} 

CComQIPtr pPF2(pSLink); 

if (!pPF2) 

{ 

printf("Query for IPersistFile failed!\n"); 


return -1; 

} 

printf("Out of scope.\n"); 

printf("Smart pointers calls Release on "); 

printf("encapsulated objects before\n"); 

printf("pSLink, pPF1 and "); 

printf("pPF2 are destroyed.\n"); 

} 

// End code block 


} 

return 0; 

The code block in this example is used to make the variables to go out 

of scope before the CoUninitialize call, otherwise the DLL containing 

the ShellLink object will unload and our poiners become invalid. 

For more information on these two template classes see there 

definition in ATLBASE.h or Microsoft Developers Network. 

2.5 35

User Guide 

Tutorials 

Summary: 

• Use the Module Wizard to lay down the ground (skeleton code). 

• Remove stuff you don’t need. 

• Add or modify implementation to get the job done. 

• Most frequently, you will need to modify/add more command handlers 

and adapt the OnUpdate handler. 

36 


Reference Guide 



About the Reference Guide 

In this reference guide, you will find information on the functions 

used in EON SDK. The guide is divided into two sections—one section 

covers functions that are used when creating nodes, the other contains 

information needed to build modules 

In the first section, the functions are listed alphabetically. The 

listings provide function descriptions and information on parameters 

and return values. There are also short examples illustrating how the 

functions are used. 

General 

Data types 

The module section contains a list of COM interfaces used in EON SDK. 

The data types used in EON SDK are listed in the following table with 

information on the corresponding event types, a brief description for 

each data type, in addition to its valid range. 

You should be familiar with the standard data types used by EON. 

Single-value fields and events have names that begin with SF (for 

Single Field). Multiple-valued fields and events have names that begin 

with MF (Multiple Field). 

Type Event type name Description Range 

Integer SFInt32 An integer value [–2,147,483,648; 2,147,483,647] 

Float SFFloat A floating-point value [-3.4E-38; 3.4E 38] 

Double SFDouble A double precision float [-1.7E –308; 1.7E 308] 

String SFString A string N/A 

2D float vector SFVec2f A two-dimensional float vector Same as Float for both components 

3D float vector SFVec3f A three-dimensional float vector Same as Float for each component 

Boolean SFBool Boolean value TRUE/FALSE 

Node SFNode Reference to a node N/A 

Color SFColor Three floats, one for each of the Red, 

Green an Blue color components 

[0.0; 1.0] each 

Time SFTime A double precision float representing 

seconds 

Rotation SFRotation Four floats: rotation around an axis, 

measured in radians; the axis is 

defined in (x,y,z) coordinates 

Image SFImage Placeholder for an arbitrary byte 

vector 

Same as Double 

Same as Float for each component 

N/A 

All SF data types have an array counterpart carrying the prefix MF. 

These MF data types can hold several SF data values. For example, 

several SFNode values can be stored in a single MFNode field. 

2.5 37


Classes in EON SDK 

Nodes 

Default node fields 

There is a well-defined set of fields that every node always 

implements by default. One such field is the Children MFNode field, 

where all the children of a the node are listed. The TreeChildren 

field is the placeholder for the same nodes as listed in the Children 

field, but also stores node references. These references are links to 

children that actually belong to other nodes. (See the Script node 

description in the EON Studio Reference Guide for more information on 

how to manipulate MFNode fields using VBScript.) 

All nodes may be started or stopped with events, and they send events 

to reflect changes in their running status. If a node is to be started 

or stopped, the SetRun or SetRun_ in-events should be used. These inevents 

use Boolean data: a SetRun value of TRUE will start a node and 

value of FALSE will stop it. SetRun_ is the inverse of SetRun (FALSE 

is used for start and TRUE for stop). 

Some nodes do not need start/stop capabilities. Implementation of 

these nodes requires neither the SetRun and SetRun_ in-events, nor the 

OnStart() and OnStop() functions. Nevertheless, the SetRun and SetRun_ 

fields will still be exposed. 

Name Field type Data type Description Range 

TreeChildren field MFNode Holds both child nodes and node references N/A 

Children field MFNode Holds the node's child nodes. N/A 

SetRun eventIn SFBool Starts the node if it is stopped TRUE/FALSE 

SetRun_ eventIn SFBool Stops the node if it is running TRUE/FALSE 

OnRunFALSE eventOut SFBool Sent when the node is stopped Always TRUE 

OnRunTRUE eventOut SFBool Sent when the node is started Always TRUE 

OnRunChanged eventOut SFBool Sent when the node changes state from running to 

stopped or vice versa 

TRUE/FALSE 

38 





CAgent 

CEonBase 

EventsProcessed 

FieldChanged 

ValidateField 

EventGenerated 

FinalConstruct 

FinalRelease 

InternalGetField 

GetPropertyEditorCLSID 

InitClass 

Serialize 

CEonObject 

OnInitialize 

OnReset 

OnStart 

OnStop 

CExternalReference 

OnGetReference 

OnGetReferenceCount 

OnSetReference 

CNode 

MoveChild 

SwapChildren 

CConnectionPointAdvisor 

Advise 

Unadvise 

EonUtil 

EonFindNode 

2.5 39



EonFindNodePath 

EonFindNodeWithInterface 

EonGetName 

EonGetParentFrame 

EonGetParentRMFrame 

EonGetPath 

EonGetRoot 

EonGetSimulationInstance 

EonHasInterface 

EonLoadFileToDisk 

EonReleaseSimulationInstance 

EonReportError 

GetCameraDistance 

GetCameraPosition 

GetCameraSQRDistance 

40 



Modules 

Modules 

Interfaces for EON Modules 

There are several COM interfaces that will interact with the modular 

system. 

2.5 41


Interfaces 

Interfaces 

There are a large number of COM interfaces for the various software 

components in the EON environment. The following section is intended 

to provide you with a thorough overview of useful interfaces. You will 

most certainly need to access several of the interface functions when 

working as an EON SDK application developer. Note that if you find an 

interface not included in the list below, you should try to avoid 

using it. 

42 



Interfaces 

IAgent 


IAgentFrame 

RenderRef 

RenderRef_ 

TransformToFrame 

TransformToWorld 

IAgentFrame2 

GetLocalTransform 

SetLocalTransform 

GetWorldTransform 

SetWorldTransform 

IAgentSimulation 

GetDescription 

SetDescription 

GetNoTreeNodes 

GetNoIniTreeNodes 

IncIniCounter 

GetStatisticsOn 

SetStatisticsOn 

LockRender 

UnlockRender 

IAgentViewport 

SetFront 

GetFront 

SetBack 

GetBack 

SetViewport 

GetViewport 

GetFieldOfView 

SetFieldOfView 

IsClicked 

IAutApp 

2.5 43


Interfaces 

ActivateView 

AddCommandTarget 

AddMenuItem 

AddModuleWindow 

AddToolbarButton 

CheckInFeature 

CheckOutFeature 

ConnectSplitView 

ForceDemoMode 

GetConfig 

GetDocument 

GetHostID 

GetLicenseKey 

GetLicenseStatus 

GetNextModule 

GetNodeInfo 

GetNodeInfoCount 

GetPositionFirstModule 

GetSettings 

GetToken 

GetUserList 

GetUserName 

GetViewPosition 

HideView 

IsDemoMode 

IsModuleLoaded 

ListenTo 

LogMessage 

RegisterCommand 

RegisterToolbar 

RegisterSplitView 

RegisterView 

RegisterView2 

RemoveView 

SendMessage 

44 



Interfaces 

SetDefaultWindowPosition 

SetViewName 

ShowView 

IAutDoc 

GetSelectedNode 

GetSimulation 

GetSimulationRoot 

SetDirty 

UpdateAllViews 

IAutNodeInfo 

GetCategory 

GetCLSID 

GetIconDLL 

GetIconID 

GetModuleCLSID 

GetNodeName 

IAutPrototype 

GetRootNode 

GetSubPrototypes 

IAutPrototypes 

GetCount 

GetPrototype 

IAutSettings 

CreateSubKey 

EnumKeys 

FindSubKey 

GetApplication 

GetRegInt 

GetRegString 

GetStandardKey 

RemoveSubKey 

SetRegInt 

SetRegString 

2.5 45


Interfaces 

CurrentRegKey 

CurrentBaseKey 

IAutSimulation 

GetPrototypes 

GetRootNode 

Run 

Stop 

ICEonConfig 

DoEditModal 

IChainSimulation 

SetNewSimulation 

GetNewSimulation 

IDegreeOfFreedom 

IDeviceKeyboard 

GetKey 

SetKey 

IEnumNodes 

Next 

Skip 

Reset 

Clone 

IEonDual 

GetField 

GetFieldByName 

GetFieldCount 

GetFieldInfo 

46 



Interfaces 

GetIdOfName 

GetParentNode 

IEonEvent 

GetField 

GetFieldByName 

GetFieldCount 

GetFieldInfo 

GetIdOfName 

IsSensor 

CollectEvent 

InternalEventsProcessed 

SetDirty 

DeliverEvent 

IEonField 

GetMFCount 

GetMFElement 

GetMFSpan 

GetSFBool 

GetSFColor 

GetSFFloat 

GetSFImage 

GetSFInt32 

GetSFNode 

GetSFRotation 

GetSFString 

GetSFTime 

GetSFVec2f 

GetSFVec3f 

SetMFElement 

SetMFSpan 

SetSFBool 

SetSFColor 

SetSFFloat 

SetSFImage 

2.5 47


Interfaces 

SetSFInt32 

SetSFNode 

SetSFRotation 

SetSFString 

SetSFTime 

SetSFVec2f 

SetSFVec3f 

SetValueFromField 

AddMFElement 

_RemoveMFElement 

_SetMFCount 

SetVariant 

GetVariant 

GetOwner 

GetStringValue 

SetStringValue 

TouchField 

ValidateField 

GetFieldInfo 

IEonField2 

GetLastInput 

IEonField3 

Load 

Save 

GetFieldID 

IEonFieldDual 

SetValue 

GetValue 

SetMFElement 

AddMFElement 

RemoveMFElement 

GetMFElement 

GetMFCount 

SetMFCount 

48 



Interfaces 

SetStringValue 

GetStringValue 

GetFieldType 

GetFieldName 

IEonInsertable 

IEonModule 

CheckInLicenseSynopsis 

CheckOutLicense 

GetCLSID 

GetDistributionRight 

GetSplitPaneReinitInfo 

GetViewReinitInfo 

OnCommand 

OnConnect 

OnCreateView 

OnDeleteContents 

OnDisconnect 

OnModuleListChanged 

OnNewDocument 

OnOpenDocument 

OnQueryDefWinPos 

OnSave 

OnSimulationRun 

OnSimulationStop 

OnUpdate 

OnUpdateCommandUI 

IEonObject 

GetIcon 

OnNewParent 

OnNewChild 

OnEdit 

Initialize 

Reset 

Clone 

2.5 49


Interfaces 

Start 

Stop 

IsRunning 

IsInitialized 

IEonObject2 

SetSimulation 

GetCLSID 

Save 

Load 

IsDirty 

LoadLegacy 

OnRemoveChild 

OnAddChild 

OnSetParent 

ValidateNewChild 

SetDirty 

LoadIcon 

IEonPropertyEditor 

DoModal 

IEonPrototype 

CreatePrototypeFromSubtree 

HasNonExportableExternalLinks 

SetPrototypeName 

GetPrototypeName 

SetIcon 

GetIcons 

GetIconsDib 

CreateSubBagIterator 

GetSubBag 

RemoveSubBag 

AddSubBag 

GetParentBag 

GetGUID 

FindSubBag 

50 



Interfaces 

GetInstanceCount 

SetShortDescription 

GetShortDescription 

SetLongDescription 

GetLongDescription 

GetExportedFieldCount 

AddExportedField 

GetExportedField 

GetExportedFieldIDByName 

SetExportedField 

RemoveExportedField 

CreatePrototypeInstance 

SetUserData 

GetUserData 

ExpandAllProtoypes 

UnexpandAllProtoypes 

GetBagID 

IEonSingleton 

SetSimulation 

IEonSingletonFactory 

GetSimulationInstance 

ReleaseSimulationInstance 

IExternalEvents 

SendEvent 

AddEventInField 

AddEventOutField 

DeleteEvent 

DeleteAllEvents 

SendOutEvent 

IExternalEventsNotifySink 

OnEvent 

IExternalReference 

GetReference 

2.5 51


Interfaces 

SetReference 

GetReferenceCount 

IFileLoader 

SetSimFile 

GetSIMDIR 

SetPath 

GetPath 

GetAbsPath 

MergePath 

LoadFile 

LoadFileToDisk 

IFileLoader2 

GetSimFileName 

GetSimFileNameLenght 

IFileLoader3 

SetSimFile 

GetSIMDIR 

SetPath 

GetPath 

GetAbsPath 

MergePath 

LoadFile 

LoadFileToDisk 

GetSimFileName 

SimFileNameLength 

Close 

IGUIMotionModel 

MotionNotify 

RequestMotionModelImages 

IJoystick 

GetNoJoysticks 

GetJoystickCapabilities 

GetJoystickData 

52 



Interfaces 

GetJoystickProperties 

SetJoystickProperties 

IJoystickState 

OnJoystickChange 

OnJoystickButtonChange 

OnJoystickPositionChange 

IKeyboard 

GetVKey 

GetVKeyPresses 

SetVKey 

SetVKeyPresses 

IKeyboardState 

OnKeyboardChange 

ILinkIterator 

Reset 

Next 

IsValid 

Current 

IMakePersistant 

SaveAll 

IMouse 

GetMouse 

SetMouse 

IMouseState 

OnMouseButtonChange 

OnMouseChange 

OnMousePositionChange 

INode 

SetParent 

GetParent 

AddChild 

2.5 53


Interfaces 

RemoveChild 

GetChild 

GetChildren 

GetChildrenCount 

SetName 

GetName 

SetBag 

GetBag 

SetID 

GetID 

INodeBag 

DeleteContents 

CreateNode 

AttachNode 

Save 

Load 

CopyNode 

CopyLink 

MoveSubtree 

MoveLink 

Paste 

CanPaste 

GetParentID 

GetParentPtr 

GetINode 

GetRefCount 

GetRefTarget 

InsertRef 

CanInsertRef 

DeleteRef 

AddRoute 

GetLink 

DeleteLink 

DeleteSubtree 

SeverLink 

54 



Interfaces 

GetReference 

GetNodeCount 

CreateNodeIterator 

CreateLinkIterator 

AddField 

DeleteField 

SwapChildren 

MoveChild 

GetAtomFromString 

GetStringFromAtom 

IsPersistentSave 

Dump 

INodeBagAge 

GetRoutesAge 

INodeBagFiles 

GetFileLoader 

INodeBagIterator 

Reset 

Next 

IsValid 

Current 

INodeBagIteratorFactory 

CreateNodeIterator 

CreateLinkIterator 

CreateSubBagIterator 

INodeIterator 

Reset 

Next 

IsValid 

Current 

INodeLicense 

GetLicenseOptions 

2.5 55


Interfaces 

GetModuleCLSID 

IPCLogQueue 

Log 

GetLogEvent 

56 



Interfaces 

UseLogType 

IsLogTypeUsed 

IPrototypeDefinitionHolder 

GetPrototypeDefinition 

GetSearchPath 

IReference 

GetLink 

SetLink 

UpdateLink 

IRouteManager 

AddRoute 

RemoveRoute 

EnableNode 

DisableNode 

AddNode 

DeleteNode 

PendingEvent 

EventDelivered 

IRouteManager2 

SetEventProcessing 

GetEventProcessing 

RegisterCallback 

UnRegisterCallback 

IRunControl 

SetBreakFlag 

GetBreakFlag 

ISettingsServer 

Edit 

SetSubKey 

IsRestartNeeded 

ISettingsServer2 

UseCurrentSubKey 

2.5 57


Interfaces 

ISimulation 

GetHwnd 

SetHwnd 


HandleActivate 

HandlePaint 

HandleResize 

HandleMove 

ISimulation2 

GetSimulationState 

GetActiveCamera 

GetActiveCameraPos 

ConvertLegacySimulation 

ISimulation3 

IncrementVisualAgeCounter 

ISimulationEONXEvent 

OnSetMotionModelImages 

ISimulationExternalEvents 

GetExternalEventsNode 

ISimulationMotionModel 

MotionNotify 

SetMotionModelImages 

InactivateGUIMotionModel 

ActivateGUIMotionModel 

ISimulationRenderEvents 

OnPreRenderViewport 

OnPostRenderViewport 

ISimulationRenderEvents2 

OnRenderSync 

OnRender 

OnFlip 

58 



Interfaces 

ISimulationRenderEvents3 

OnRenderTransparent 

ISimulationStateEvents 

OnStateChange 

ISimulationUpdateEvents 

OnPreUpdate 

OnPostUpdate 

ISimulationWindowEvents 

OnWindowSizeChanged 

ITraversal 

GetState 

IVersionInfo 

GetDependencies 

2.5 59

Macros 

Add field macros 

Version information macros 

60 



Interfaces 

Index 

Accessing field values, 25 

ActivateGUIMotionModel, 60 

ActivateView, 45 

Add field macros, 62 

AddChild, 56 

AddCommandTarget, 45 

AddEventInField, 54 

AddEventOutField, 54 

AddExportedField, 53 

AddField, 57 

AddMenuItem, 45 

AddMFElement, 50 

AddModuleWindow, 45 

AddNode, 59 

AddRoute, 57, 59 

AddSubBag, 53 

AddToolbarButton, 45 

Advise, 40 

Agent Wizard generated 

files, 23 

Agents, 9, 39 

AttachNode, 56 

CAgent, 40 

CanInsertRef, 57 

CanPaste, 57 

CConnectionPointAdvisor, 40 

CEonBase, 40 

CEonObject, 40 

CExternalReference, 40 

CheckInFeature, 45 

CheckInLicenseSynopsis, 51 

CheckOutFeature, 45 

CheckOutLicense, 51 

Classes in EON SDK, 40 

Clone, 47, 52 

Close, 55 

CNode, 40 

CollectEvent, 49 

Connection points, 26 

ConnectSplitView, 45 

ConvertLegacySimulation, 60 

CopyLink, 56 

CopyNode, 56 

CreateLinkIterator, 57, 58 

CreateNode, 56 

CreateNodeIterator, 57, 58 

CreatePrototypeFromSubtree, 

52 

CreatePrototypeInstance, 53 

CreateSubBagIterator, 53, 

58 

CreateSubKey, 46 

Current, 55, 58 

CurrentBaseKey, 47 

CurrentRegKey, 47 

Data types, 38 

Default node fields, 39 

Defining fields, 25 

DeleteAllEvents, 54 

DeleteContents, 56 

DeleteEvent, 54 

DeleteField, 57 

DeleteLink, 57 

DeleteNode, 59 

DeleteRef, 57 

DeleteSubtree, 57 

DeliverEvent, 49 

DisableNode, 59 

DoEditModal, 47 

DoModal, 52 

Dump, 57 

Edit, 59 

EnableNode, 59 

EnumKeys, 46 

EON Agent Wizard, 21 

EON licensing, 13 

EON log, 26 

EonFindNode, 41 

EonFindNodePath, 41 

EonFindNodeWithInterface, 

41 

EonGetName, 41 

EonGetParentFrame, 41 

EonGetParentRMFrame, 41 

EonGetPath, 41 

EonGetRoot, 41 

EonGetSimulationInstance, 

41 

EonHasInterface, 41 

EonLoadFileToDisk, 41 

EonReleaseSimulationInstanc 

e, 41 

EonReportError, 41 

EonUtil, 41 

EventDelivered, 59 

EventGenerated, 40 

Events, 10 

EventsProcessed, 40 

Execution model, 10 

ExpandAllProtoypes, 53 

Field Changed, 40 

Fields, 9 

FinalConstruct, 40 

FinalRelease, 40 

FindSubBag, 53 

FindSubKey, 46 

FLEXlm licensing, 15 

ForceDemoMode, 45 

Generating eventOut, 25 

GetAbsPath, 54 

GetActiveCamera, 60 

GetActiveCameraPos, 60 

GetApplication, 46 

GetAtomFromString, 57 

GetBack, 44 

GetBag, 56 

GetBagID, 53 

GetBreakFlag, 59 

GetCameraDistance, 41 

GetCameraPosition, 41 

GetCameraSQRDistance, 41 

GetCategory, 46 

GetChild, 56 

GetChildren, 56 

GetChildrenCount, 56 

GetCLSID, 46, 51, 52 

GetConfig, 45 

GetCount, 46 

GetDescription, 44 

GetDistributionRight, 51 

GetDocument, 45 

GetEventProcessing, 59 

GetExportedField, 53 

GetExportedFieldCount, 53 

GetExportedFieldIDByName, 

53 

GetExternalEventsNode, 60 

GetField, 47, 49 

GetFieldByName, 47, 49 

GetFieldCount, 48, 49 

GetFieldID, 50 

GetFieldInfo, 48, 49, 50 

GetFieldName, 51 

GetFieldOfView, 44 

GetFieldType, 51 

GetFileLoader, 57 

GetFront, 44 

GetGUID, 53 

GetHostID, 45 

GetHwnd, 60 

GetIcon, 51 

GetIconDLL, 46 

GetIconID, 46 

GetIcons, 52 

GetIconsDib, 53 

GetID, 56 

GetIdOfName, 49 

GetINode, 57 

GetInstanceCount, 53 

GetJoystickCapabilities, 55 

GetJoystickData, 55 

GetJoystickProperties, 55 

GetKey, 47 

GetLastInput, 50 

GetLicenseKey, 45 

GetLicenseOptions, 58 

GetLicenseStatus, 45 

GetLink, 57, 59 

GetLocalTransform, 44 

GetLogEvent, 58 

GetLongDescription, 53 

GetMFCount, 49, 51 

GetMFElement, 49, 51 

GetMFSpan, 49 

GetModuleCLSID, 46, 58 

GetMouse, 56 

GetName, 56 

2.5 61

GetNewSimulation, 47 

GetNextModule, 45 

GetNodeCount, 57 

GetNodeInfo, 45 

GetNodeInfoCount, 45 

GetNodeName, 46 

GetNoIniTreeNodes, 44 

GetNoJoysticks, 55 

GetNoTreeNodes, 44 

GetOwner, 50 

GetParent, 56 

GetParentBag, 53 

GetParentID, 57 

GetParentNode, 49 

GetParentPtr, 57 

GetPath, 54 

GetPositionFirstModule, 45 

GetPropertyEditorCLSID, 40 

GetPrototype, 46 

GetPrototypeDefinition, 59 

GetPrototypeName, 52 

GetPrototypes, 47 

GetRefCount, 57 

GetReference, 54, 57 

GetReferenceCount, 54 

GetRefTarget, 57 

GetRegInt, 47 

GetRegString, 47 

GetRootNode, 46, 47 

GetRoutesAge, 57 

GetSearchPath, 59 

GetSelectedNode, 46 

GetSettings, 45 

GetSFBool, 49 

GetSFColor, 49 

GetSFFloat, 49 

GetSFImage, 49 

GetSFInt32, 49 

GetSFNode, 49 

GetSFRotation, 49 

GetSFString, 49 

GetSFTime, 49 

GetSFVec2f, 49 

GetSFVec3f, 49 

GetShortDescription, 53 

GetSIMDIR, 54 

GetSimFileName, 54, 55 

GetSimFileNameLenght, 54 

GetSimulation, 46 

GetSimulationInstance, 53 

GetSimulationRoot, 46 

GetSimulationState, 60 

GetSplitPaneReinitInfo, 51 

GetStandardKey, 47 

GetState, 61 

GetStatisticsOn, 44 

GetStringFromAtom, 57 

GetStringValue, 50, 51 

GetSubBag, 53 

GetSubPrototypes, 46 

GetToken, 45 

GetUserData, 53 

GetUserList, 45 

GetUserName, 45 

GetValue, 50 

GetVariant, 50 

GetViewport, 44 

GetViewPosition, 45 

GetViewReinitInfo, 51 

GetVKey, 55 

GetVKeyPresses, 55 

GetWorldTransform, 44 

HandleActivate, 60 

HandleMove, 60 

HandlePaint, 60 

HandleResize, 60 

HasNonExportableExternalLin 

ks, 52 

HideView, 45 

IAgent, 44 

IAgentFrame, 44 

IAgentFrame2, 44 

IAgentSimulation, 44 

IAgentViewport, 44 

IAutApp, 45 

IAutDoc, 46 

IAutNodeInfo, 46 

IAutPrototype, 46 

IAutPrototypes, 46 

IAutSettings, 46 

IAutSimulation, 47 

ICEonConfig, 47 

IChainSimulation, 47 

icon, 26 

IDegreeOfFreedom, 47 

IDeviceKeyboard, 47 

IEnumNodes, 47 

IEonDual, 47 

IEonEvent, 49 

IEonField, 49 

IEonField2, 50 

IEonField3, 50 

IEonFieldDual, 50 

IEonInsertable, 51 

IEonModule, 51 

IEonObject, 51 

IEonObject2, 52 

IEonPropertyEditor, 52 

IEonPrototype, 52 

IEonSingleton, 53 

IEonSingletonFactory, 53 

IExternalEvents, 53 

IExternalEventsNotifySink, 

54 

IExternalReference, 54 

IFileLoader, 54 

IFileLoader2, 54 

IFileLoader3, 54 

IGUIMotionModel, 55 

IJoystick, 55 

IJoystickState, 55 

IKeyboard, 55 

IKeyboardState, 55 

ILinkIterator, 55 

IMakePersistant, 55 

IMouse, 56 

IMouseState, 56 

InactivateGUIMotionModel, 

60 

IncIniCounter, 44 

IncrementVisualAgeCounter, 

60 

InitClass, 40 

Initialize, 52 

INode, 56 

INodeBag, 56 

INodeBagAge, 57 

INodeBagFiles, 57 

INodeBagIterator, 58 

INodeBagIteratorFactory, 58 

INodeIterator, 58 

INodeLicense, 58 

InsertRef, 57 

Installation, 4 

Interfaces, 26 

InternalEventsProcessed, 49 

InternalGetField, 40 

IPCLogQueue, 58 

IPrototypeDefinitionHolder, 

59 

IReference, 59 

IRouteManager, 59 

IRouteManager2, 59 

IRunControl, 59 

IsClicked, 45 

IsDemoMode, 45 

IsDirty, 52 

ISettingsServer, 59 

ISettingsServer2, 60 

ISimulation, 60 

ISimulation2, 60 

ISimulation3, 60 

ISimulationEONXEvent, 60 

ISimulationExternalEvents, 

60 

ISimulationMotionModel, 60 

ISimulationRenderEvents, 60 

ISimulationRenderEvents2, 

61 

ISimulationRenderEvents3, 

61 

ISimulationStateEvents, 61 

ISimulationUpdateEvents, 61 

ISimulationWindowEvents, 61 

IsInitialized, 52 

IsLogTypeUsed, 59 

IsModuleLoaded, 45 

IsPersistentSave, 57 

IsRestartNeeded, 59 

IsRunning, 52 

IsSensor, 49 

IsValid, 55, 58 

ITraversal, 61 

IVersionInfo, 61 

ListenTo, 45 

Load, 50, 52, 56 

LoadFile, 54 

LoadFileToDisk, 54, 55 

LoadIcon, 52 

Loading and Saving, 25 

LoadLegacy, 52 

62 



Interfaces 

LockRender, 44 

Log, 58 

LogMessage, 45 

Macros, 62 

MergePath, 54 

Module licensing, 14 

Module Wizard, 27 

Module Wizard generated 

files, 28 

Modules, 12 

MotionNotify, 55, 60 

MoveChild, 40, 57 

MoveLink, 57 

MoveSubtree, 56 

Next, 47, 55, 58 

OnAddChild, 52 

OnCommand, 51 

OnConnect, 51 

OnCreateView, 51 

OnDeleteContents, 51 

OnDisconnect, 51 

OnEdit, 52 

OnEvent, 54 

OnFlip, 61 

OnGetReference, 40 

OnGetReferenceCount, 40 

OnInitialize, 40 

OnJoystickButtonChange, 55 

OnJoystickChange, 55 

OnJoystickPositionChange, 

55 

OnKeyboardChange, 55 

OnModuleListChanged, 51 

OnMouseButtonChange, 56 

OnMouseChange, 56 

OnMousePositionChange, 56 

OnNewChild, 52 

OnNewDocument, 51 

OnNewParent, 52 

OnOpenDocument, 51 

OnPostRenderViewport, 60 

OnPostUpdate, 61 

OnPreRenderViewport, 60 

OnPreUpdate, 61 

OnQueryDefWinPos, 51 

OnRemoveChild, 52 

OnRender, 61 

OnRenderSync, 61 

OnRenderTransparent, 61 

OnReset, 40 

OnSave, 51 

OnSetMotionModelImages, 60 

OnSetParent, 52 

OnSetReference, 40 

OnSimulationRun, 51 

OnSimulationStop, 51 

OnStart, 40 

OnStateChange, 61 

OnStop, 40 

OnUpdate, 51 

OnUpdateCommandUI, 51 

OnWindowSizeChanged, 61 

Paste, 57 

PendingEvent, 59 

Processing eventIn, 25 

Project IDL file, 25 

RegisterCallback, 59 

RegisterCommand, 45 

RegisterSplitView, 45 

RegisterToolbar, 45 

RegisterView, 46 

RegisterView2, 46 

ReleaseSimulationInstance, 

53 

RemoveChild, 56 

RemoveExportedField, 53 

RemoveMFElement, 50, 51 

RemoveRoute, 59 

RemoveSubBag, 53 

RemoveSubKey, 47 

RemoveView, 46 

RenderRef, 44 

RequestMotionModelImages, 

55 

Reset, 47, 52, 55, 58 

Run, 47 

Save, 50, 52, 56 

SaveAll, 56 

SendEvent, 53 

SendMessage, 46 

SendOutEvent, 54 

Serialize, 40 

Serializing, 25 

SetBack, 44 

SetBag, 56 

SetBreakFlag, 59 

SetDefaultWindowPosition, 

46 

SetDescription, 44 

SetDirty, 46, 49, 52 

SetEventProcessing, 59 

SetExportedField, 53 

SetFieldOfView, 44 

SetFront, 44 

SetHwnd, 60 

SetIcon, 52 

SetID, 56 

SetJoystickProperties, 55 

SetKey, 47 

SetLink, 59 

SetLocalTransform, 44 

SetLongDescription, 53 

SetMFCount, 50, 51 

SetMFElement, 49, 50 

SetMFSpan, 49 

SetMotionModelImages, 60 

SetMouse, 56 

SetName, 56 

SetNewSimulation, 47 

SetParent, 56 

SetPath, 54 

SetPrototypeName, 52 

SetReference, 54 

SetRegInt, 47 

SetRegString, 47 

SetSFBool, 49 

SetSFColor, 49 

SetSFFloat, 50 

SetSFImage, 50 

SetSFInt32, 50 

SetSFNode, 50 

SetSFRotation, 50 

SetSFString, 50 

SetSFTime, 50 

SetSFVec2f, 50 

SetSFVec3f, 50 

SetShortDescription, 53 

SetSimFile, 54 

SetSimulation, 52, 53 

SetStatisticsOn, 44 

SetStringValue, 50, 51 

SetSubKey, 59 

SetUserData, 53 

SetValue, 50 

SetValueFromField, 50 

SetVariant, 50 

SetViewName, 46 

SetViewport, 44 

SetVKey, 55 

SetVKeyPresses, 55 

SetWorldTransform, 44 

SeverLink, 57 

ShowView, 46 

SimFileNameLength, 55 

Skip, 47 

Start, 52 

Stop, 47, 52 

SwapChildren, 40, 57 

TouchField, 50 

TransformToFrame, 44 

TransformToWorld, 44 

Unadvise, 40 

UnexpandAllProtoypes, 53 

UnlockRender, 44 

UnRegisterCallback, 59 

Update, 44, 60 

UpdateAllViews, 46 

UpdateLink, 59 

UseCurrentSubKey, 60 

UseLogType, 59 

Using DirectX, 25 

ValidateField, 40, 50 

ValidateNewChild, 52 

Version information macro, 

62 

Visual Studio, 5 

Wizard generated files, 28 

Wizard-generated files, 23 

Wizards, 21 

2.5 63

Introduction to EON SDK - Construction IT research at VTT

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?