Introduction to EON SDK

Jan 2002

Copyright EON Reality, Inc. 2002

Table of Contents

Table of Contents
User Guide
Table of Contents

Introduction

Installation

EON SDK Basics

Wizards

20

Techniques

30

Introduction

37

Nodes

38

Classes in EON SDK

39

Modules

41

Interfaces

42

Macros

60

Index

61

EON SDK 2.53.0

Users Guide
Introduction

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 onethe 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. Modulesand even
individual nodescan be license-protected with EON SDK, permitting
third-party developers to create specialized EON Studio plug-ins.

2.5

User Guide
Installation

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

System Requirements
Processor

Memory

Disk space

Operating system

Intel Pentium 75
(minimum)

16 Mb

7 Mb (minimum)

Windows 95/98

Pentium 166 MHz

(recommended)

32 Mb

10 Mb (with examples)

Or
Windows NT 4.0 with Service Pack 3 or
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.
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.

Installing DirectX SDK

To work with nodes that employ graphicssuch as 3D objects (meshes)you
will need Microsofts 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

EON SDK 2.53.0

User Guide
Installation

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 Studios 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

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

Run-time Mode

Scen Node
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

EON SDK 2.53.0

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

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 nodeits 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

EON SDK 2.53.0

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 nodes 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.)

The event model used in EON provides several benefits:

A node that sends events need not be aware of the receivers

identity.

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

senders identity.

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

senders, one receiver) are supported automaticallynew 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.

Execution model
The execution cycle of an EON simulations 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

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 nodes
OnInitialize() is called. The code in the nodes 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 Microsofts 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

EON SDK 2.53.0

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.
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.

Why use modules?

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 implementsfeatures 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.
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).

How to create a module

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

EON SDK 2.53.0

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 Microsofts 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 \ <ModuleCLSID>
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 \ <ModuleCLSID> \ <NodeCategory> \ <NodeName>
The entry for the node shall contain:

14

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

EON SDK 2.53.0

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(<NodeCLSID>, <NodeClassName>)
lines between the BEGIN_OBJECT_MAP() and END_OBJECT_MAP() macros in
the <Module>.cpp file.
The macro DECLARE_MODULE_CLSID(<ModuleCLSID>) will use <Module> 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 foramong several
other purposeslicense 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
automaticallyand unconditionallywhen 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 documentview
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 documentthe 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
documentsthat is, several sets of databut 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 intermediatormodules 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

EON SDK 2.53.0

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

EON Studio
1. Register message (IAutApp::GetToken )

Actual

4. Broadcast message to
subscribed module(s), using the
Win32 API SendMessage

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 useyou 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 messagesthose 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

EON SDK 2.53.0

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

EON SDK 2.53.0

User Guide
Wizards

9. Select which node group the node should belong to. New node groups
may be created.
10. Enter your nodes 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 nodes 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 nodes 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.

22

NodeName.H

EON SDK 2.53.0

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
See description in previous section.

STDAFX.CPP
See description in previous section.

RESOURCE.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
See description in previous section.

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.

2.5

PPNodeName.H

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

EON SDK 2.53.0

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

EONs 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

EON SDK 2.53.0

User Guide
Wizards

disable licensing (the licensing source code will just be commented

outnot 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.

STDAFX.CPP
This C++ source file is used to create the project's precompiled
header file (.pch).

RESOURCE.H
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

EON SDK 2.53.0

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 objects
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 objects
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 <stdio.h>
#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
);
if (FAILED(hr))
{
CoUninitialize();
return -1;
}
IUnknown* pUnk2 = pUnk1;
ULONG lRef = pUnk2->AddRef();
printf("Reference counter = %d\n", lRef);
lRef = pUnk2->Release();
printf("Reference counter = %d\n", lRef);
lRef = pUnk1->Release();
printf("Reference counter = %d\n", lRef);
CoUninitialize();
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

EON SDK 2.53.0

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 <stdio.h>
#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 T>
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<T> &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 <stdio.h>
#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 main(void)
{
int a, b;
printf("Creating pointers:\n");
CSmartPtr<CMyClass> pSmart1 = new CMyClass;
CSmartPtr<CMyClass> 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

EON SDK 2.53.0

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
02: AddReference: Reference count = 1
03: AddReference: Reference count = 1
04:
05: Testing pointers:
06: Silly = 42, Smart1 = 42
07:
08: Assigning pointers:
09: ReleaseReference: Reference count
10: CUnknown object destroyed!
11: AddReference: Reference count = 2
12: ReleaseReference: Reference count
13: AddReference: Reference count = 2
14:
15: Release pSilly
16: ReleaseReference: Reference count
17:
18: Out of scope!
19: ReleaseReference: Reference count
20: CUnknown object destroyed!
21: ReleaseReference: Reference count
22: CUnknown object destroyed!

= 0
= 1

= 1
= 0
= 0

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
#include
#include

<stdio.h>
"shlobj.h"
"objbase.h"
"atlbase.h"

int main(void)
{
HRESULT hr = CoInitialize(NULL);
if (FAILED(hr))
{
CoUninitialize();
return -1;
}
// Start code block
{
CComPtr<IShellLink> pSLink;
//IShellLink* pShellLink;
// CoCreateInstance calls AddRef
hr = CoCreateInstance
(
CLSID_ShellLink,
NULL,
CLSCTX_INPROC_SERVER,
IID_IShellLink,
(void **) &pSLink
);
if (FAILED(hr))
{
CoUninitialize();
return -1;
}
CComPtr<IPersistFile> pPF1;
hr = pSLink->QueryInterface
(
IID_IPersistFile,
(void **) &pPF1

34

EON SDK 2.53.0

User Guide
Techniques

);
if (FAILED(hr))
{
printf("Query for IPersistFile failed!\n");
CoUninitialize();
return -1;
}
CComQIPtr<IPersistFile, &IID_IPersistFile> pPF2(pSLink);
if (!pPF2)
{
printf("Query for IPersistFile failed!\n");
CoUninitialize();
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
CoUninitialize();
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 dont 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

EON SDK 2.53.0

Reference Guide
Introduction

Introduction
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 sectionsone 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.
The module section contains a list of COM interfaces used in EON SDK.

General
Data types
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

Integer

SFInt32

An integer value

Range
[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

Same as Double

Rotation

SFRotation

Four floats: rotation around an axis,

measured in radians; the axis is
defined in (x,y,z) coordinates

Same as Float for each component

Image

SFImage

Placeholder for an arbitrary byte

vector

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

Reference Guide
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.

38

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

EON SDK 2.53.0

Reference Guide
Classes in EON SDK

Classes in EON SDK

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

Reference Guide
Classes in EON SDK

EonFindNodePath
EonFindNodeWithInterface
EonGetName
EonGetParentFrame
EonGetParentRMFrame
EonGetPath
EonGetRoot
EonGetSimulationInstance
EonHasInterface
EonLoadFileToDisk
EonReleaseSimulationInstance
EonReportError
GetCameraDistance
GetCameraPosition
GetCameraSQRDistance

40

EON SDK 2.53.0

Reference Guide
Modules

Modules
Interfaces for EON Modules
There are several COM interfaces that will interact with the modular
system.

2.5

41

Reference Guide
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

EON SDK 2.53.0

Reference Guide
Interfaces

IAgent
Update

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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

Reference Guide
Interfaces

GetModuleCLSID

IPCLogQueue
Log
GetLogEvent

56

EON SDK 2.53.0

Reference Guide
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

Reference Guide
Interfaces

ISimulation
GetHwnd
SetHwnd
Update
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

EON SDK 2.53.0

Reference Guide
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

EON SDK 2.53.0

Reference Guide
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

2.5

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

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

62

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

EON SDK 2.53.0

Reference Guide
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

2.5

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

63