WO2003081389A2 - Visual application development system and method - Google Patents

Abstract

A method and apparatus for a visual toolset (100), executable file format (102), execution engine (108), and server platform (125, 175) enabling people who are not programming experts to build and deploy robust software applications (104) in an all visual environment without traditional coding is disclosed. Software applications built using the invention include client-server applications (102, 104-107, 110) and multi-user groupware and shared-space applications wherein multiple users on different devices (130) interact within the same virtual space within the same application in real-time.

Description

VISUAL APPLICATION DEVELOPMENT SYSTEM AND METHOD

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

This application is related to and claims priority from U.S. Application Serial No. 60/366,474 filed on March 20, 2002 which is incorporated herein in its entirety by reference.

FIELD OF THE INVENTION

The present invention pertains to the field of electronic software development, deployment, and operation, including, more specifically, a true visual programming paradigm for improved development of client-server networked software.

BACKGROUND OF THE INVENTION

Programmable electronics began with humans creating instructions for computing devices using a series of 1 's and 0's called machine code, that reflected the electronic circuitry and how it would perform low-level functions such as getting a number from storage, adding two numbers together, or comparing two to determine if one was larger than the other. All software was derived from such low level instructions. Initial improvements were made when simple English like commands such as "add" and "subtract" were used which the string of 1 's and 0's previously used. This new programming "language" was called assembly language. The next stage of improvement saw multiple low-level computer instructions being encompassed in a single instruction, typically of longer and more elaborate construction and syntax.

Over the past ten years improvements in software development has proceeded with three, often parallel goals, achieving varying degrees of success. These are: object-oriented programming to enable greater code reuse and ease of project management; serialization - a methodology to request, encode and decode objects for efficient network transportation; and visual programming environments designed to empower a greater number of software developers - especially those without advanced training in computer technology. Unfortunately, while software engineers and academicians working toward one of these three fields often crossed-over into other the tracks, no prior invention has incorporated all three as primary goals. Thus, there is a need for an improved software development system and method which incorporates object-oriented design, serialization and a visual environment.

SUMMARY OF THE INVENTION

These needs and others are satisfied by a visual software application development system and method according to the present invention. As a result of the invention disclosed and claimed herein, non-programming experts can create sophisticated applications, including networked applications and shared-space or groupware applications wherein multiple users on different devices interact within the same virtual space within the same application in real-time.

This invention incorporates aspects of object-oriented programming, serialization and a visual programming environment into practice. Prior to this invention, software development required expert programmers - people skilled and knowledgeable in computers, networks, and textually based programming languages. The invention includes a visual toolkit which allows domain experts, with little or no programming experience and training (including game designers, educators, corporate trainers, business process experts) to build multi-user shared space seamlessly portable client-server applications. The invention is a purely visual software development system accessible to users who have not, and need never, write a line of code, while being powerful enough to be attractive to and of service to highly experienced software developers. Additionally, the invention includes serialization techniques and a new form of executable that enables the same executable to run across many different devices.

One advancement in software development has been Object-oriented technology: the encapsulation of both code and data into "software objects" which developers may share and combine to build more complex applications at reduced costs. Using such objects, coders access the "entry" points - often called interfaces - and callback functions, from within their own code files. The invention includes a toolset with various components. Each component, be it a run-time visual (such as a button) or a purely logical component (such as a calculator), has named input and output events which developers "wire" together by visually drawing a line to connect them to each other, thereby building application logic. Users never have to edit source code to implement events (i.e. calling functions and passing parameters) because no source code is ever generated. The invention automatically handles method invocation and data transport within its own visual environment. In fact, an application under development with the invention resembles an electronic schematic diagram with groups of circuits summarized by their relevant function into easier to comprehend building blocks. With the increasing importance of networked computing (see ARPANET, NSFNET, Internet, the Web, mobile communications), software developers have needed an efficient method for transporting complex pieces of data across networks for use on multiple platforms. To this end, there are a multitude of markup languages and standards such as HTML, WML, XML and CORBA, which require users implementing them to write code. The invention improves upon conventional systems and methods by encoding data components and logical connections between them into one streamable format for convenient network transport or persistent storage.

Besides eliminating the need to write code, the invention offers a distinct advantage over existing standards in that the application logic rests in the actual encoded objects (which map directly to the visual layout) rather than in the machine executable. So while conventional serialization techniques work on the principle of a "smart" client, requesting an object with a preconceived - and thus limited - use for it, a device running an execution engine according to the present invention is a far more powerful "dumb" platform where the requested objects may do whatever was encoded within them. Part of the invention is an application that includes an execution engine which decodes a set of connected components and triggers application logic upon input from a user, a network message or launch component. Once an application has started, it can use this same mechanism to decode additional objects which may serve as executable logic and/or simple network messages.

Preferably, the serialization of the present invention is geared toward easy multi-platform porting to run across a very wide range of computing and electronic devices. An execution engine may be ported to most any language for most any platform. The device-specific execution engine decodes only the appropriate portions of the executable. For example, a PVColor component (object) can have an alpha color value - which some portable devices (mobile phones) might not use. The device specific execution engine on such devices can be configured to simply ignore the encoded value.

While great strides have been made in object-oriented programming and serialization, software development has fallen woefully short in creating a visual environment with the low barrier to entry non-programmers need and the flexibility and power programmers demand. Current visual systems (including Microsoft's VisualBasic, Netscape's visual Java tool, Sun's Forte, and PowerBuilder,) are mostly screen layout aids, which generate source code based on the final arrangement of graphical widgets. Once the layout is complete, adding all but the most basic application logic (e.g. pushing a button closes a window) requires developers to drop out of the visual environment and to edit textual source code. This approach has many shortcomings which the present invention improves upon. Such pre-existing visual code generation tools severely limit their use to those with extensive coding experience or training. Also, experienced programmers are hampered by the source code such tools generate, as the idiosyncratic code structure and formatting of such code makes it as difficult or more difficult to read and edit for the user than another programmer's code. This often creates more work to perform tasks the developer could more succinctly program without the visual code generation tool. Additionally, once such source code edits have been made, the relationship between the pre-existing visual layout and the new source files is effectively destroyed, frequently resulting in an inability to easily, efficiently and reliably use the visual tool for further code modification or maintenance. Other visual tools are highly specialized for a specific domain, and require a large number of modules (frequently stand-alone programs) to provide functionality within this domain, and their visual programming serves primarily as dataflow between these modules rather than as a highly flexible general tool for a wide variety of software development. Examples include National Instruments Labview, AVS (Advanced Visual Systems), and Khoros' Cantana. Additionally the invention provides for the development of advanced client-server applications and shared-space applications which are not generally covered by these domain tools. The invention's smaller set of components and far wider functionality and domain applicability yield an easier learning curve (fewer pieces) for a wider functionality.

Preferably, with the invention, all logical interaction, application graphical layout and user interface, and all visual tool interface functionality can be kept in the same files used by the visual toolset. The visual toolset and environment can be the only environment ever required for software development and maintenance. Users never have to edit source code because no source code is ever generated.

The invention's atomic components and much of the toolset can be implemented in high level languages, as can existing execution engines. Nevertheless, the invention's toolset allows its users to create components using the tool itself. Whether the components were hardcoded or made with the toolset is completely transparent to the user of the components, as their appearance and functionality is identical.

The flexibility of high level languages is sometimes measured in their ability to create applications which mimic themselves. After all, FORTRAN and C compilers are often developed using FORTRAN and C. Similarly, the invention is sufficiently flexible and robust to create custom implementations of the invention using nothing but the pre-existing implementations of the invention itself.

The invention's component library can consist of objects needed to encapsulate most any type of program design - math, text manipulation and all logical and sequence operations. Additionally, the invention can include a full suite of Graphic User Interface components and tools to interact with SQL databases, file systems and networks on multiple protocols, be it persistent state connections via the inventions multi-space servers, HTTP, SMTP, WTCP, or others.

The invention toolset can be made to have its functionality readily expanded with more components, generated within the toolset itself, as well as with high level languages.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig 1 is a block diagram illustrating a high-level functional description of one embodiment of the invention in which the toolset and components generate executable files which can run as multiple software processes on a wide range of computing and electronic devices and on the server side of a client-server application deployed across an arbitrary network.

Fig 2 is a block diagram illustrating a functional description of one embodiment of the invention in which software can be created and operated across a network.

Fig 3 is a block diagram illustrating a functional description of one embodiment of a toolset, toolset graphical user interface (GUI), and working development environment aspects of one embodiment of the invention used by a person to build and maintain software applications without traditional coding.

Fig 4 is a block diagram illustrating one embodiment of the method by which toolset files and executables can be generated or saved from use of the visual toolset of Fig 3 to build software using components in the visual interactive programming process according to one embodiment of the present invention.

Fig 5 is a flowchart depicting one embodiment of how user actions in the toolset shown in Fig 3 can produce values within the executable files shown in Fig 4.

Fig 6 - Network, is a block diagram illustrating a functional description of one embodiment of a high-level process by which executables shown in Fig 4 and components can be configured to talk (pass messages and data) over one or many different underlying networks using either persistent connections or polling. Fig 7 is a block diagram illustrating a functional description of part of one embodiment of the present invention that loads and runs an executable file shown in Fig 4 to create a running software process.

Figs 8 a and 8b are block diagrams illustrating a functional description of one embodiment of the server software that provides a platform for specific server-side applications generally created within the toolset shown in Fig 3, and which delivers and communicates with client- side applications generally made with the toolset to form networked software applications.

Fig 9 is a block diagram illustrating a functional description of one embodiment of an extensible server platform supporting the addition of arbitrary protocol gateways for networking, communication, and data.

Fig 10 is a block diagram illustrating a functional description of one embodiment of an extensible server platform, which includes key community capabilities for multi-user and shared-space applications and which supports the addition of arbitrary community features to coordinate and facilitate multi-user interactivity, and makes these capabilities available to the software developer using the toolset shown at Fig 3, without the user needing to understand how these capabilities are implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMODIMENT In accordance with the present invention, a visual software application development system and method is described that provides distinct advantages when compared to those of the prior art. The invention can best be understood with reference to the accompanying drawing figures. Referring now to the drawings, Fig. 1 depicts a functional overview of one embodiment of the present invention showing a visual toolset 100 that can be used by a person to generate arbitrary software applications 105, 106, 107 and of the user's design which can run as multiple software processes 108 on a wide range of computing and electronic devices 130 and on the server side 125 of a client-server application using a scalable server platform 120, as a server side software application 110 deployed across an arbitrary network 115 such as an Internet, WAN, cable TV, infrared, mobile phone or other communication network. These applications 105, 106 and 107 maybe stand-alone (client only without need of a network), or may be client-server networked 105, 106, 107 and 110 applications, or may be multi-user shared-space client-server 105, 106, 107 and 110 in nature including functions of groupware, multi-player games, whiteboards, collaborative systems, group education and training, and other robust applications for virtual application space or graphical display or text display where user actions change the display and/or user interface and/or options of other users in real-time. Additionally these applications 105, 106 and 107 may communicate with other arbitrary servers and applications 175, such as web services, authentication servers, enterprise servers, location servers (such as global positioning systems) or any other application which can send or receive data, instructions, or objects over a network. The devices 130 supporting the application may be most any device supporting programmable instruction including: computers 135; mobile phones 140; embedded electronic systems 145 with instruction sets fixed at manufacture not readily altered including such devices as digital watches, microwaves, refrigerators, controllers used in manufacturing, monitoring, or distribution; ; interactive television delivered 150; vehicles and engines 155 including electronics involved in operation, tracking, monitoring, or diagnostics of any engine or power source (electrical generators, motors, turbines) such as commonly found in cars, trucks, planes, ships, power plants, or industrial equipment; wearable computers 160 made to be worn or incorporated into clothing, glasses, headsets or into the body 160, typically for entertainment, business, medical, health, monitoring, communication, or tracking purposes; personal digital assistants (PDAs) 165 including handhelds such as Palm

Pilots and other mobile computers with display and user input; and other networked electronics 170 which contain an instruction set and which can communicate across a network.

Fig. 2 depicts a functional overview of one embodiment of the invention as used to create software 220 and 275 and operating it across a network 235. A person uses a process 200 (enlarged in Fig 5) consisting of selecting components 210, which are software building blocks, by using an interactive visual toolset with graphical user interface 205 (enlarged in Fig 3) to produce software applications in the form of executable files 215 (enlarged in Fig 4) that can be client side 220 and/or server side 275. These executable files (215, 220, and 275) can be loaded and run by an execution engine (225 and 280) (enlarged in Fig 7). The execution engine (225 and 280) may obtain these executable files (215, 220, and 275) locally from the machine it runs on, or may request them over the network 235 from the server platform 270. In addition, the code which implements the components 210 necessary to run the executables (215, 220, and 275) may be local or may be obtained via the network 235, or may be both local and remote with the execution engine 225 checking with the server platform 270 for the most current component 210 version to run and receiving any updated component versions. The executable (215, 220, and 275) can then be run by the execution engine (225 and/or 280) (which may be different implementations running on different operating systems and different hardware yet still communicating) to create one or more software application processes (230 and/or 285) running on most any hardware device as shown in Fig 1. These application processes (230 and/or 285) may communicate over an arbitrary network 235 such as an Internet, WAN, cable TV, infrared, mobile phone or other communication network. The communication is accomplished using a network protocol (Fig 6) implemented within the software application as built with the visual toolset 205 with network components enabling reliable communications over any arbitrary network. These applications 220 and 230 may be stand-alone (client only without need of a network), or may be client-server networked (230 and 285) applications, or may be multi-user shared-space client-server in nature (230 and 285) including functions of groupware, multi-player games, whiteboards, collaborative systems, group education and training, and other robust applications for virtual application space or graphical display or text display where user actions change the display and/or user interface and/or options of other users in real-time. Additionally, client applications 230, server applications 285, and client-server applications ( 230 with 285) may communicate with other arbitrary servers 290 and applications 240, such as web services, web browsers and plug-ins, authentication servers, enterprise servers, location servers (such as global positioning systems) legacy systems, or any other application which can send or receive data, instructions, or objects over a network. Importantly, hardcoded clients 240 enable optimized software in terms of application size, execution efficiency (such as may be needed for a wireless handset or small embedded system, or where no execution engine has been implemented) to be used and still communicate with server applications 285 and with other client applications made with the visual toolset 230 as well as other hardcoded clients 240.

One example of an application made in accordance with the present invention is a 4-player card game of Hearts with text chat that can be played head-to-head simultaneously by the 4 players: player one using a hardcoded J2ME (Java 2 Micro Edition) client 240 for a mobile phone communicating to a server application 285 using UDP; player two using a server-side application 285 generating WML (Wireless Mark-up Language) for a mobile phone with a WAP (Wireless Application Protocol) browser delivered with UDP; player three using a server-side application 285 generating HTML (Hyper-Text Mark-up Language) for a standard web browser communicated via HTTP (Hyper-Text transport Protocol) on a PC running Windows; and the fourth player using a client application 230 as an executable 220 running on an execution engine 225 installed on a Macintosh and communicating with a server-side application 285 using sockets or TCP/IP. There may be from 1 to 4 server-side applications depending upon the developer's implementation preferences and style. The system could be configured to have the HTML and WAP server applications 285 act as proxy clients for their players and join into a game via the community infrastructure 260 to a master server-side application 285 that would maintain the game state and the game's shared-space of the cards, player positions, turn, score, and status. The master server-side application 285 could communicate directly with the players on the hardcoded J2ME client 240 and the client application 230 without the need of a proxy.

Importantly, hardcoded server side applications 290 enable legacy, optimized, or third party software to be deployed on the server platform 270 and make use of the community infrastructure 260, server gateways 255, other systems 265, general security layer 250, and general firewall layer 245, while still communicating with server applications 285 and with other client applications made with the visual toolset 230 as well as other hardcoded clients 240.

In an alternative example application to the one described above, player two could instead be using a using a hardcoded server-side application 290 generating WML (Wireless Mark-up Language) for a mobile phone with a WAP (Wireless Application Protocol) browser delivered with UDP. This hardcoded server-side application 290 could be deployed on the server platform 270 and make use of a bandwidth and media management system 265 to deliver different sized screens and card images to different mobile devices. It could make use of the community infrastructure 260 for player login, dropout, ratings, rankings, tournaments, and challenge ladders. It could further make use of the UDP server gateways 255 for communication with the mobile handsets and TCP/IP gateways for communication with the master server-side application 285. It could make use of the general security layer 250, and general firewall layer 245 as well minimizing hardware, software, and operational costs.

The networked application may run behind or in conjunction with almost any network security system 245 including a firewall, router, monitoring agent or other. The server platform 270 provides for the use of a general security layer 250 to be employed as well, such as an authentication server (such as RSA, Kerberos, public key encryption). Server gateways 255 can be part of the server platform (including TCP/IP, UDP, sockets, SQL, HTTP, XML (extensible mark-up language), HTML, SMS (short text messaging system), MMS (multimedia messaging system), WAP, xHTML, NFS and other gateways may readily be added). The community infrastructure 260 (enlarged in Fig 13) can include key community capabilities such as player login and account management, player communication management (live connection, dropped connection, connection time-outs) which can be simplified for the developer by incorporation into the network components 210. Additionally, this supports the addition of arbitrary community features including tournament or class structures, challenge ladders, ranking, rating and grading systems, reporting and logging systems, user match-up, reward systems, advertisement servers, discussion groups, and other web community functions. The community infrastructure 260 makes these capabilities available to the software developer using the toolset (Fig 3), without the user needing to understand how these capabilities are implemented, frequently providing a simplified interface to these systems.

Other systems 265 can provide for the connection, configuration and or integration of additional systems into the operational server. Examples include custom or third party advertisement management software for; serving and tracking ads, customer profiling, billing and payment, and security such as authentication services, which may be integrated or accessed by a network connection.

Fig 3 is a functional description of one embodiment of the toolset, toolset graphical user interface (GUI), and working development environment aspects of the invention used by a person to build and maintain software applications without traditional coding by selecting and connecting components into circuit like diagrams which visually show the software application logic, display and graphical user interface. The toolset user 300 may be a programmer but may also be a person with little or no programming experience or training. Upon start a blank window, or canvas, is created by default for building a new Toolset file ( See also Fig 4). The user 300 selects the toolset mode 305 which is one of exit 399, build 310, run 365, or debug 380. If exit 399 mode is selected, the toolset application is closed after asking to save any open files. If build 310 mode is chosen, then the user 300 is shown the work space 335 and may perform any of the workspace functions 312-335 or may select a component 338 and be given the display and choices 342-354 for connecting components together 358. The user may load pre-existing toolset files 330 which will appear in their own window or the user may create a new blank canvas 326 for components. Any component canvas may be saved as a Toolset file or Executable. Collectively, all options and actions of the user in build mode 310 are part of the Visual Interactive Programming Process 359, an alternate view of which is provided in Fig 5. hi the work space 335, components are displayed and organized into groups by functional areas called trays. The trays 312 provide an easy means for the user 300 to find and select any one of the desired components. System help 314 is available to the user 300 on how to use the tool, on any tray or component, and by keyword or index. Floating tool panels 320 provide easy user configuration for functions such as specifying graphical layouts (X and Y coordinates of the current component location, height and width of current graphical display component size and precise alignment with other graphical display components, color by panel, color wheel, color table, RGB (red-green-blue), or other color specification system), input file name for graphics, animation, sound, table, or text (as is practiced in GUI builders and software drawing tools). The user is allowed to select 322 any other mode 305 from build mode 310. User may open a saved executable file 330, or open a new one that is empty (blank), or save one built in the toolset. Each file has its own display window for the configuration and connection (wiring) of components 312 into a circuit-like diagram which is the toolset representation (or equivalent) of the saved executable file 398.

When a component has been selected while in the build mode 310 the connecting components 358 options become active. When connecting components 358 the user is shown the input and/or output events for the selected component, as well as any settings it may have that the user may configure or values it accepts that the user may enter. This may include selecting an option, entering numbers, tabular data, formulas, or file names. When appropriate, system file search and selection capabilities are invoked to simplify this for the user. Tabular data may be entered by referencing an external file or via a pop-up spreadsheet style table that the user may edit. Additionally, the user is shown all previously selected, incoming and outgoing events previously configured while connecting components together. Additionally, the user is shown incoming and outgoing wires 350 connecting the currently selected component to other components with input and output connections (wires) visually represented differently by color, thickness, and/or number. Numbers on wires visible at this time correspond to numbers used for component incoming and outgoing events 346 for easy mapping of one to the other. Additionally when one is selected the active connection is highlighted for user convenience. The user may select a wire and delete it, or may select an output from a component and connect or wire that output event to another component 354. When a destination component (previously placed in the individual display window 326) is selected, the user is given events which may be triggered, and then may proceed to wire these to yet more components and thereby create logic, layout, and graphical user interfaces to build a robust software application saved as executable files 398.

The Run Mode 365 consists of several phases. The current user enters into run mode 365 by selection 305. The components in memory are saved into a temporary Toolset File 370. This intermediary file 370 is created on a pre-specified directory based on the current implementation of the toolset, Execution Engine and the underlying Operating System. Execution Engine is then invoked 372 with the full path of the temporary file as the argument. Execution Engine launches a new window. At that point the Execution Engine is instructed by the framework to open the temporary executable file and load all objects and data into memory. This step all can involve executing any native code or instruction sets embedded into the intermediary executable file. Such actions can cause the generation of new system events or graphical user objects to appear 374 in the window.

Debug mode 380 is similar to run mode 365 with the addition of capabilities to enable the user to step through the flow of data without the need to exit the toolset environment. The current user enters into debug mode 380 by selection 305. An intermediary file 385 is created on a pre-specified directory based on the current implementation of the toolset, Execution Engine and the underlying Operating System. This file is similar in structure and behavior to the intermediary file 370 created in the run mode 365 phase. The Toolset Visual Component Debugger then proceeds to open the file and load objects into memory 387 allowing application developers to effectively step through the application. Launching the debugger brings up a debugging options screen 389. This is the central hub of the debugging process. It is the instrument by which the application designer or developer can track the flow of logic and data through a file created with the Toolset. The Options screen includes several utilities that the user may need. Among the most important is the ability to add break points and to step through the flow of logic 391. Stepping through the component flow causes the application to launch and progress at the application designer's will. This includes the display of visual components and graphical user interface windows 394.

Fig 4 illustrates methods by which toolset files and executables can be generated or saved from use of the visual toolset to build software using components in the visual interactive programming process.

Both file types may actually be run by the execution engine and will create the same software process. Both file types can also be encoded and decoded using a proprietary method of encoding and decoding explained. The encoding and decoding schemes can consist of various steps that insure data integrity and persistence and either retain toolset information or optimize for execution. Toolset files are made for use within the toolset GUI and Environment and include serialized objects and data, where the data consists of screen location of components as well as size and key information about each object. These files may be run or a more optimized file type for running may be saved in the executable. The executables can be designed to be optimized for running in a production environment. They can be similar to Toolset files in their structure and content, however screen position and other visual data may be stripped out, making the file smaller, and also obfuscating it to prevent copying and editing by unauthorized parties. Additionally, compression can be invoked to make Executable Files still smaller in size to further speed network transmissions and to further reduce the executable's footprint, which is particularly valuable in limited computing devices such as mobile phones and embedded systems.

Encoding and decoding of toolset files and executable files involve applying encoding and encoding patterns and algorithms. New instances of objects can be created when needed to reconstruct and regenerate the originating file. The components can be laid out onto the toolset screen 400 by the user in the visual interactive programming process. This creates a working canvas of components all connected together via a series of visual connections for event transmissions or "wires". The user ,on completion of the creation procedures, can decide to save the file. The user has several options as to the type of file to be saved as 404, either a toolset source file or an executable or both. Toolset files can be used within the toolset and maintain information about the layout and configuration of components within the toolset. Executable files can be optimized for execution in a production or operational environment. Both file types can be similar, however there are two differences: 1) toolset files contain toolset development information whereas executable files typically do not, and 2) compression algorithms and schemes can be applied to executable files but typically are not applied to toolset files. In a production environment, executable files are the preferred file type for running applications of any kind. The steps involved in saving toolset and executable files are almost identical, each object can be serialized and key object information, such as object key, (408 for Toolset Files, 444 for Executables) can be written to persistent memory. Each object can have a unique key assigned in the encoding process. These keys can be used to reference the object in stages of development and deployment. The keys can be used to group objects of similar structure, thus making the execution flow more efficient. The keys can also be written to the file being saved. The core object can then be examined and its size can be written, the serialized object can then be written hence saving its current state (420 for toolset files, 456 for executables). All data currently residing in those objects (inner objects) can be numbered, totaled, and written to disk and preserved in their current state (424 and 428 for toolset files, and similarly 460 and 464 for executables). The process of saving a toolset files can include an extra unit of information to be saved per each visual component. This is the x/y screen position of the component. This can be used so that any organization the application developer has in terms of component layout within the toolset environment can be preserved, thus making future editing of the visual file easier.

Loading of toolset files and executable files can be opposite procedures than that of saving the file (440 for Toolset Files, 472 for Executables). This step can include utilizing the decoding methods and algorithms to reproduce the serialized object with the saved state. The file can be read into memory and its core parts are parsed in the following order. The object position can be read 478 for toolset files only; this allows the toolset to reconstruct the component at the last position placed. The type of the object can then be examined (480 for toolset files, 490 for executables). This determines the method of decoding to be used. The toolset files also can include another unique step; it can read the name of the object and any specific visual data to be displayed on the screen or the properties menu. A new instance of the object can be created 481 during this phase, and that instance can then be altered to resemble the state of the saved object, thus reproducing it. The object's size can now be read (482 for toolset files, 492 for executables); this includes any data that occurs within the actual visual components. The parsing can now move on to object data (483 for toolset files, 493 for executables), which can be loaded into memory. The inner components of class can then be analyzed (484 for toolset Files, 494 for executables). Then, the object key (485 for toolset files, 495 for executables) can be read. After that, the object id (486, 496) can be read. The object key and id can once again be used to verify the versioning type and consistency of the saved components versus the current build of the components in the operationally deployed server system.

Fig 5 is a flowchart depicting one way user actions in the toolset (Fig 3) produce values within the executable files. The process of building rich software applications in the toolset can be both simple and intuitive compared to coding, enabling developers with programming skills and those without programming expertise to create applications visually. The visual development approach also speeds development by allowing the developer to focus more on the problem at hand rather than the details of the implementation medium. The programming process involves the selection of components from a visual tray 504, containing a grouped set of components, and then placing 507 them on the screen. Placement control allows the application designer to arrange these components in an organized manner corresponding to the designer's approach to the problem and the development style. Once several components have been selected and placed 507 onto the canvas, the user can apply logic to connect these parts. This flow of logic can be the core execution path which is the software application.

Each component can contain both output and input event menus. The user can select an individual component then trigger an event to bring up either the input or output events menu.

On starting a component, the developer can bring up the output events menu 513 and can make a selection from events listed 515. A visual line appears on screen, the user 500 then connects 517 that line or "wire" to the second component; this causes the second component's output events menu to appear. The user selects the appropriate menu to "hook" the "wire" to 517. This causes the flow of logic to trigger that event when the outgoing event of the originating component occurs. The "wire" represents flow of logic between components. Once all the connections are made the user may select a component and edit its individual properties 512. The user can continue to add more components and make new connections or deletes or modifies existing ones as desired 519. At any time the user may test the current software application and quickly and easily jump back into build mode 519.

This rapid testing allows users to very quickly try and test, making software development more efficient. In build mode, the components may be moved or deleted as desired by the user, and graphical display and user interface components may be resized, recolored, or otherwise modified 520. In the development process the user may often select a component and view wires extending outwards from it to other components. However there are instances in which the user may want to know how the current component's events were trigged. This can readily be seen by invoking the toolset's show incoming wire command on the object. This command produces visual wires that are contrasting in color to indicate wires coming into the component, as distinguished from the color of those leaving it. This facilitates development by allowing a more efficient method of tracing the flow of data and logic.

Component Overview

A software development toolkit according to the present invention comprises various components which can easily be used by people with little or no programming experience to create working software applications. The components can be configured to use message passing. This has method is intuitive for non-programmers to understand. People inherently understand message passing as it fits with their view of the world, and the spoken language format makes building a sequence of events simple to follow and build. hi general a component is the encapsulation of:

1. Data.

2. Logic for processing data.

As well as one or both of the following:

1. Channels to receive messages and accompanying data from other components, i.e. Input events.

2. Channels to send messages and accompanying data to other components, i.e. output events.

What makes the encapsulation an enhancement from previous object-oriented concepts is that all interface, callback and customization is determined in the toolset visual environment without writing code. The toolset requires no code writing to develop sophisticated software applications, nor does it generate any, instead serializing components and logic data in a new binary executable format.

Component Communication

Communication between components can be represented in the visual environment as virtual wires between the two components. Upon firing, an output event of one component carries data to the input event of another &#8211 ; or the same ~ component. Because people can inherently understand the natural language describing the two events, they can develop complex logic without even realizing they are "programming".

Data within a component can be extracted via the "push" method, i.e. Shooting it out via one of the output events. Push can be highly convenient and efficient in some uses, but a completely independent series of logical events might be needed to fetch a value. For this, the component set include a Retriever which can query a component's data generally through an input event named "Return <data>" and deliver the value or reference data to one or more destinations - also referred to as a "reverse wire".

One aspect of the present invention includes a component which can take a single event and deliver it to multiple destinations. In this case, the fan allows for delivery of a single event to multiple locations; two different visual text boxes. Various components can use this functionality. For instance, the Retriever component can be configured to deliver to multiple locations.

Data in Components

Components are not limited to simple data structures. One abstraction, called a DataCard, can be built using a construct (Index Card) recognizable to every non-programmer, allowing them to create custom data items. Items within the data card can include number, text and any kind of object (including other DataCards). To create new DataCards, a DataCardGenerator can be used which allows users to describe DataCards using a comma delimited format. The DataCardGenerator can also read tab or comma delimited files exported from any spreadsheet application. Card Piles in one implementation can be simple Java Vectors abstracted to something non-programmers can understand.

Integer guns and text fields also have simple data structures. Returning all the data is simple and sufficient. Other components, such as DataCards, have more complex internal data structures. To extract the right piece of data from the DataCard a component called a DataCard Interrogator can be used. Other complex components have their own equivalent interrogators.

Building New Components with the Toolset GUI and Environment

Using basic building blocks and components it is possible to build new richer components using the toolset GUI and environment itself. These components are called PVPlug and PVSocket. When the designer references an executable file using the PVPlug, the events are automatically passed into the PVSocket. The executable then behaves as if it is just another component written in a traditional programming language. These can sit on a tool bar or component tray and look no different than other components. Unlike visual tools that form data flow between what are otherwise hardcoded stand-alone applications, toolset users may open these components to better understand them or to modify them ~ all within the same environment without needing to be a programmer. This dissolves the hard barrier between domain experts without programming expertise and the expert programmers, improving development.

PVPlugs as Visual Extensions

There can be a distinction between visual and non-visual components. During build mode, components can be visible to the designer. During run time, the non-visual components can be invisible.

PVPlug files may contain not only non- visual components, but also visual objects, which is a key advantage when building large or complex applications as it provides for a divide and conquer strategy in both development and testing. Additionally, it allows development and testing to be done in parallel (i.e. more people working on the same project). Also there is a benefit derived from the reuse of these subroutines.

There are multiple ways to make a PVPlug visible at run-time. One way is to simply use the event "Open In Window". This will pop-up a window with the contents of the file referenced in the PVPlug file. Another way is a PVVisualContainer. The designer can retrieve the list of components from a PVPlug using a "Ret All Components" event. The list could then be delivered to the PVVisualContainer's "Set Component List" event. Change's to the PVPlug's visuals could then be referenced in the PVVisualContainer.

Component List

Below is a list of some sample components and their function according to the present invention

Calculator Calculator component is for accepting a standard math formula (such as "a + 2.5b = c") in textual form within the visual environment to allow for the easy implementations of algorithms and formulas while also maintaining them in a form users readily can identify and comprehend.

Comment Stores comments by the developer.

Cond. fr t Triggers events based on the value of an integer. Cond. Long Triggers events based on the value of a long integer.

Cookie h t. Returns information from a web cookie.

DataCardPile Stores and manipulates datacards.

DC Gen. Creates datacards, a versatile object for storing arbitrary data sets.

DC Inter. Returns information from a datacard.

Debug Outputs data to the system log for debugging and tracking.

Enumerator Enumerates a list of obj ects .

Fan An event splitter used to trigger multiple events.

Formula Performs complex math using standard math formulas and expressions.

Current embodiment uses two integers.

IntegerGun Stores and manipulates integers.

I.MachineGun Fires a series of integers.

Launch Triggers an event when the application initializes.

Lockers A Lockers component is an assortment of storage spaces each identified by a key with a value or object within them. The Lockers component is able to store any type of data, including, but not limited to, numbers, strings, list, datacards, datacard piles and objects.

LongGun Stores and manipulates long integers.

Mail Sender Sends e-mail to an SMTP server.

ML Gateway Sends and receives mark up language content HTML/XML/WML etc.

Msg. Router Delivers network data within the application.

Msg. Sender Sends network data across a network.

Musket Fires an object once, requiring an explicit reset to fire again.

Null Check Checks if an object is null.

PV Client Receives network data from the PV Server.

PV Plug Used to contain custom events for easier access.

PV Server Sends network data to the PV Client.

PV Socket Used to access plug events. RandomNum Generates a range of random numbers.

Retriever Retrieves data and delivers it to multiple sources.

Schat A SChat is used to control the input and output of chat to the server. It performs the handling of input and output chat messages from users.

SMS Gate. Sends and receives SMS messages.

SMS Int. Returns information from an SMS message.

String h t. Returns information from a string.

StringTeam Manipulates two strings.

SQL Inter. Provides access to an SQL server.

Switch Changes the flow of events on demand.

TextStore Loads and manipulates bodies of text.

Timer Fires an event at set intervals.

Ustoreit Permanent data store of arbitrary objects on client or server using underlying third party file system for reliable scalable storage and fast retrieval.

Wall Clock Returns time related data.

See Appendix A for more details regarding the various components shown in this list.

Extensibility Advantages:

Adding New Components to Extend the Toolset GUI and Environment

While most board, strategy, and classic games (i.e. excluding arcade or 3D action games) and applications can be built with components listed above, other applications (including 3D graphics, very highly optimized applications, and those for specialized or limited devices) may require or substantially benefit from custom components. In each domain, such as multiplayer board games, 3D action games, education, telematics, enterprise, and web applications, the user visual and interactive software development process can be facilitated by creating additional high-level components that, can capture commonly used functions, processes, and interfaces to make common software development tasks in their domain easier and more efficient. The component set described encompasses the high-level components for board, strategy, and classic games. An open extensible API to enable easily integration with legacy systems and third party applications.

In other cases adding custom components could be desirable as a means of readily incorporating external code (legacy code, legacy applications, and software application interfaces to other software, systems and third party applications such as web-based services) into the toolset GUI and environment in order that new software may be developed entirely within the toolset and environment without needing to port or re-engineer existing software that is functional and operational. This open extensibility is the advantage of invention power because it improves the effectiveness for the development of real software applications in the real world by tackling the difficult migration and transition problem when moving from existing systems and a set of technologies to new or modified systems implemented with the invention and other third party software.

Encode/Decode Advantages for Component Structure and Executable Fonnat (Fig 4)

Saving space and time in the encode/decode process and executables. hi the encode and decode process, an id can be assigned to objects which are used multiple times so that they may be incorporated by their reference id rather than duplicated. The advantage of this is that it reduces file sizes and speeds network transmission. The id is a special number that can be generated by the system during encoding. This id is a unique id assigned to individual objects when they are encoded. Each object is only encoded once. This saves space and time in the encode/decode process. This is transparent to users.

Backward compatibility in the encode/decode process and executables.

An enhancement to this comes from getVersion(), providing an internal number a person can use to identify which version of the component code actually encoded the object. If a user creates a file with a component in it and later wants to change the encoding elements of the component, will not have to invalidate the file, instead he can simply change the version. When a user implements the decodeltem, he can check to see if the component is the old version and if so, he could convert it to the new version and all future saves would be with the new version of code. (Note that individually deployed systems with frozen configurations could elect not to add updates). This allows developers to change the code of a component, provide automatic forward migration incorporating the new improvements or bug fixes, while maintaining backwards compatibility because code changes will not break existing executables. Forward compatibility and automatic code migration in the encode/decode process and executables.

An enhancement to this comes from the ds.skipltem(id). If a component does not recognize the key, then it can tell the DecodeStream to skip over the item being decoded. This might occur if a programmer has two different users using older and newer versions of the component. If the user of the newer component sends a file to the user with the old code, the component would still be readable. This maintains backwards compatibility while providing for a migration path forward for improvements.

Reverse Wire

The term Reverse Wire is used to refer to the ability of certain components to retrieve data from another component. Normally when a component is Wired to another component it is delivering something. If the component has this Reverse Wire capability it will retrieve the data first and then perform its normal sequence of wired events. This provides many advantages. A component, such as an integergun, can effectively be used as a datastore so that many different logical sequences can reference the datavalue by using a reverse wire (such as from the retriever component) to return the value. Without the reverse wire, the integergun may need to trigger the next step in the process, requiring the component to be used repeatedly, once for each different logic sequence. The reverse wire greatly simplifies the process of building software in the visual environment.

Debugging and Logging Advantages for Component Structure and Executable Format

An advantage in debugging and logging is enabled by setStatelnfo, which improves the debugging of client-server applications and shared-space applications. In one preferred embodiment, such tagged logging information from clients and server side processes or applications can be integrated to facilitate debugging by providing a smooth trace across the network just as though the client-server application was a single non-networked application.

Component Structure Details

There are multiple types of components you can build, visual and non- visual. This describes non- visual components first, but both can be configured to use the same event structure. One difference is that Visual components typically require more events to handle mouse and keyboard events and appearance issues.

Components can have multiple basic elements such as: Events and Encoding. Events are how users wire or connect two components together to create logic. Events can be further separated into input and output events. Encoding is how a component is saved and restored from a executable. Encoding is also how data is transferred along wires across a network connection.

Source Files

Each component may require multiple source files. For example, a component may use a component class and a Beanlnfo with a Buildlnfo interface. Beanlnfo should be familiar to anyone who has done JavaBean programming.

Interfaces

Each component is required to implement three different interfaces.

Streamable

PVComponent

Target

Streamable can provide the means for each component's encoding, decoding and storage in different media.

Target can contain a single method which enables various components to receive input events.

PVComponent can encompass three different state variables used by the various components.

Attributes

Attributes are data items that can be set on a component. For a designer to have access to it, the attribute must have a public get and set method. This can be a JavaBeans requirement and should be familiar to Java programmers. For instance, if a component needs to keep a score and the designer would like to set the score through the properties window, he could use the following two methods. public void setScore(int score); public int getScore();

When the system loads the component on startup, it scans the code for any methods starting with get and set. It parses the string after the get and set to describe the attribute in the properties dialog. The get and set methods for the attribute can be called automatically by the system when the designer views or makes changes to the attribute.

Encoding Encode/Decode is a mechanism by which a component can save its current state to a stream (executable file in memory or permanent storage/network/other) and restore its state later or on the other side of a network component.

There are multiple methods which can be implemented in the Streamable interface, for example int getVersion(); int getNumberOfEntriesO; void encode(EncodeStream es); void decodeItem(DecodeStream ds, int id, int key); getVersion() is an internal number that can be used to identify which version of the component code actually encoded the object. If a file is created with a component on it and the user later wants to change the encoding elements of the component, he doesn't have to invalidate the file, but can merely change the version. When he implements the decodeltem, he can check to see if the component is the old version and if so, he could convert it to the new version and all future saves would be with the new version of code. This allows programmers to change the code of a component and maintain backwards compatibility because code changes will not break existing executables. getNumberOfEntriesO is the number of entries a programmer intends to encode. If this does not match the actual number of entries encoded, the file will not decode properly. encode() is called when a component needs to write itself to a stream. All information that needs to be saved to restore the complete component state can be written to the EncodeStream (an internal class utilized by the PureVis tool, the PNRunner, and numerous components including PVPlugs, as is the DecodeStream). Each item can be identified with a unique key. The following sample would encode five different items, each with unique keys. For instance an integer uniqueld is written with the key 1, key 2 is a String and so on. public void encode(EncodeStream es)

{ es . writelnt( 1 ,uniqueld) ; es . writeString(2, aString) ; es.writeVector(3,aVector); es . writeHashtable(4, aHashtable) ; es. writeObj ect(5 , aTarget) ;

} decodeItem() is called when a component is being read from a stream. It is called once for each item that was decoded. The following sample decodes the information which was encoded in the previous example. Notice that the keys match the types and variables which were encoded.

The id is a special number that can be generated by the system during encoding. In this case the only use of id is in the ds.readObject. This id is a unique id assigned to individual objects when they are encoded. This is because some objects may be referenced by multiple objects in the encode process. In this case, the object is only encoded once and referenced by a simple id in later encodings. This saves space and time in the encode/decode process. This is transparent to the programmer, but just know that when decoding, if the item has already been decoded, the id will be used to reference it instead of creating yet another copy.

The key in this case is the key that was used in the encode phase. public void decodeItem(DecodeStream ds, int id, int key)

{ switch(key)

{ case 1 : uniqueld = ds.readlntQ; break; case 2: aString = ds.readStringO; break; case 3: aVector = ds.readVector(); break; case 4: aHashtable = ds.readHashtable(); break; case 5: aTarget = (Target) ds.readθbject(id); break; default: ds.skipltem(id); break;

} }

Another case is the ds.skipltem(id). If a component does not recognize the key, then it must tell the DecodeStream to skip over the item being decoded. This might occur if a programmer has two different users using older and newer versions of the component. If the user of the newer component sends a file to the user with the old code, the component should still be readable. This maintains backwards compatibility while providing for a migration path forward for improvements. PVComponent

The PVComponent defines multiple sets of data which can be common to all components. The first two are attributes which all components typically have, PVName and Uniqueld: public String getPVName(); public void setPVName(String strName);

The PVName is for the designer to identify each component by name. Think of this as minor comment for each individual component. The PVName may also be used in some log messages by specific components. public int getUniqueId(); public void setUniqueId(int id);

The unique id is should be passed to the logger as the itemld when the component creates a log message. The unique id is assigned an incrementing value as each component is added to a file. The designer may also change this value. This is used to identify one component from another in a log message. public void setStateh fo(Stateh fo info); setStatelnfo is called by the VisRunner and gives each component more information about the specific process that component is running within. This information is useful for logging. Most of the values on the client side (server id, group id) will be zero, but on the server side this allows a designer to separate out specific message from different games or event different game sessions. In one preferred embodiment such tagged logging information from clients and server side processes or applications can be integrated to facilitate debugging by providing a smooth trace across the network just as though the client-server application was a single non-networked application.

Target

The Target interface contains a single method called performCommand(). Events can contain two elements, an integer command and an Object. void performCommand (int command, java.lang.Object data)

A component can define any number of commands. This is typically done with a static variable by a programmer. Each command must be unique and cause some action in the performCommand method. A sample component may modify a number when it is sent to the component through an event. In this case, the programmer could define a static integer describing the event and give it a unique number. static int MODJ_FY_NUMBER_EVENT_KEY = 1;

Then in the performCommand, the event would be processed. In this case, we'll say that the component is expecting an integer input. void performCommand(int command, java.lang. Object data)

{ if (command = MODIFY_NUMBER_ENENT_KEY)

{ if (data instanceOf Integer)

{

Integer toModify = (Integer) data;

// create a new number and add one to the number that was passed in

Integer i = new Integer( toModify.intValue()+l);

} else

{

// print out an error

System.out.println("error MODIFY_NUMBER_^ENENT_KEY, expected int, got "÷data);

// or, more nonnally, send it to the log purevis.core.MasterLogger.getMasterLogger().log(stateinfo,itemID,MasterLogger.LOG_ER ROR,"error MODIFY_NUMBER_EVENT_KEY, expected int, got *'+data);

} } }

Beanlnfo/Buildlnfo

The Beanlnfo and Buildlnfo interfaces describe the component to the tool and allows the tool to modify certain aspects of the component. The description includes all the input and output events and any extra information (like editors) for components.

The normal component's Beanlnfo class extends SimpleBeanlnfo and implements Buildlnfo. The class name also has the same name as the class, with Beanlnfo on the end. This is a JavaBean requirement.

For instance, in a sample described below, the class declaration for the Beanlnfo class looked like this: public class CounterBeanlnfo extends SimpleBeanlnfo implements Buildlnfo

Nothing is changed from the SampleBeanlhfo. There are multiple methods which can be implemented from the Buildlnfo interface, for example: public String getDisplayName() public String getIcon(Object ob) public Hashtable geth putEvents(Object ob) public Hashtable getOutputEvents(Object ob) public Hashtable getTarget(Object ob, int key) public void setTarget(Object ob, int key, Target target, int command)

The first two (getDisplayName and getlcon) are very simple. The first returns a string which is used in the Toolbox to describe the component. The second is a string to the icon image name to use for the component.

The last four have to do with input and output events for the component. getlnputEvents describes the input events of a given component. The expected return value is a Hashtable containing a list of integer keys with data for each key being the description of the input event shown to the designer when wiring. The integers represent command events processed in the performCommand method of the component. For instance, in the previous performCommand there was the event key MODIFY_NUMBER_EVENT_KEY. To recognize that event, the Beanlnfo's gethiputEvents could create a hashtable in the following way.

Hashtable hash = new Hashtable(); hash.put(new Integer(MyComponent.MODIFY_NUMBER_EVENT_KEY),"Modify Number"); return hash;

For multiple Input events, just add more keys and descriptions to the Hashtable. getOutputEvents describes output events of a given component. The expected return value is a Hashtable. The hashtable contains a list of integer keys with data being the description to show the designer when wiring from the component. The key will be used when designer wires from the component and the toolset calls setTarget, which is described just below. Please note that even if a component has no output events, this should return an empty hashtable.

Hashtable hash = new Hashtable(); hash.put(new Integer(MyComponent.MY_OUTGOrNG_EVENT_KEY),"Outgoing Event"); return hash; getTarget is called by the toolset when it needs to know what component is the target for a specific outgoing event key. The return data is a Hashtable with the key being the Target and the data being the command which will be sent to that Target. All events have two pieces of information which a component must know to send that event. A Target and an integer command. This information is contained in the individual components and the Beanlnfo should read it from the component which is passed into getTarget. Again, even if a component has no output events, this should return an empty hashtable.

Hashtable hash = new Hashtable();

MyComponent mc = (MyComponenfjobj; hash.put(mc.getMyOutgoingEventTarget(),new integer (mc.getMyOutgomgEventCommandO)); setTarget is called by the toolset when a designer wires a new event from your component. It has the following parameters: public void setTarget(Object ob, int key, Target target, int command)

The object (ob) is the individual component which the designer wired from. The key is the event key specified in the getOutputEvents method described above. The Target is the component which the designer wired to. The command is what that command is expecting when the event fires. The Target and the command should be saved in the individual component and the performCommand called at the appropriate time. The event call from the component would look like this. if (theTarget ! =null)

{ theTarget.performCommand(theCommand,someObjectData);

}

Attached as Appendix A is a collection of component definitions for a sample tool kit called PureVis.

Fig. 6 is a block diagram illustrating functional description of one example high-level process by which the execution engine establishes a network connection with the server over one or many different underlying networks, using either persistent connections or polling, to create a homogeneous connection for executables and components to pass messages and data. This approach, in combination with the toolset enables network implementation and protocols to be transparent to both the application user and the application designer. Different protocols and schemes can be used "behind the scenes" to provide a seamless and effective communication scheme. With this networking approach, an application developer can provide identical content simultaneously to different clients and servers over a wide variety of network protocols, including but not limited to HTTP, WAP, MMS, tcp/ip, UDP, SMS and WCTP. The benefits of this approach include a simplification of development, and enabling designers who do not have an understanding of network programming to be able to effectively develop robust networked applications. A single core logic file can be the base of the application, and a change in this core file functions and is represented across the multitude of underlying network access methods which the designer need never be aware of.

The invention's networking can be configured to use a two step approach for scalability which supports diverse connections such as, but not limited to, HTTP Polling and tcp/ip and UDP hard connections. New types of network connections can be added to the server and pre-existing applications will automatically run over them without any changes and without any need to recompile the executable as executables are not compiled. This is a unique advantage of the invention, as recompiling would be required in compiled software development approaches. Synchronization is used with message numbering and tracking to ensure messages arrive in order both on the client and server side of the communication even if connections are broken and must be re-established. Specific components can be used in networking such as PVClient and PVServer. A client application 920, 945 begins by making a request to the server 995. Upon successful contact, the server instructs the client to continue with its current connection or it may return another hard port for the client to connect to 965. If so instructed, the client then disconnects the current connection and creates a new connection to the server on the specified port.

In one web implementation the initial contact from a web browser would be via HTTP to load the execution engine as a Java applet. The Java applet in turn would initiate an HTTP request to the server and might be instructed to continue HTTP client-based polling of the server, or might be instructed to connect again using tcp/ip through a specified port 965, depending upon the configuration of the execution engine, the user profile, or server configuration. The advantage of HTTP polling is that it is more readily workable through firewalls. The advantage of the hard connection is that it provides for superior network performance. The advantage of the two step approach is that connection loading can be balanced across different ports and different computers in the port assignment process. The server manages the client connection with configurable timeouts by application and sends a message to the Executable file (process) if a user is dropped the software designer need not be aware of any of these issues.

The server begins logging 985 and synchronizing 980 all networking traffic with that particular client 920, 945, assigning both a unique client id and application id for any applications launched by that client. The server also deals with maintaining persistent storage through the form of flat files 997 and a SQL database 996 depending on the type of application. These data stores are synchronized so that clients do not overwrite each other's data.

Fig. 8a is a block diagram illustrating a functional description of one embodiment of the server software that provides a platform for specific server-side applications generally created within the toolset, and which delivers and communicates with client-side applications generally made with the toolset to form networked software applications. The servers are built to be scalable. Complex algorithms and techniques have been applied to ensure data integrity, user management capabilities and the ability to handle multiple simultaneous connections. These servers are also multithreaded, increasing performance and efficiency.

The shared space server 1120 is a proprietary server built on top of the execution engine technology. The server 1120 upon startup launches a single instance 1125 of a executables file. All users 1100,1105... share this file and any changes made are reflected to all users. This is ideal for an environment in which users exchange data and ideas frequently (e.g. a multiplayer game, enterprise groupware, collaborative education, telematics based fleet management). The server 1120 is fully synchronized when handling user requests as well as the modification of persistent data in a database 1135 or flat file or file system (for example through Ustorelt) 1130.

Another server (labeled TCS Server) 1160 is similar to the shared space server 1120, but with a simpler operation. Rather than all users sharing a single instance of a executables file as is done in the shared space server, a unique instance is created for each individual user 1165, 1170, similar to a standard web server CGI process. There can never be communication between users and each invocation of the executables file is encased and isolated.

Fig. 8b is a diagram illustrating one embodiment of one server which is effectively an amalgamation of both the shared space and TCS Servers. It allows users to share unique executable files, as well as create a separate instances. Network clients are able to create new instances or to join existing ones, if the application allows it. This server 1180 is robust and scalable to handle a number of simultaneous users. It contains logging methods and synchronization methods to ensure data integrity. An application loaded into memory can be modified during runtime with little effect on current live applications. The advantages of the multi space server is shown in the delivery of complex services, such as multiplayer game communities on the Internet, interactive TV, mobile phones, and PDAs; multiuser group education and training communities; enterprise groupware, or other collaboration services featuring multiple titles where users can readily move between more than one application titles and use user match-up applications, all the while text chatting with people in any application within the service without the need for an external chat application or separate chat window.

In one embodiment of the servers, only toolset files are saved by developers. In this embodiment the toolset file is published on the server responsible for delivering the client executables and the server responsible for running the server-side application (which may be separate machines or the same machine, or there may be only an installed stand-alone application) and the server builds the executables, maintains these and their mapping to the toolset files, substituting the Executables file on the fly. The advantage of this approach is a reduction in user configuration management.

Fig. 9 is a block diagram illustrating a functional description of one embodiment of the extensible server platform supporting the addition of arbitrary protocol gateways for networking, communication, and data (including but not limited to SQL, tcp/ip, UDP, HTTP, XML, HTML, WAP, SMS, MMS, NFS, tables, flat files). These are supported by the server and made available to the software developer using the toolset, without the user needing to understand or even be aware of the network protocols being used.

The execution engine was created with modularity in mind. It can be invoked via several gateways that provide for unique data entry points to the invention. The execution engine (has been integrated with an HTTP server 1205 to provide visual scripting capabilities. This allows users to create dynamic web content. The email server 1210 allows the execution engine to be invoked upon the reception of specific email to specific email addresses. The instant messaging server 1215 allows instant messages to be passed as data to VisRunner. Through a combination of these gateways a single application made with the toolset can be adapted to run on several operating systems, network protocols, and hardware devices with no change at all to the core logic files. Due to the open architecture design of the execution engine 1220, it can be adapted for use with any server available and handle incoming requests of any kind. It is vital to note that other gateways can be implemented - all dealing with a specific executables file application 1225. This enables the easy incorporation of standard gateways and web services into executables including: ad servers, IRC chat, instant messaging, challenge ladders, bulletin boards, payment systems, caching servers such as Akami, search engines, and others. These gateways may also deal with the local operating system, such as the UStorelt component does with a file manager 1230, or gateways to other servers such as a SQL database. This provides the application developer with the ability to create a single application without having to deal with methods of communication. That is all transparent to the executables file 1225.

Fig. 10 is a functional description of one embodiment of the extensible server platform, which includes key community capabilities and supports the addition of arbitrary community features, and makes these capabilities available to the software developer using the toolset, without the user needing to understand how these capabilities are implemented. Several features are integrated to simplify management of multiuser environments for the toolset user. Anytime a user joins a current session (server process) the toolset file is notified allowing designers to handle that event 1325. The same is provided for when a user logs off. The server is also constantly checking users and searching for inactive users to boot off the system based on server configured timeouts. Chat features and private messages provide for a stable medium of communication among users of the system. Special administrative applications can be launched to administer and monitor the current state of the system.

A single client 1345, 1346,1347,1348 individually connects to the server 1300 across the network 1340. The server is in charge of authenticating 1305 that particular user. In one implementation, this is done by referencing an SQL database 1310, but may also be through an authentication server or other third party security system. While it is possible to authenticate against a flat text file, using an SQL Database or authentication server offers the ability to allow users to easily change their passwords, as well as gives the system administrator an easier task of managing user data and sharing that information across the community infrastructure. After authentication, the server sends the user a list of available applications based on the users current access level. This may be unique for each user and/or defined user group, whereas allowing users of different privileges, membership, or ownership status maybe given access to different sets of applications. A client 1345-1348 then sends the server the requested application name and type. The server checks for an instance of the executables file 1320 requested in memory. If an instance does not exist, the filel320 is read from disk 1315. Next, the server begins to deal specifically with user management 1325, watching for users that join particular applications, and monitoring for inactive users based on configurable timeouts or more sophisticated criterion in the form of monitoring applications as executables 1320. All application logic is handled by the individual executable file 1320. The component logic 1330 built into the file 1320 executes as per the application developers design. The component logic 1330 also has the ability to read and write synchronized data onto persistent storage in the form of an SQL database 1310 and a flat file by use of the UStorelt 1335 component. The UStorelt is a special component for saving persistent data. It utilizes a mapping scheme of folders and files to produce persistent data without requiring an SQL database.

While the particular systems and methods herein shown and describe in detail are fully capable of attaining the above described object of the invention, it is understood that the description and drawings presented herein represent one embodiment of the invention and are therefore representative of the subject matter which is broadly contemplated by the present invention. It is further understood that the scope of the present invention fully encompasses other embodiments that may become obvious to those skilled in the art and that the scope of the present invention is accordingly limited by nothing other than the appended claims.

APPENDIX A

Calculator Component ViewJndjviduaJly Compon ndex

Overview Build Properties Incoming Events Outgoing Events Examples

Performs basic math functions.

Overview

An Calculator is used to perform complex math procedures on 2 numbers. These can be either Integers , Longs or Doubles.

Remarks

Calculator component is for accepting a standard math formula (such as "a + 2.5b = c", where c is the output value) In textual form within the visual environment to allow for the easy implementations of algorithms and formulas while also maintaining them in a form users readily can identify and comprehend. The preferred embodiment includes several variants for simplicity, for thin client operation where the application (Executable) footprint size needs to be minimized, and for small device operation where some functions may not be implemented. This preferred embodiment includes a basic integer component (Formula) the Calculator as described below, and more advanced components to handle an arbitrary number of variables, and encompass complex math functions such as calculus, linear algebra, derivatives and others in one or more advanced math components. The current basic component performs the following math functions on 2 numbers: Addition, multiplication, division, subtraction, absolute value, exponential, sine, cosine, tangent, arcsine, arccosslne, arctangent, natural long.natural exponent, one over value, factorial, pi, e, return N as degrees and return N as radians.

See Also

Formula. Integer Gun. Long Gun

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Tpp Build Properties

The Calculator has these build properties:

Build Property Name Value Expected Description

NO Double This sets the NO register to the value that is sent to it. If you enter a whole number like 6, when you go to view it again it will automatically add the decimal point making it 6.0.

N1 Double This sets the N1 register to the value that is sent to it. If you enter a whole number like 6, when you go to view it again it will automatically add the decimal point making it 6.0.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Calculator component. Naming components makes them easier to find during debugging.

Remarks None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The Calculator has these incoming events:

Incoming Event Value Expected Description

Set NO Integer, Long or Double This sets the value of the NO register to the current value being sent to ** it.

Set N1 Integer, Long or Double This sets the value of the N1 register to the current value being sent to it.

Set NO and Compare Integer. Long or Double This sets the value of the NO register to the current value being sent to

_** it. This compares the values at both the NO and N1 registers and if they are equal it fires the Calculator's Equal outgoing event. If they are not equal then the Calculator's Not Equal outgoing event is fired.

Set N1 and Compare Integer, Long or Double This sets the value of the N 1 register to the current value being sent to it. This compares the values at both the NO and N1 registers and if they are equal it fires the Calculator's Equal outgoing event. If they are not equal then the Calculator's Not Equal outgoing event is fired.

Return Result Reverse Wire This returns the result of the most recently executed function. This is an integer. ^* Return Remainder Reverse_Wire This returns the remainder of the most recently executed division function. This is an integer. * Add (N0+N1 ) Trigger Event This adds the value of the NO and 1 registers and pushes the result out the Calculator's Push Result outgoing event. Subtract (N0-N1 ) Trigger Event This subtracts the value of the N1 from the value of the NO registers and pushes the result out the Calculator's Push Result Outgoing event.

Multiply (N0*N1) logger. Event This multiplies the value of the N1 by the value of the NO registers and pushes the result out the Calculator's Push Result Outgoing event.

Divide (N0/N1 ) Trigger Event This divides the value of the NO by the value of the N1 registers and pushes both the result and the remainder out the Calculator's Push Result and Push Remainder Outgoing event.

Compare (N0==N1) Trigger Event This compares the values at both the NO and N1 registers and if they are equal it fires the Calculator's Equal outgoing event. If they are not equal then the Calculator's Nor Equal outgoing event is fired.

Calculate N0^ΛN1 Trigger Event This calculates NO to the N1 power.The component will send a message out the Push Error event if both values are negative. NO! Trigger Event Calculates the factorial of NO. It will trigger an error if NO is less than zero. Since this is a integer/long function, the component will round all doubles before performing the calculation.

Abs NO Trigger Event Calculates the absolute value of NO.

Modulus (N0%N1) Trigger Event Calculates the remainder of N0/N1. Unlike the division command, this pushes the remainder out the Push Result output event and Ret Result will return the remainder. The Push Remainder event is left untouched. The component will round doubles before perfo ing this function.

Ceiling NO TriggerJΞvent Calculates the highest whole integer value closest to NO. So, if NO is 4.2, this will generate 5, if NO is -4.7, it will generate -4 and if NO is -4.2 it will also generate -4. Floor NO Trigger Event Calculates the lowest whole integer value closest to NO. So, if NO is - 4 2, this will generate -5, if NO is 4 7, it will generate 4 and if NO is 4.2 it will also generate 4.

Sιn(NO) Trigger Event Calculates the sine value (in radians) of NO.

Cos(NO) Trigger J≡yent Calculates the cosine value (in radians) of NO.

Tan(NO) Trigger Event Calculates the tangent value (in radians) of NO. The component will send a message out the Push Error event if NO equals Pi/2

Arcsin(NO) Trigger Event Calculates the arcsin value (in radians) of NO. The component will send a message out the Push Error event if the absolute value of NO is greater than 1.

Arccos(NO) Trigger Event Calculates the arccosiπe value (in radians) of NO. The component will send a message out the Push Error event if the absolute value of NO is greater than 1.

Arctan(NO) Trigger Event Calculates the arctangent value (in radians) of NO. NO to Radians Trigger Event Converts NO degrees to radians. NO'to Degrees Trigger Event Converts NO radians to degrees 1/NO Trigger Event Calculates the value of one divided by NO. This will throw and error if N0=0. e^ΛN0 Trigger Event Calculates the value of e raised to NO. Return Pi Reverse Wire Returns an approximation of Pi as a double. Return E Reverse Wire Returns an approximation of Pi as a double. Mode to Integer Trigger Event Sets the component to convert all values to integers before performing calculations, rounding as necessary.

Mode to Long Trigger Event Sets the component to convert all values to longs before performing calculations, rounding as necessary.

Mode to Double Trigger Event Sets the component to convert all values to doubles before performing, calculations, rounding as necessary.

^* Keep in mind that if you change modes after an operation the old values will still be in the "results" and "remainder" registers. You will need to perform the operation again to get the new results and remainder values. For example, lets say that while in Integer mode you divide 3 by 2. The result is 1 and the remainder is 1. Now you change the mode to Double. If you return the result it will be 1.0 and the remainder will be 1.0. But if you execute the divide function again and return the results they are now 1.5 and the remainder is still 1.0. Keep in mind that while dividing while in Double mode returning the remainder is totally useless since it is designed to return the remainder while working with whole numbers.

^** You can also use Strings as long as it is the string representation of a number.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Backio Top Outgoing Events

The Calculator has these outgoing events:

Outgoing Event Name Value Output Description

Equal Null If the result of a comparison between the NO and N1 registers are equal then this outgoing event is triggered. Not Equal Null If the result of a comparison between the NO and N1 registers are NOT equal then this outgoing event is triggered. Error Message String. If the result of a math function produces an error then this outgoing event is triggered. Example would be if you had N1 set to 0 and tried to divide NO by it. You would get the following error message: "Attempting to divide by zero".

Push Result integer, Long or Double When a math calculation or function Is done the results are pushed out this event. Push Remainder Integer, or Long When a math division function is done while in Integer or Long mode the remainder s pushed out this event. Example: You divide 10 by 3. The result is 3 and the remainder is 1.

Remarks

None

1*1 Comment Component View Individually support Links

Overview Build Properties Incoming Events Outgoing Events Examples

Used to add comments to PureVis files.

Overview

The Comment component is used to add a comment to a PureVis file. This is useful for documenting your PureVis files.

Remarks

The more comments that you put into your PureVis file, the easier it will be to decipher what's happening.

See Also Debug

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing. Events B_ackJo Top

Build Properties

The Comment has these build properties:

Build Property Name Value Expected Description

Comment String This is the actual text that will appear when it is opened in the future. Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID'S make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Comment component. Naming components makes them easier to find during debugging.

Remarks

Try to make your Comments as specific as possible.

Overview Build Properties Incoming Events Outgoing Events BackJo Top Incoming Events

The Comment has these incoming events:

None. Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The Comment has these outgoing events:

None.

Remarks

None

Conditionallnt Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to check for Integer Math conditions.

Overview

A Conditionallnt is used to change the flow of events based upon different comparisons or conditions.

Remarks

Conditionallnt works only with Integers You can not send a Long into a Conditionallnt.

See Also lnteg.ejLJG_urΛ, Long Gun, Conditional Long

Note to Java/C++ Programmers

None

O er iew Build Properties IncomingjE vents QutgoingjΞveαts Back to Top Build Properties

The Conditionallnt has these build properties:

Build Property Name Value Expected Description

Greater Than Value Integer This sets the Greater Than Value for the comparison. This can also be set a run time.

Less Than Value Integer This sets the Less Than Value for the comparison. This can also be set a run time.

Step Integer This sets the Step at which the comparison numbers appear. This number must always be positive.

Ceiling Integer This sets the Ceiling or the highest value for the list of comparison numbers. This is NOT included in the range of numbers unless the inclusive box is checked. ^*

Floor integer This sets the Floor or the lowest value for the list of comparison numbers. This number is ALWAYS included in the comparison range.

Values sjrirjg This sets the values for the comparisons. * Inclusive <Toggle> If this is checked then the Ceiling is included in the number range. If not it is not.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name striαa Optional. A name to be specified for the Conditionallnt component. Naming components makes them easier to find during debugging.

* It is possible to generate comparison values from both using the ceiling, floor and sfep method and from just entering the numbers as values. As an example. Lets say that you have the floor set to 1 and the ceiling set to 5 and the step is 1. You also have the inclusive box checked. When you go to wire the Conditionallnt to another component you will see that the numbers 1 through 5 are in the list. Now if you add the numbers 9 and 12 into the values box and go to wire it again, you will still see the 1 through 5, but you will also see the 9 and 12.

Remarks

None

Overview Build Properties Incoming Events Qutgnrø.g.j -£rιi£ Back Tor. Incoming Events

The Conditionallnt has these incoming events:

Incoming Event Value Expected Description

Set and Enable Variable Event Integer This sets the variable for use with the variable events. This also enables the use of variable events.

Disable Variable Event Trigger Event This disables the use of variable events. The last variable that was set will still be there if you enable the variable event later.

Enable Variable Event Trigger. Event This enables the use of variable events.

Set and Process Integer Integer This sets the integer with the value sent and the processes it. This starts the comparison between the number sent and the numbers that are set in the Conditionallnt.

Collect and Process Integer Trigger Event This causes the Conditionallnt to retrieve an integer using it's Retrieve Outgoing event. And then it will process that number.

Set Greater Than Value Integer This sets the Greater than value for the comparison.

Set Less Than Value Integer This sets the less than value for the comparison.

Remarks

None

Overview Build Properties Incoming Events Outgoing. Events Back to Top Outgoing Events

The Conditionallnt has these outgoing events:

Outgoing Event Name Value Output Description

Equal to Variable Integer This event is fired if the value passed to it is equal the the value that was last set as the variable with the Set and Enable Variable Event Incoming event.

Not Equal to Variable Integer This event is fired if the value passed to it is NOT equal the the value that was last set as the variable with the Set and Enable Variable Event Incoming event.

Value in Range Integer This event is fired if the value passed to it is both higher than the greater than value and lower than the less than value. *

Value Not in Range Integer This event is fired if the value passed to it is NOT higher than the greater than value and lower than the less than value. *

Value Greater Than Integer This event is fired if the number sent in is greater than the number set as the Greater than number.

Value Less Than Integer This event is fired if the number sent in is less than the number set as the Less than number.

Retrieve Integer Reyerse Vjre This causes the Conditionallnt to retrieve an integer and then to process the number.

Value Greater Than or Equal to Integer This event is fired if the number sent in is greater than or equal to the number set as the Greater than number. Value Less Than or Equal to Variant This event is fired if the number sent in is less than or equal to the number set as the Less than number. Equal to: <value> Integer These outgoing events will only show up if you have added values during build mode. This enables you to compare the number in question against a particular number. This event is fired if the comparison results in both numbers being equal.

Not Equal to: <value> Integer These outgoing events will only show up if you have added values during build mode. This enables you to compare the number in question against a particular number. This event is fired if the comparison results in both numbers being equal.

* As an example. Lets say that you have the Greater than number set to 5 and the less than number set to 10. Then you send the number 7 into the Conditionallnt and you process the number. This will trigger the Value in Range event. But then if you send in the number 3 into the Conditionallnt this would trigger the Value not in rangeevent.

Remarks

None

CondtioinalLong Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to check for long math conditions.

Overview

A ConditionalLong is used to change the flow of events based upon different comparisons or conditions.

Remarks

ConditionalLong works only with long numbers. You can not send an integer into a ConditionalLong

See Also

Lαng_Gun, Integer Gun, Conditionaljnteger

Note to Java/C++ Programmers

None

QLVjejrwew Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The ConditionalLong has these build properties:

Build Property Name Value Expected Description

Greater Than Value Long This sets the Greater Than Value for the comparison. This can also be set a run time.

Less Than Value Lonq This sets the Less Than Value for the comparison. This can also be set a run time.

Step Long This sets the Step at which the comparison numbers appear. This number must always be positive. *

Ceiling Long This sets the Ceiling or the highest value for the list of comparison numbers. *

Floor Long This sets the Floor or the lowest value for the list of comparison numbers. *

Values String This sets the values for the comparisons. *

Inclusive <Togqle> If this is checked then the Ceiling is included in the number range. If not it is not.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the

Unique ID lets you know which one has the problem.

PV Name Optional. A name to be specified for the ConditionalLong component.

Naming components makes them easier to find during debugging.

* It is possible to generate comparison values from both using the ceiling, floor and step method and from just entering the numbers as values. As an example. Lets say that you have the floor set to 1 and the ceiling set to 5 and the step is 1. You also have the inclusive box checked. When you go to wire the ConditionalLong to another component you will see that the numbers 1 through 5 are in the list. Now if you add the numbers 9 and 12 into the values box and go to wire it again, you will still see the 1 through 5, but you will also see the 9 and 12.

Remarks

None

Overview BuildJPjroperties Incoming Events Outgoing Events Back to Top

Incoming Events

The ConditionalLong has these incoming events:

Incoming Event Value Expected Description

Set and Enable Variable Event Long This sets the variable for use with the variable events. This also enables the use of variable events.

Disable Variable Event Trigger Event This disables the use of variable events. The last variable that was set will still be there if you enable the variable event later.

Enable Variable Event Trigger Event This enables the use of variable events.

Set and Process Long Long This sefs the integer with the value sent and the processes it. This starts the comparison between the number sent and the numbers that are set in the ConditionalLong.

Collect and Process Long Trigger Event This causes the ConditionalLong to retrieve an integer using it's Retrieve Outgoing event. And then it will process that number.

Set Greater Than Value Long This sefs the Greater than value for the comparison.

Set Less Than Value Lonq This sets the less than value for the comparison.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back o Top Outgoing Events

The ConditionalLong has these outgoing events:

Outgoing Event Name Value Output Description

Equal to Variable Long This event is fired if the value passed to it is equal the the value that was last set as the variable with the Set and Enable Variable Event

Incoming event.

Not Equal to Variable Long This event is fired if the value passed to it is NOT equal the the value that was last set as the variable with the Set and Enable Variable

Event Incoming event. Value in Range Long This event is fired if the value passed to it is both higher than the greater than value and lower than the less than value. *

Value Not in Range Long This event is fired if the value passed to it is NOT higher than the greater than value and lower than the /ess than value. ^*

Value Greater Than Long This event is fired if the number sent in is greater than the number set as the Greater than number.

Value Less Than Long This event is fired if the number sent in is less than the number set as the Less than number.

Retrieve Long Reverse Wire This causes the ConditionalLong to retrieve an integer and then to process the number.

Value Greater Than or Equal to Long This event is fired if the number sent in is greater than or equal to the number set as the Greater than number. Value Less Than or Equal to Long This event is fired if the number sent in is less than or equal to the number set as the Less than number. Equal to: <value> Long These outgoing events will only show up if you have added values during build mode. This enables you to compare the number in question against a particular number. This event is fired if the comparison results in both numbers being equal.

Not Equal to: <value> Long These outgoing events will only show up if you have added values during build mode. This enables you to compare the number in question against a particular number. This event is fired if the comparison results in both numbers being equal.

^* As an example. Lets say that you have the Greater than number set to 5 and the less than number set to 10. Then you send the number 7 into the ConditionalLong and you process the number. This will fire the Value in Range event. But then if you send in the number 3 into the ConditionalLong this would fire the Value not in Range event.

Remarks

None

Cookielnterrogator Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A Cookielnterrogator is used to setup and process HTTP Cookies. Cookies are used to store a single piece of data on either a computer or wireless device as long as the device supports cookies.

Remarks

Cookielnterrogator components can not only retrieve the cookies they can create and send one as well.

See Also

MLGateway, TextStore, Siringlnterroaatox

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events OutgoingJEvents Back to To Build Properties

The Cookielnterrogator has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it Is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Cookielnterrogator component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The Cookielnterrogator has these incoming events:

Incoming Event Value Expected Description

Set Cookie Oblect This sets the cookie that was returned from the MLGateway component. Once set the value and name can be retrieved. Return Cookie Reverse Wire This returns the cookie from the Cookielnterrogator. This is normally done after a new cookie is created using the (New) Clone Cookie Incoming event, and the cookie is populated with values. It is then sent to the MLGateway component.

Return Cookie Name Reverse Wire This Returns the Cookie Name from the most recently Sef Cookie.

Return Cookie Value Reverse Wire This Returns the Cookie Value from the most recently Sef Cookie.

Set Cookie Name String This Sef ffte Cookie Name. You must have already created a new cookie using the (New) Clone Cookie Incoming event first.

Set Cookie Value String This Sef the Cookie Value. You must have already created a new cookie using the (New) Clone Cookie Incoming event first.

Set Maximum Age Integer This sefs the Maximum Age of the cookie in seconds before it will expire A negative number indicates the default, that the cookie will expire when the browser exitc. A zero value tells the browser to delete the cookie immediately.

Set Path String Specifies a path for the cookie, which is the subset of URIs to which a cookie should be sent. By default, cookies are sent to the page that set the cookie and to all pages in that directory or under that directory. A path set to "/" causes a cookie to be sent to all pages on a server. A cookie's path must be such that in includes the sen/let that set the cookie.

Set Domain String Specifies a domain restriction pattern. A domain pattern specifies the servers that should see a cookie. By default, cookies are returned only to the host that saved them. Specifying a domain name pattern overrides this. The pattern must begin with a dot and must contain at least two dots. A pattern matches only one entry beyond the initial do. For example, ".PureVis.com" is valid and matches www.PureVis.com and upload.PureVis.com but not www.upload.PureVis.com. For more details on domain name patterns, see Netscape's Cookie Specification and RFC 2109.

Set Comment String This sefs the comment field for the cookie. A comment describes the intended purpose of a cookie. A web browser may choose to display this text to the user. Comments are not supported in version 0 cookies.

(New) Clone Cookie Trigger Event This is called when you want to create a (New) Cookie. This must be called prior to calling the Sef the Cookie Name, and the Sef the Cookie Value.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The Cookielnterrogator has no outgoing events.

Remarks

None Ξ DataCardGenerator Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A DataCardGenerator is used to generate a deck of Datacards.

Remarks

The data for these DataCards can be predefined at build time. These Datacards can also contain a graphic for displaying on the screen.

See Also

DataCardlnterrogator. DataCardPile

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing_^ Events Back to Top Build Properties

The DataCardGenerator has these build properties:

Build Property Name Value Expected Description

Data Delimiter String This sets the delimiter for the data file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that is NOT used in the data. Tab delimiter is highly recommended. This can also be set a run time.

Main Data File _/ String This is the url of the Main Data File. This can also be set at run time.

Main Defs File String This is the url of the Main Data File. This can also be set at run time.

Field Ignore Key String This sets the Field Ignore Key for the Custom Card File. This can be any text. It is recommended that you use either SKIP or IGNORE. This can also be set at run time.

Debug to Log <Toggie> When there is any activity by this component it is printed out to the log if this box is checked.

Defs Delimiter String This sets the delimiter for the definitions file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that is NOT used in the data. Tab delimiter is highly recommended. This can also be set at run time.

Custom Card File String This is the url of the Custom Card File. This can also be set at run time.

Unique Id iQteger PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file. Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the DataCardGenerator component. Naming components makes them easier to find during debugging. Remarks

None

Overview BuiJd_Prope_rti.es Incoming Events QujtgpJ n g JEve nts Back to Xo Incoming Events

The DataCardGenerator has these incoming events:

Incoming Event Value Expected Description

Set Main Defs File String This is the url of the Main Definitions File. This can also be set at build time.

Set Main Data File String This is the url of the Main Data File. This can also be set at run time.

Set Defs Delimiter String This sets the delimiter for the definitions file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that is NOT used in the data. Tab delimiter is highly recommended. This can also be set at build time.

Set Data Delimiter String This sets the delimiter for the data file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that is NOT used in the data. Tab delimiter is highly recommended. This can also be set at build time.

Generate Trigger Event This caused the DataCardGenerator to generate the cards based upon the data found in the Main Data File and in the Main Defs File: ,

Return New Card Reverse Wire This Returns a New Card with the fields that are specified In the Main

Defs File. Strings are returned as an empty string and Integers are returned with a -1.

Set Custom Card File String This is the url of the Custom Card File. This can also be set at build time.

Generate Custom Cards Trigger Event This caused the DataCardGenerator to generate the cards based upon the data found in the Custom Card File.

Set Field Ignore Key String This sets the Field Ignore Key for the Custom Card File. This can be any text. It is recommended that you use either SKIP or IGNORE. This can also be set at Build time.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Xop Outgoing Events

The DataCardGenerator has these outgoing events:

Outgoing Event Name Value Output Description

Card Destination DataCard The Card Destination event sends the cards that are generated when the DataCardGenerator is told to generate cards. This is normally wired to a DataCardPile. Generation Complete Null Fired when the DataCardGenerator is done generating all the Datacards.

Remarks

None

DataCardlnterrogator Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events. Examples

Overview

A DataCardlnterrogator is used to retrieve and get information from a DataCard.

Remarks

DataCardlnterrogator components allow the user to not only retrieve data from a DataCard, but also gives them the ability to change the values. ,

See Also

DataCardGenerator, DataCardPile

Note to Java/C++ Programmers

None

Overview Build Properties Incoming .Events Outgoing Events Back_to„T_op

Build Properties

The DataCardlnterrogator has these build properties:

Build Property Name Value Expected Description

Load Defs File <Action Click > This causes the DataCardlnterrogator to read the DefmitionsFile and then to create DataCardKeys from it. This will eliminate the need to type in long list of fields into the DataCardKeys text box.

Defs Delimiter String This sets the delimiter for the data file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that is NOT used in the data. Tab delimiter Is highly recommended.

Data Card Keys String This Is an string list of the keys associated with the DataCard fields. Setting these keys will allow the user to wire events to set and retrieve the data at those particular DataCardKeys. Once these keys are set they will appear in the DataCardlnterrogator's Incoming events when you try to wire another component to it.

Defs File String This is the url of the definitions file that you want to read from if you click on the LoadDefsFile box. This will read all the fields from the DefmitionsFile and create keys from it.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the DataCardlnterrogator component. Naming components makes them easier to find during debugging.

Remarks None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The DataCardlnterrogator has these incoming events:

Incoming Event Value Expected Description

Set Card DataCard This sets the DataCard into the DataCardlnterrogator. Once set the data can be read or changed.

Return Card Null This returns the actual DataCard from the DataCardlnterrogator.

Set Key Strinq or Integer This sets the key for which the next Return Value at Key or Sef Value at Key will be performed on.

Return Value at Key Reverse Wire This returns the value of the currently selected key.

Set Value at Key String or Integer This sets the value of the currently selected key.

Return List of Keys Reverse Wire This returns a list of the keys.

Build Blank Card Tπqqer Event This builds a new Blank DataCard. The new DataCard has no keys or data

Return Class Name Reverse Wire

Clear Card Trigger.Eve.nt This clears all the data from the card.

Return Copy of Card Reverse Wire This returns a copy of the Datacard from the DataCardlnterrogator while leaving the actual DataCard in the DataCardlnterrogator.

Remarks

None

Overview BuildJProperties Incoming Events Outgoing Events Back Jo Top Outgoing Events

The DataCardlnterrogator has NO outgoing events.

Remarks

None DataCardPile Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A DataCardPile is used to store Datacards. It works much like a deck of cards. The DataCards are stored in the pile and can be retrieved in various ways.

Remarks

DataCardPile components can store more than just Datacards. They can store anything including numbers.

See Also

DataCardGenerator, DataCardPile

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to.Top Build Properties

The DataCardPile has .these build properties:

Build Property Name Value Expected Description

Load Defs File <Action Click > This causes the DataCardPile to read the DefinitionsFile and then to create DataCardKeys from it. This will eliminate the need to type in long list of fields into the DataCardKeys text box.

Defs Delimiter String This sets the delimiter for the data file. The default is Tab. This is a single character only and can be any character you want. But keep in mind that is should be a character that Is NOT used in the data. Tab delimiter is highly recommended.

Data Card Keys This is an string list of the keys associated with the DataCard fields. Setting these keys will allow the user to wire events to set and retrieve the data at those particular DataCardKeys. Once these keys are set they will appear in the DataCardPile's Incoming events when you try to wire another component to it.

Defs File String This is the url of the definitions file that you want to read from if you click on the LoadDefsFile box. This will read all the fields from the DefinitionsFile and create keys from it.

Auto Shuffle <Tqggle> With the A-/foS/?uffifeturned on the DataCardPile will automatically shuffle the deck when it encounters a card that it had previously dealt out. This is most useful when cards are placed back in the

DataCardPile as discards and you want to reshuffle when a card that was already dealt out has made it's way to the top of the

DataCardPile.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the

Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the

ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the DataCardPile component. Naming components makes them easier to find during debugging.

Remarks

None

Overview BjjildPrp4_ertj.es Incoming Events Outgoing Events Back to Top Incoming Events

The DataCardPile has these incoming events:

Incoming Event Value Expected Description

Draw Top Card Reverse Wire This returns the Top Card from the DataCardPile. It also deletes the

DataCard from the deck as well.

Draw Bottom Card Reverse Wire This returns the Bottom Card from the DataCardPile. It also deletes the DataCard from the deck as well.

To Bottom of Card Pile Variant This sends whatever is sent to the bottom of the card pile. To Top of Card Pile Variant This sends whatever is sent to the top of the card pile. Shuffle Deck Trigger .Event This shuffles the deck. Return # of Cards Reverse Wire This returns the number of cards in the DataCardPile. This is an

Integer.

Return Card Stack Reverse Wire This returns a list of whatever is in the DataCardPile. This is only a list and does not remove the cards.

Remove Card DataCard or Lnteger This removes the card or number that is sent, from the DataCardPile. This will only remove the first card that matches. If you want to remove all of the cards you should use the Remove All Card Instances event.

Remove All Card Instances DataCard or Integer This removes all the instances of the card or number that is sent to the DataCardPile. Clear Deck Tπgger.Event This will Clear the Deck If the contents of this DataCardPile is stored somewhere else it will also be cleared. This differs greatly from the

New Deck event which only clears the content of the one

DataCardPile.

New Deck Trigger Event This will create a New Deck. This deck will be empty. The New Deck only affects this deck.

Set Sort Priority Integer This sets the sorting priority for the currently selected key. Higher numbers high priority over lower numbers.

Clear Sort Priorities Trigger Event This clears the sort priorities for all keys.

Sort Ascending Tnqqer Event This sorts the DataCardPile in ascending order based upon the key that is currently set.

Sort Descending Trigger Event This sorts the DataCardPile in descending order based upon the key that is currently set.

Set Low Selection Value integer This sets the Low Selection Value for use when using the Ref Cards btwn Selecϋons or the Return Rand Card w n Selections event.

Set High Selection Value Integer This sets the High Selection Value for use when using the Ref Cards btwn Selections or the Return Rand Card w/in Selections event.

Clear Selections Trigqer Event This clearns both the Low and High selection values.

Return Cards btwn Selections Reverse Wire This returns a list of cards between the High and Low values that were set in the Sef Low Selection Value and the Set High Selection Value.

Return Random Card w/in Reverse Wire This returns a single random card between the High and Low values Selections that were set in the Sef Low Selection Value and the Sef High Selection Value.

Return # Cards Meeting R_.everse_VVJre This returns the # of cards that currently meet the selection Criteria. Selection Criteria This is an Integer.

Return High Value Meeting Reverse Wire This returns the High value for the Datacards that have met the Selection Criteria selection criteria.

Return Low Value Meeting Reverse Wire This returns the Low value for the Datacards that have met the Selection Criteria selection criteria.

Return Mean Value Meeting Reverse Wire This returns the Mean value for the Datacards that have met the Selection Criteria selection criteria. The mean is the mathematical average of all the selections.

Return Median Value Meeting Reverse Wire This returns the Median value for the DataCards that have met the Selection Criteria selection criteria. The median is the cards that have the most occurrences..

Set Key String or Integer This sets the Key for the next event that requires a key to be set. Set Deck List This sets the Deck with a new list of cards. This will replace whatever was there.

Sort key to Ascending Trigger Event This sorts the DataCardPile in ascending order based upon the key that is currently set.

Sort key to Descending Trigger Event This sorts the DataCardPile in descending order based upon the key that is currently set.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The DataCardPile has these outgoing events:

Outgoing Event Name Value Output Description

Deck Shuffled Trigger Event This event is fired if the DataCardPile shuffles the deck. There are two ways that this can happen. The first is if you call the Shuffle Deck Incoming event in the DataCardPile. The second is if you have the AutoShuffle box checked during build mode. This will cause the DataCardPile to automatically shuffle the deck if it tries to deal a card that was already dealt once.

Remarks

None Debug Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to print out debug information to the log.

Overview

The Debug is used to print out data from a component.

Remarks

If the data is a list then it prints out the entire list. If it is a datacard then it prints out the fields and values associated with that data card. If the value sent to it is Null then it says Null.

See Also Comment

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing.Eyents Back.tP.Top Build Properties

The Debug has these build properties:

Build Property Name Value Expected Description

Description String Optional. This description will show up in the log prior to the value that was passed to it.

Date Time Stamp ^/ <Toggle> When this is selected a DateTimeStamp will be printed in the log.

Enabled Ioggle> In order to have the Debug active this must be clicked. Once you don't want the Debug info to show up any more just deselect this.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID'S make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Debug component. Naming components makes them easier to find during Debugging.

Remarks

None

Overview Buildprpperties Incoming Events Outgoing Events Back to Top Incoming Events The Debug has these incoming events:

Incoming Event Value Expected Description

Print to Log Variant Calls on the Debug to print out whatever was sent to it. Set Session Key Variant If the Session Key is set prior to calling the Debug then it is printed to the log prior to all other information. This can be a unique value for each player, and was designed to help keep track of multiple sessions in one log file.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The Debug has these outgoing events:

None.

Remarks

None

Fl i

Enumerator Component Viewjjidjyidjually Ci_mpj5_enLLndex

Overview Build Properties Incoming Events Outgoing Events Examples

Used to enumerate a list.

Overview

An Enumerator is used to enumerate a list of objects, numbers, strings or datacards "Enumerating" is the process of firing objects in a collection one-by-one. Dealing a deck of cards is enumeration, for example. Once each element of the collection is fired, it may be processed individually

Remarks

None

See Also Retriever. Fan

Note to Java/C++ Programmers

A enumerator encapsulates a Java enumeration.

Overview Build Properties Incoming Events OutgoϊngJ≡vents Back tp pjp Build Properties

The Enumerator has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Enumerator component. Naming components makes them easier to find during debugging.

Remarks

The Enumerator can enumerate any type of list. This includes, numbers, strings, objects and datacards.

Overview Build_^Properties Incoming Events Outgoing Events B_ack to_T_op Incoming Events

The Enumerator has these incoming events.

Incoming Event Value Expected Description

Set List List Sets the list in the Enumerator. Note: This event will not begin the enumerator process; it only sets the list in place. Set and Enumerate List List Sets the list in the Enumerator and starts the enumeration process. See Outgoing Events for details on order of events. Enumerate List Trigger Event Enumerates a previously set list. See Outgoing Events for details on order of events. Stop Enumeration Trigger Event Stops the Enumerator from enumerating. If the Enumerator is not already enumerating, this event will do nothing. Reset Enumeration Trigger Event Resets the list starting position in the Enumerator. If the Enumerator is told to enumerate again it will start at the beginning of the list. Return List Size Reverse Wire Returns the size of the list. This event returns an Integer.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The Enumerator has these outgoing events:

Outgoing Event Name Value Output Description

List Size Inteqer Fires the number of elements that are contained in a list. This event is fired prior to the Nexf Element event.

Next Element Variant Fires each element in a list one item at a time once the Enumerator is told to enumerate.

Finished Enumeration Null Fires after the last element has been fired. The Finished Enumeration event will not fire if Stop Enumeration is called.

Remarks

None.

Overview Build Properties Incoming Events Outgoing Events Back to Top Examples

Requirements

If the Example Library is not already installed on your system, you may need to download it. To do so, download examp.lel_.ibrary.zip and unzip it to your c:\purevis directory. The required sub-directories will be created automatically.

Examples

• Functionality Example

(c:\purevis\library\enumerator\enumerator.pvt)

Example Focus:

All enumerator events

The example shows how to use the various events of the enumerator. The enumerator will manipulate a list of keys retrieved from a text store.

Fan Component Vjew J ndj id u a I ly Component Index Overview Build Properties Incoming Events Outgoing Events Examples

Used to distribute data to multiple sources.

Overview

A Fan is used to spread copies of data to multiple components, or can be used to trigger multiple events. For example, a Button might call a Fan during its OnClicked event. The Fan would then call several other components for further processing.

Remarks

Fan components perform wired events in order, starting from Send EventO. If a Send Event has no wiring, but there are further Send Events beyond it, Wire will skip the missing event and move on to the next Send Event.

See Also

Retriever. Integer Gun

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The Fan has these build properties:

Build Property Name Value Expected Description

Maximum Events I eger Declares how many outgoing Send Events the Fan will provide. Wire will bypass any unused Send Events.

Shift Events Down < Action Click > Shifts all Send Events down by one. This is often useful when adding an additional chain of processes before other Send Events should be called. If you click this and the last event is currently used, that wire will be lost.

Insert Event <Action Click > Used to insert a new fan event. Just enter the number of the event where you want the new event to be inserted, and it will move all the other events down. If necessary it will also create a new event at the end.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name Optional. A name to be specified for the Fan component. Naming components makes them easier to find during debugging.

Remarks

None Overview Build Properties Incoming Events Outgoing Events Back to Tpp

Incoming Events

The Fan has these incoming events:

Incoming Event Value Expected Description

Fan Event Variant Calls on the Fan to distribute data via Send Events. A copy of the data will be sent to each component wired to a Send Event. Each Send Event is called in numerical order, starting from Send EventO. The next event will not be called all events spawning from the most recently fired are complete.

Turn Fan On Trigger Event Restores the Fan component's ability to distribute data after Turn Fan Off has been called. Turn Fan Off Trigger Event Disables the Fan component's ability to distribute data. Any data sent to a Fan when it has been disabled will be ignored. No Send Event processes will be triggered - the Fan Component's Evenf Blocked event will be triggered instead.

Skip Remaining Events Trigger Event Will stop the Fan from processing any further Send Events after Skip Remaining Events has been called.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Outgoing Events

The Fan has these outgoing events:

Outgoing Event Name Value Output Description

Event Blocked Variant The Z-Venf Blocked event is generated when the Fan has been disabled via the Turn Fan Off incoming event The Fan will send out the data sent to it, which may be used to trigger further processing.

Send Event Variant Triggered when data is passed into the Fan via the Fan Event incoming event. The Fan will pass out a copy of the data to each event, in order, through each Send Event outgoing event.

Remarks

None

Overview B_ulLd_P.roperties IncpjnjngJ≡yents Outgoing Events Back to Top Examples Requirements

If the Example Library is not already installed on your system, you may need to download it. To do so, download examplelϊbrary.zip and unzip it to your c:\purevis directory. The required sub-directories will be created automatically.

Examples

Fan On/Off Example • Fan Skip Remaining Example (c:\purevis\library\fan\onoff.pvt) (c:\purevis\library\fan\skip_remaining.pvt)

Example Focus: Example Focus:

Turn Fan Off, Turn Fan On, "Skip Remaining Events incoming and Event Blocked events. event.

This example shows how to use the Turn Fan On and Turn Fan Off The example shows a fan incrementing a gun events to regulate data passing an infinite amount of times, as the fan's last event is wired to itself. However, the gun's value will be through a Fan component. passed through a conditional integer with each loop. If the gun's value becomes 50, the conditional integer will tell the fan to skip its remaining events, skipping the event that restarts the loop.

NOTE: It is -never- recommended to create a potentially infinite loop on purpose. While the application is looping, the client will appear to be "frozen", and too many itterations may the application to crash due to memory constrains.

Formula Component View Individually Support Links

Overview B.ui Id.. Properties Incoming Events Outgoing Events Examples

Overview

A Formula is used to perform elaborate mathematically formulas. It can also do addition, subtraction, multiplication and division.

Remarks

The formulas can be enclosed with parentheses. The formulas contained in the parentheses are performed first.

See Also

CalculatQE, Integer.Gun, Long Gun

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The Formula has these build properties:

Build Property Name Value Expected Description

Formula String This is the formula string. This string can contain variable names and math operands such as +, -, * and /. You can also use parenthesis to control the order in which things are calculated.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Formula component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The Formula has these incoming events:

Incoming Event Value Expected Description

Push Result Trigger Event This causes the Formula component to calculate it's formula and to push the results.

Calculate & Return Result Reverse Wire This causes the Formula component to calculate it's formula and to send the results back with component that called it. Most likely a Retriever or perhaps a Conditionallnt

Set Formula String This sets the formula with a new formula string. Once set this will become the new formula for the next calculation. Set (?) Integer, Long or Double This sets the variable name that was given in the formula string with the value sent to it. As an example. Lets say you want to calculate a players batting average. You would use the following formula and set it at build time: hits*1000/ab. Once this formula is set you would use the Sef hits incoming event to set the number of hits and the Sef ab to set the number of at bats.

Set Variable Name String This sets the name for a variable in the Formula component. Set Variable Value Integer, Long or Double This sets the value for the last variable name that was set in the Formula component.

Mode to Integer Trigger Event This sets the current mode for the Formula to Integer. All calculation results will be in this number format. This is the default.

Mode to Long Trigger Event This sets the current mode for the Formula to Long. All calculation results will be in this number format.

Mode to Double TriggeLE ent This sets the current mode for the Formula to Double. All calculation results will be in this number format.

Remarks

None

Overview Build. Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The Formula has these outgoing events:

Outgoing Event Name Value Output Description

Result Target Integer, Long or Double This sends out the result of a formula calculation. Error Target String This event is triggered if an error accured in your formula. This will contain a string that will describe your error, (i.e. Attempted to divide by zero) When this event is triggered it does not trigger the Result Target, nor will there be any value to "get" with the Gef Result incoming event.

Remarks

None 0 IntegerGun Component View Individually Support Links

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

An IntegerGun is used to store Integer numbers. The range of an Integer is from -2147483648 to 2147483647. If you need to use numbers that are higher or lower than this you will need to use a LoπgGuπ.

Remarks

IntegerGun components store Integer numbers. This numbers can then be sfjof to another component or can be retrieved.

See Also

Conditional Int. Long Gun

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back JtoJTpp Build Properties

The IntegerGun has these build properties'

Build Property Name Value Expected Description

Maximum Value Integer This sets the MaximumValue for the IntegerGun. This can also be set at run time.

Minimum Value Integer This sets the MinimumValue for the IntegerGun. This can also be set at run time.

Number To Send Integer This sets the current value for the IntegerGun. This can also be set a run time.

Wrap Around <Toqgle> If this is checked then if a number reaches the maximum or minimum values then it will wrap around. As an example. You have the maximum set to 10 and the minimum set to 0. You have the NumberToSend set to 10. You then increment the number by one. With the WrapAround checked on the NumberToSend will then be 0. If it is NOT checked then the NumberToSend Will remain at 10.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the IntegerGun component. Naming components makes them easier to find during debugging.

Remarks None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The IntegerGun has these incoming events:

Incoming Event Value Expected Description

Set To Minimum Integer This sets the Number To Send value of the IntegerGun to the current Minimum Value.

Set To Maximum Integer This sets the Number To Send value of the IntegerGun to the current Maximum Value. Fire Away Triggeχ_Eyent This tells the IntegerGun to Fire it's current Number To Send value. This fires the IntegerGun's Shoot Int Outgoing event. Decrement By 1 Trigger Event This Decrements the value of the current Number To Send by 1. If the number falls below the Minimum Value then it will remain at the current Minimum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Maximum Value.

Increment By 1 Trigger Event This Increments the value of the current Number To Send by 1. If the number is higher than the Maximum Value then it will remain at the current Maximum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Minimum Value.

Decrement By- Integer This Decrements the value of the current Number To Send by the number sent to it. If the number falls below the Minimum Value then it will remain at the current Minimum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Maximum Value.

Increment By- Integer This Increments the value of the current Number To Send by the number sent to it. If the number is higher than the Maximum Value then it will remain at the current Maximum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Minimum Value.

Set NumberTo Send integer This sets the current Number To Send. This can also be set at build time.

Return Int Reverse Wire This returns the current Number To Send in the IntegerGun.

Set Maximum Value Integer This sets the MaximumValue for the IntegerGun. This can also be set at build time.

Set Minimum Value integer This sets the MinimumValue for the IntegerGun. This can also be set at build time.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The IntegerGun has these outgoing events:

Outgoing Event Name Value Output Description

Shoot Int Integer This tells the IntegerGun to Shoot the current value of the Number To

Send.

Remarks

None

IntegerMachineGun Component Viewj.ndJvidyc3_.y. support Links

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A IntegerMachineGun is used to shot a series of numbers. You can set the starting and ending numbers along with the step. The step is the distance between the numbers. As an example. If you set the starting number to 0, the ending number to 10 and the step to 2. Then the IntegerMachineGun will shot the following numbers: 0,2,4,6,8 and 10.

Remarks

If you set the starting number to a higher number than the ending number then it will count down. You can also use negative numbers as the starting and ending numbers, but the step must always be a positive number. If you try to use a negative number it will change it to a positive one automatically.

See Also lαte-gejrJG_un, Long Gun, Enumerator

Note to Java/C++ Programmers None

Overview Build Properties !.ncp_ming Events Outgoing Events B_LC_k_to.Tpp

Build Properties

The IntegerMachineGun has these build properties:

Build Property Name Value Expected Description

Start Value Integer This is the StartValue at which the IntegerMachineGun will start shooting at. This can be any valid integer number. This can also be set a run time.

End Value Integer This is the EndVaiue at which the IntegerMachineGun will finish shooting. This can be any valid integer number. This can also be set a run time.

Step Integer This is the Sfep at which t e IntegerMachineGun will shoot. This must be a positive number. A Sfep of 1 will shoot all numbers, a Sfep of 2 will shoot every other number, a Sfep of 3 will shoot every third number and so on. This can also be set a run time.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file. Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the IntegerMachineGun component. Naming components makes them easier to find during debugging.

Remarks

None Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The IntegerMachineGun has these incoming events:

Incoming Event Value Expected Description

Fire from Start Trigger Event Calls on the IntegerMachineGun to start firing. This fires the

IntegerMachineGun's Shoot Int Outgoing event.

Stop Firing Trigger Event Calls on the IntegerMachineGun to stop firing. Continue Hiring Trigger Event Calls on the IntegerMachineGun to Continue firing. If it was told to

Stop Firing, It will continue to fire from where it left off.

Set Starting Number Integer This sets the Starting Number at which the IntegerMachineGun will start shooting at. This can be any valid integer number. This can also be set a build time.

Set Ending Number integer This sets the Ending Number at which the IntegerMachineGun will finish shooting. This can be any valid integer number. This can also be set a build time.

Set Step Integer This is the Sfep at which the IntegerMachineGun will shoot. This must be a positive number. A Sfep of 1 will shoot all numbers, a Sfep of 2 will shoot every other number, a Sfep of 3 will shoot every third number and so on. This can also be set a build time.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The IntegerMachineGun has these outgoing events:

Outgoing Event Name Value Output Description

Shoot Int Integer This shoots out the next number in the sequence of numbers to be fired from the IntegerMachineGun. This is normally wired to a

IntegerMachineGun.

Finished Spray Null This event is fired when the IntegerMachineGun is done firing all of it's numbers. This way you can start another event based upon the fact that the IntegerMachineGun is done with it's events.

Remarks

None Launch Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

The Launch component is used to start the first component is the main PureVis file. It basically sets the starting point from which all other events happen.

Remarks

The Launch component is normally used to start logic components in the main PureVis file. It is not a required component.

You may have only one Launch per PureVis file.

See Also Fan. Retriever

Note to Java/C++ Programmers

When a PureVis file is opened, the VisRunner application searches the vector of components for the first Launch and triggers it. If you have more than one Launch, there is no way of determining which will fire first. So it is recommended that you only use one Launch component.

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The Launch has these build properties:

Build Property Name Value Expected Description

Unique Id integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Launch component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build. Properties Incoming Events Outgoing Events Back to Top Incoming Events

The Launch has these incoming events: ,

None. Remarks

None

Overview Build Properties Incoming Events Outgoi g Events Back to Top Outgoing Events

The Launch has these outgoing events:

Outgoing Event Name Value Output Description

Initialization Null This event does nothing more than just start the first component.

Remarks

This is used to start the first component of the main PureVis file. The Launch is normally wired to a Fan.

Fl Lockers Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to temporarily store data.

Overview

A Lockers component is an assortment of storage spaces each identified by a key with a value or object within them. It is used to create temporary data storage, such as data storage for a session, and otherwise is very similar to the ustoreit component in functionality. In the current preferred embodiment, this means storage in memory (RAM), which may include a systems virtual memory. The toolset user need not understand the memory issues. Lockers serve to differentiate between fast, limited (expensive) storage for data that need not be recovered if a session is lost and permanently recorded, or less volitile data.

Remarks

The Lockers components is able to store any type of data. This includes, but is not limited to, numbers, strings, list, datacards, datacard piles and objects.

See Also

UStorelt. SQLInterroqator, TextStore

Note to Java/C++ Programmers None

Overview Build Properties IncomiηgJΞyents Outgoing Events Back to. Top Build Properties

The Lockers has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Lockers component. Naming components makes them easier to find during debugging.

Remarks

Each space within a Locker can have whatever type of data you want to place there. You can store a number in one key, a datacard in another key and a string in yet another key.

Overview BuildPrpperties Incoming Events Qutgoing.Eyϋnts Back„tP_Top

Incoming Events

The Lockers has these incoming events: Incoming Event Value Expected Description

Set Key Integer or String This sets the key for the Lockers. Once this key is set any Incoming event that affects the value at the key will affect this key only.

Set Value at Key Variant This sets the value at the key that was last set with the Sef Key incoming event. This value can be a number, string, list, datacard or object.

Return Value at Key Reverse Wire This returns the value at the key that was last set with the Sef Key

Incoming event. Clear Locker at Key TπggerJΞvent This clears the Locker at the key that was last set with the Set Key incoming event. This will delete both the Key and the Value at the Key.

This also affects any references to this same object.

Clear All Lockers Irιgger_Eve.nj This clears all the Lockers. This will delete both the Keys and the

Values at the Keys, thus making this a completely empty locker. This also affects any references to this same object.

New (Empty) Lockers Trigger Event This creates a new Locker that contains NO keys or values, without affecting any references_, to any objects that were already in the

Lockers.

Set Content List List This sets the Content list for the Locker. This list included both the keys and the values at the keys. This in normally set from a list that was returned from a previous Return Content List.

Return Content List Reverse Wire This returns the content list of the Locker. This list contains both the keys and the values at the keys. Return Keys Reverse Wire This returns a list of the keys for the entire Locker. This only contains the keys and does not include the values at the keys.

Remarks

None

Overview BuiJd _.Properties Incoming Events Outgoing Events Back Jo Top Outgoing Events

The Lockers have no outgoing events.

Remarks

None __

LongGun Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Eye rt.s Examples

Overview

A LongGun is used to store long numbers. The range of long number is from -9223372036854775808 to 9223372036854775807.

If you can use numbers that are between -2147483648 and 2147483647 ,then you should use an IntegerGun.

Remarks

IntegerGun components store Long numbers. This numbers can then be shot to another component or can be retrieved.

See Also

Integer Gun, Conditional Long

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back toXop Build Properties

The LongGun has these build properties:

Build Property Name Value Expected Description

Maximum Value Long This sets the MaximumValue for the LongGun. This can also be set at run time.

Minimum Value Long This sets the MinimumValue for the LongGun. This can also be set at run time.

Number to Send Long This sets the current value for the LongGun. This can also be set a run time.

Wrap Around ≤Isgg]e If this is checked then if a number reaches the maximum or minimum values then it will wrap around. As an example. You have the maximum set to 10 and the minimum set to 0. You have the NumberToSend set to 10. You then increment the number by one. With the WrapAround checked on the NumberToSend will then be 0. If it is NOT checked then the NumberToSend will remain at 10.

Unique Id integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the LongGun component. Naming components makes them easier to find during debugging.

Remarks

None Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The LongGun has these incoming events:

Incoming Event Value Expected Description

Set To Minimum Long This sets the Number To Send value of the LongGun to the current Minimum Value.

Set To Maximum Long This sets the Number To Send value of the LongGun to the current Maximum Value. Fire Away Trigger Event This tells the LongGun to Fire it's current Number To Send value. This fires the LongGun's Shoot Int Outgoing event. Decrement By 1

This Decrements the value of the current Number To Send by 1. If the number falls below the Minimum Value then it will remain at the current Minimum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Maximum Value.

Increment By 1 Trigger Event This Increments the value of the current Number To Send by 1. If the number is higher than the Maximum Value then it will remain at the current Maximum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Minimum Value.

Decrement By.. Long This Decrements the value of the current Number To Send by the number sent to it. If the number falls below the Minimum Value then it will remain at the current Minimum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Maximum Value.

Increment By.. Long This Increments the value of the current Number To Send by the number sent to it. If the number is higher than the Maximum Value then it will remain at the current Maximum Value unless the WrapAround box was check at build time, in which case the number will WrapAround and become the current Minimum Value.

Set Number To Send Long This sets the current Number To Send. This can also be set at build time

Return Long Long This returns the current Number To Send in the LongGun.

Set Maximum Value Long This sets the MaximumValue for the LongGun. This can also be set at build time.

Set Minimum Value Long This sets the MinimumValue for the LongGun. This can also be set at build time,

Remarks

None

Overview Build Properties Incoming Events OjutgpjngJE vents Back to Top Outgoing Events The LongGun has these outgoing events:

Outgoing Event Name Value Output Description

Shoot Int Long This tells the LongGun to Shoof the current value of the Number To

Send.

Remarks

None

Fl MailSender Component View Individually -Ccmpoj Undex

Overview Bujld Properties incoming Events Outgoing Events Examples

Used to send an e-mail.

Overview

A MailSender is used to compose and send an e-mail. You can set the to address, to address, from name, from address, subject and message.

Remarks

At this time the MailSender does not have the capability to send attachments. If you feel this would be a feature that you would use, please let us know.

See Also

MLGateway. SMSGateway, PVCIient, PVServer

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoin jΞyents Back to Top

Build Properties

The MailSender has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the MailSender component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back.to Top

Incoming Events

The MailSender has these incoming events:

Incoming Event Value Expected Description Set To Address String This sets the To Address of the person you are sending the e-mail to. This would look something like: yourname@PureVis.com. This is required.

Set To Name String This sets the name of the person you are sending the e-mail to. This is optional. If used, this is what will show up to the other person when they receive the e-mail. If this is not set, then the "To Address" will be shown instead.

Set From Name String This sets the name of the person who is sending the e-mail. This is optional. If used, this is what will show up to the other person when they receive the e-mail. If this is not set, then the "From Address" will be shown instead.

Set From Address String This sets the address of the person who is sending the e-mail. This is required.

Set Message String This sets the actual message itself. Technically this is not required, but it would not make a lot of sense to send a blank e-mail.

Set Subject String This sets the subject of the message. This is what will show up in the

"Subject" area. This is optional but recommended.

Send Message , Trigger Event This actually sends the message that you have created.

Remarks

None

Overview Build. Properties Incoming. Events Outgoing. Events Back to_Top

Outgoing Events

The MailSender has NO outgoing events:

Remarks

None

MessageRouter Component YiewJndwjduaNy C___^ηponenLLnd.ex

Overview Build Properties Incpming Events Outgoing.Events Examples

Used to route network messages.

Overview

A MessageRouter is used to route messages from either a PVServer or a PVCIient component.

Remarks

MessageRouter components can route incoming events based upon event names that can be selected by the wirer.

See Also

Msssag.e.SfiD_deχ, PVCIient, PVServer

Note to Java/C++ Programmers

None

Overview Build Properties IncpmjyngJEypjgte Outgoing. Events Back to Top

Build Properties

The MessageRouter has these build properties:

Build Property Name Value Expected Description

Out Events String This is a list of the names for all of the events being passed to either the Client or Server. If this is wired from a PVServer component then this is a list of the event names coming from the Client. If this is wired to a PVCIient component then this is a list of the event names coming from the server.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the MessageRouter component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing.Events Back p Tsp.

Incoming Events

The MessageRouter has these incoming events: Incoming Event Value Expected Description

Return MessageRouter Reverse Wire This is only connected from either a PVCIient or a PVServer's

Retrieve Message Router outgoing event. These event names will match the names that are sent via the MessageSender Component.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Outgoing Events

The MessageRouter has these outgoing events:

Outgoing Event Name Value Output Description <Event Name> String These Outgoing events are generated from the list created from the OutEvents during build time. These events are normally wired to a Fan for further processing.

Remarks

None

MessageSender Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A MessageSender is used to send messages to the PVCIient or PVServer components.

Remarks

MessageSender components can send any type of data. This includes, but is not limited to, a single number, a list of datacards or even the contents of a locker.

See Also

MessageRouter. PVCIient. PVServer

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back.t Tpp

Build Properties

The MessageSender has these build properties:

Build Property Name Value Expected Description

To Gallery <Toggle> If this box is checked then this message will be sent to the gallery also.

To Gallery Only Toggle> If this box is checked then this message will be sent ONLY to the gallery.

Message Name String This is the name of the message to be sent. This should contain only the standard characters. (A-Z, a-z and 0-9) You can not use spaces but you can use the underscore ( _ ). Example' Game_Score

Pkey integer This is the Pkey of the player the message will be sent to. A value of -1 will broadcast the message to all players.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the MessageSender component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back.toJCo

Incoming Events The MessageSender has these incoming events:

Incoming Event Value Expected Description

<Name of Event> String Once you set the Message Name during build mode, it will show up as the first Incoming event. When you wire something to this event the data that is being sent to it will be sent along with the message name which identifies the message.

Set Pkey Integer This sets the Pkey of the player who this message is going to be sent to. If this is set to -1 , then It will be sent to all players.

Remarks

None

Overview B.uild..Prpperties Incoming.Events Qjutgoing Events Back. to Top

Outgoing Events

The MessageSender has these outgoing events:

Outgoing Event Name Value Output Description

Retrieve Pkey from Network Reverse Wire This should be wired to the PVServer and will retreive the Pkey of the player who sent the message.

Remarks

None

Fl MLGateway Component Vie_y j_djγjdj_aJJ COmponenilndex

Overview Build.Prpperti.es Incoming Events Outgoing Events Examples

Overview

A MLGateway is used to send and receive data between either a WAP device (WML) or the Internet (HTML). It becomes a gateway to communicate with either.

Remarks

MLGateway components allow you to return data from a WML or HTML document via a "Get" or "Post" method. Then you can send back a WML or an HTML page. You can also examine the list of the Params, cookies and header that were sent back with each "Get" or "Post". And you also have the ability to send back a cookie as well.

See Also Cookielnterrogator. TextStore

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The MLGateway has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the MLGateway component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The MLGateway has these incoming events:

Incoming Event Value Expected Description

Set Param Key This sets the ParamReg for the next Ret Param at ParamReg event. This ParamReg must be one from the Param List.

Ret Param at Param Key Reverse Wire Once the ParamReg has been set this returns the actual value that is at the ParamReg. This is a String so if you are expecting a number you must convert it first.

Return Param List Reverse Wire This returns a list of all the Param's that were sent back with the last "Get" or "Post". This is a list and must be enumerated before you can set the ParamReg, which will enable you to Ref Param at ParamReg.

Write Text String This writes the WML or HTML text back for viewing. This is the actual WML or HTML page text.

Return Session Key Reverse Wire Add Cookie Object This Adds a Cookie that was created using the Cookielnterrogator. Ret All Cookies Reverse Wire This returns a list of all the Cookies that were sent back with the last

"Get" or "Post". This is a list and must be enumerated before you can set the cookie into a Cookielnterrogator,

Set Content Type String This must be set once before you Write Text. For WAP (WML) its text/vnd.wap.wml, and for HTML it is text/html. Ret Header Names Reverse Wire This returns a list of all the Header Names that were sent back with the last "Get" or "Post". This is a list and must be enumerated before you can set the HeaderReg, which will enable you to Ret Header at

HeaderReg.

Ret Header at Header Key Reverse Wire Once you have Sef the HeaderReg, this will return the actual header information that resides there. Set Header Key String This Set's the HeaderReg for the next Ret Header at HeaderReg incoming event.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The MLGateway has these outgoing events:

Outgoing Event Name Value Output Description Get Fired Null This event is fired if a "Get" method was sent to the visx file via a WML or HTML page. This does nothing more than just start the chain of events. It's up to you to decide what to do once the "Get" was fired.

Post Fired Null This event is fired if a "Post" method was sent to the visx file via a WML or HTML page. This does nothing more than just start the chain of events. It's up to you to decide what to do once the "Post" was fired.

Remarks

When either a Get or Post is received the MLGateway retains the Information for that Get or Post until another one comes in. This information can include a list of Params, Cookies and even the header information. E3

Musket Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing.Eyents Examples

Used to "fire" something to a component and then must be reloaded to fire again.

Overview

The Musket can be loaded with an integer, long, string, list, cardstacks and datacards. Once loaded it can then be fired. Once it is fired the object is sent to the component it was fired too and the Musket must be either loaded, or reloaded before it can fire again. If you try to fire an unloaded Musket you will get a clicked output event instead of the fired event.

Remarks

The ability to have the Musket fire anything from an integer or long to a string, list, cardstack and datacard makes it a very useful component.

See Also

Integer Gun. Switch

Note to JavatC++ Programmers

A Musket contains two data items, a boolean flag and a the data type to be fired. Because of this separation, a "loaded" musket can fire nulls and an unloaded one can still contain ammo.

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The Musket has these build properties:

Build Property Name Value Expected Description

Load On Creation <Toggle> If this is checked then the Musket will be loaded initially. So if the Musket is fired then the output event will be fired and not clicked. It will, however, fire a null value unless it was loaded with something else.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Musket component. Naming components makes them easier to find during debugging.

Remarks

None

Overview BjULildJ rpperties Incoming Events Outgoing. Events Back to Top Incoming Events The Musket has these incoming events:

Incoming Event Value Expected Description

Load Variant This loads the Musket with whatever was passed to it. Once loaded the Musket will fire the value or object stored here when it's told to fire. It is possible to load a Musket with a null.

Reload Trigger Event Reload causes the Musket to load whatever was last loaded prior to firing.

Unload Trigger Event Unload unloads whatever was last loaded into the Musket. This will cause the Muskets click output event to fire if the Musket is fired. This does not set the ammunition data to null.

Fire Trigger Event This will cause the Musket to fire. If it was loaded first then the Muskets fire output event will be triggered. If it is not loaded or was untoadec/then the Muskets click event will be triggered.

Remarks

None

Overview Build. Properties Incoming Events OutgpingJEyents Back Jto Top Outgoing Events

The Musket has these outgoing events:

Outgoing Event Name Value Output Description

Click Variant This click event is processed if the Musket's fire input event was triggered and it is NOT loaded. The value passed through here is the last value that was loaded into the Musket. If no value was ever foaded then it passes a null.

Fired Variant This fired event is processed if the Musket's fire input event was triggered and it is loaded. The value passed through here is the last value that was loaded into the Musket.

Remarks

None

NullCheck Component View Individually Component Index Overview Build Properties Incoming Events Outgoing Events Examples

Used to check if an object or value is Null.

Function

A NullCheck is used to determine if the item is question is null.

Remarks

The following are not considered null values:

• A numeric value of 0

• An empty list of objects

• An empty string. IE ""

A value is considered "empty" when it at one point in time had data. For example, retrieving sO from a StringTeam before any value has been set will return null. Setting sO and then clearing It will return "empty". Functionality is on the way for NullCheck to cause seperate events for null and empty. In the meantime, if the value passes a null check, it can then be passed to an interrogator and evaluated. Examples:

• To determine whether a string is empty: Set into a String Interogator and retrieve the string's length. If the string size is 0, the list is empty.

• To determine whether a list is empty: Set into an Enumerator and retrieve the list size. If the list size is 0, the list is empty.

See Also Retriever

Note to Java/C++ Programmers

None.

Overview Build Properties Incoming JΞy.ents Outgoing Events Back.to.Tpp Build Properties

The NullCheck has these build properties:

Build Property Name Value Expected Description

Unique Id integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the NullCheck component. Naming components makes them easier to find during debugging.

Remarks If you send a numeric value of 0 or an empty string through the NullCheck it will NOT be flagged as being null. c value of 0 or an empty string ("") through the NullCheck it will not be flagged as being null, nor will a DataCard with no fields or an empty DataCardPile.

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The NullCheck has these incoming events:

Incoming Event Value Expected Description

Null Check Variant Determines whether the passed data is a null or non-null. The result is fired through outgoing events Is Null or Nof Null.

Remarks

If you send a numeric value of 0 or an empty string ("") through the NullCheck it will not be flagged as being null, nor will a DataCard with no fields or an empty DataCardPile

Overview Build Properties Incoming Events Outgoing Events Back.tpTpp Outgoing Events

The NullCheck has these outgoing events:

Outgoing Event Name Value Output Description

Is Null Null Fired if the value passed into the NullCheck was null.

Not Null Variant Fired if the value passed into the NullCheck was not null. The value or object that was checked is also sent through.

Remarks

If you send a numeric value of 0 or an empty string through the NullCheck it will not be flagged as being null.

Overview Build Properties IncomingJΞvents Outgoing Events Back to Top Examples

Requirements

If the Example Library is not already installed on your system, you may need to download it. To do so, download examplelibrary.zip and unzip it to your c:\purevis directory. The required sub-directories will be created automatically.

Examples

• Functionality Example

(c:\purevis\library\nullcheck\nullcheck.pvt) Example Focus: All null check events

The example shows how to use the various events of the Null Check. Retrieving "sO" from a StringTeam before sO has been set to a value will return a null value. This will be used to show the component's functionality.

Ξ PVCIient Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to communicate with the PVServer.

Overview

A PVCIient is used to send data to the server and to receive data from the server.

Remarks

PVCIient components perform data transfer between the client and server. They are always wired to the MessageRouter component.

See Also

PVServer. MessageRouter. MessageSender

Note to Java/C++ Programmers

None

Overview Build Properties Incoming. Events Outgoing. Events Back tpTop

Build Properties

The PVCIient has these build properties:

Build Property Name Value Expected Description

Server Url String This is the url of the server side visx file for the game.

Print Debug <Toggle> This causes all events that are received by the PVCIient component to be printed to the out log.

Http Url Inteαer This is the url of the server. It will always end with /pvserv.

Server Visx File Name String This is the file name of your server visx file. This should include the path as well.

PV Name String Optional. A name to be specified for the PVCIient component. Naming components makes them easier to find during debugging.

Remarks

None

Overview BuJJd...Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The PVCIient has these incoming events:

Incoming Event Value Expected Description Connect TriggerJΞyent This is only used when running the visx file through Visrunner. You should wire a clickable button to this to bring up the connection Login Window. This will connect you as a game player.

Disconnect Triggej Eyent This is only used when running the visx file through Visrunner. You should wire a clickable button to this to disconnect when you want to quit a game. This MUST be wired or you will need to exit from PureVis to stop the process from running.

Connect as Gallery Trigger Event This is only used when running the visx file through Visrunner. You should wire a clickable button to this to bring up the Gallery connection Login Window. This will connect you as a gallery user.

Remarks

None

Overview Build Properties Incoming Events Outgoing .Events B_a.ck.to_X.op

Outgoing Events

The PVCIient has these outgoing events:

Outgoing Event Name Value Output Description

Retrieve Message Router Revejrse Wire This event MUST be wired directly to a MessageRouter's Return Message Router incoming event. The MessageRouter is then used to route the incoming messages from the server.

Remarks

None

Fl , PVPlug Component View Individually support Links

Overview Build Properties Incoming Events Outgoing Events Examples

Used to exchange data between 2 VIS files.

Overview

A PVPlug is used to connect the visx file where it resides with another visx file. Then they are able to share in and out events.

Remarks

None

Note to Java/C++ Programmers

None

Overview Build Properties ljιcp ng_Eyents Qutgσi.ηgJ_yents. Back to Top

Build Properties

The PVPlug has these build properties:

Build Property Name Value Expected Description

Fife Url String This is the Url of the file that you want to connect to. The file you are connecting to must be saved as a visx file.

Reparse Events <Action Click > This causes the PureVis file to look for the file specified in the FileUrl box and rebuild the event lists. You should check the out log to make sure that the file was found.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the PVPlug component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing.Eyents Back Jo Top Incoming Events

The PVPlug has these incoming events: The incoming events that show up here will match the outgoing events of the visx file that you parsed with it. The value passed through these events can be anything.

Remarks

None

Overview Build Properties Incoming Events Outgoing. Events Back to Top Outgoing Events

The PVPlug has these outgoing events:

The outgoing events that show up here will match the in events of the visx file that you parsed with it. The value passed through these events can be anything.

Remarks

None

Fl PVServer Component VjewJndiyiduaJly Component Index

Overview BuildJProperties Incoming Events Outgoing Events Examples

Used to send and receive data to and from a PVCIient.

Overview

A PVServer is used to communicate with a client. It can send data to the client and can also receive data from a client.

Remarks

PVServer component is always connected to a MessageRouter. This is used to route the messages that are received from the client.

See Also

PVCIient, MessageRouter. MessageSender

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgojng.Eyents Ba.ck_tp.Top

Build Properties

The PVServer has these build properties:

Build Property Name Value Expected Description

Maximum Users Integer This sets the Maximum number of Users that can play the game at the same time.

Has Gallery <Tpggle> If this box is checked then the game will have a gallery. Users can join the gallery just to watch. Once you start a game with this box checked it will show up in the game list as both a game and as a gallery. *

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the PVServer component. Naming components makes them easier to find during debugging.

* Keep in mind that if your game has a gallery, you must make sure that you wire specific events for the gallery.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The PVServer has these incoming events: Incoming Event Value Expected Description

Return Current Pkey Integer This returns the Pkey of the current player who is accessing the server file. This is a unique integer number.

Return Current User Name String This returns the name of the current player who is accessing the server file.

Remarks

Each time a player starts the PureVis Front Door he is given a unique Pkey number This number is used to identify him while he is playing. This Pkey stays with the player until he closes out the PureVis Front Door. And the next time he opens it, he will be given another unique Pkey number.

Overview Build Properties Incoming Events Outgoing Events Back to To

Outgoing Events

The PVServer has these outgoing events:

Outgoing Event Name Value Output Description

Retrieve Message Router Object This event is fired whenever a message is sent from the client by a user who is playing the game. This should always be connected to the

MessageRouter. The the MessageRouter will route the message to the correct place. You should use a separate Message Router for the game and for the gallery.

User Joined (Pkey) integer This event is fired whenever a user joins a game. The users Pkey is also sent.

Lost User (Pkey) Inteqer This event is fired whenever a user leaves a game. The users Pkey is also sent.

Gallery Join (Pkey) Integer This event is fired whenever a user joins the gallery. The users Pkey is also sent.

Left Gallery (Pkey) Intege.r This event is fired whenever a user leaves the gallery. The users Pkey is also sent.

Push Last Pkey Integer Any time a user accesses the server file this event is fired. The exception to this would be the Lost User (Pkey) and the Left Gallery

(Pkey).

Remarks

None Fl

PVSocket Component Yl^wJ.ndiyidyally Conap Ln Lindex

Overview Build Properties Incoming Events Outgoing Events Examples

Used to send data between two PureVis files.

Function

A PVSocket is used to create in and out events that can then be parsed with another PureVis file. Thus they can share data or send messages back and forth.

Remarks

None

See Also PVPlug

Note to Java/C++ Programmers None

Overview Build Properties Incoming Events Outgoing Events Back tp.To

Build Properties

The PVSocket has these build properties

Build Property Name Value Expected Description

Plug Icon Url String This is the Url location of an Icon. This icon will then replace the generic plug icon. This helps to keep track of your plugs if you have a lot of them.

Out Events String This is the name of the OutEvents associated with the .PureVis file. Each name should be followed by a carraige return except for the last one in the list.

Print Debug Info <Joggle> This will cause the debug info to be printed to the outlog each time the PVSocket component is accessed.

In Events String This is the name of the InEvents associated with the .PureVis file. Each name should be followed by a carraige return except for the last one in the list.

Unique Id lnte.ger PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the PVSocket component. Naming components makes them easier to find during debugging.

Remarks

None Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The PVSocket has these incoming events:

The incoming events are taken from the PVSockets InEvents that were entered in the properties box. The value passed through these events can be anything.

Remarks

None

Overview Build Properties Incoming Events Outgoing . Events. Back to Top Outgoing Events

The PVSocket has these outgoing events:

The outgoing events are taken from the PVSockets OutEvents that were entered in the properties box. The value passed through these events can be anything.

Remarks

None

RandomNumber Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to generate random numbers.

Overview

A RandomNumber is used to generate a random number within a certain range. You can set the minimum and maximum values.

Remarks

RandomNumber components perform random number generations You can also set a seed which will cause the

RandomNumber component to generate the same sequence of random numbers.

See Also

Integer Gun, Integer Machine Gun

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The RandomNumber has these build properties:

Build Property Name Value Expected Description

Minimum Integer Sets the Minimum value the RandomNumber will generate.

Maximum Integer Sets the Maximum value the RandomNumber will generate.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make It easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name S.tring Optional. A name to be specified for the RandomNumber component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The RandomNumber has these incoming events: Incoming Event Value Expected Description

Fire Random Trigger Event Tells the RandomNumber component to fire a random number within the preset Maximum and Minimum values.

Return Random Intege.r Returns a random number from theRandomNumber component within the preset Maximum and Minimum values.

Set Minimum Inteqer Sets the Minimum value the RandomNumber will generate.

Set Maximum Integer Sets the Maximum value the RandomNumber will generate.

Set Seed Integer Sets the seed for the next number generated by the RandomNumber component. Once set, the RandomNumber component will generate the same sequence of numbers.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The RandomNumber has these outgoing events:

Outgoing Event Name Value Output Description

Random Target Integer This Output event is fired when you tell the RandomNumber component to Fire Random.

Remarks

None

Fl

Retriever Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to retrieve and distribute data to multiple sources.

Function

A Retriever is used to retrieve and then deliver data. Once a Retriever is told to fetch, it will first retrieve data via its retrieve event, then deliver the data to multiple sources via deliver events. The delivery events start with deliverO, and will continue to the last deliver event. A Retriever can have an unlimited number of deliver events.

Remarks

Retriever components can retrieve and deliver any type of data. This includes integers, longs, strings, objects and lists.

See Also

Fan, Integer Gun

Note to Java/C++ Programmers

Because the retriever is distributing data references, or copies of integer, long and string it is possible to distribute the same data to multiple components.

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The Retriever has these build properties:

Build Property Name Value Expected Description

Maximum Deliveries Integer Declares how many outgoing Deliver events the Retriever will provide. PureVis will bypass any unused Deliver Events.

Shift Events Down <Action Click > Shifts all Deliver Events down by one. This is often useful when adding an additional chain of processes before other Deliveries Events should be called. If you click this and the last event is currently used, that wire will be lost.

Insert Delivery <Action Click > Used to insert a new delivery event. Just enter the number of the event where you want the new event to be inserted, and it will move all the other events down. If necessary it will also create a new event at the end.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Retriever component. Naming components makes them easier to find during debugging. Remarks

None

Q.vejyiew_ B.uild.P.rpp_e.rties Incoming Events Outgoing„Eyents B_ack_.to_.Tpp Incoming Events

The Retriever has these incoming events:

Incoming E.ent Value Expected Description Fetch Trigger Event Calls on the Retriever to retrieve data its retrieve Event and distribute the data to multiple destinations via Deliver events.

Skip Remaining Deliveries Trigger Event Will stop the Retriever from processing any further Delivery Events after Skip Remaining Deliveries has been called.

Remarks

None

Overview Build Properties Incoming Events QjjtgpjngJEvents Back to Top Outgoing Events

The Retriever has these outgoing events:

Outgoing Event Name Value Output Description

Retrieve Reverse Wire Causes the Retriever to retrieve data from the target event. This can be numbers, strings, objects or even lists.

This must be wired to an event that begins with "return" to insure it is getting data. If not, an error may occur.

Deliver Variant Delivers retrieved data to a target component.

Remarks

The term Reverse Wire is used to refer to the ability of certain components to retrieve data from another component. Normally when a component is Wired to another component, it is delivering data. If the component has this Reverse Wire capability, it will retrieve the data first and then perform its normal sequence of wired events. In this case the Retriever will first retrieve the data it is wired to and then deliver it to other destinations.

Overview Build.Properties Incoming Events Outgoing Events B.ack.to Jpp Examples

Requirements

If the Example Library is not already installed on your system, you may need to download it. To do so, download examplelibrary.zip and unzip it to your c:\purevis directory. The required sub-directories will be created automatically.

Examples

Retriever Fetch & Deliver Example • Retriever Skip Remaining Example (c:\purevis\library\retriever\fetch_and_deliver.pvt) (c:\purevis\library\retriever\skip_remaining.pvt)

Example Focus: Example Focus:

"Fetch" and "Deliver" events. "Skip Remaining Events" incoming event.

The example shows a Retriever retrieving a pre-set The example shows a Retriever attempting to string from a TextStore, and delivering it to multiple deliver debug components. "Hello" to 7 different fans. However, the 3rd fan will instruct the Retriever to skip its remaining events.

In all, only 3 "Hello" strings will be delivered.

SChat Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A SChat is used to control the input and output of chat to the server.

Remarks

SChat components perform the handling of input and output chat messages from users Thus enabling the wirer (toolset user) to route the chat messages to the appropriate user/s.

See Also

MessageSender, MessageRouter, PVCIient, PVServer

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The SChat has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the SChat component Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The SChat has these incoming events:

Incoming Event Value Expected Description

Set Pkey Name String This sets the name of the player in the SChat component. You must first set the Current Pkey prior to setting the name. Both of these can be retrieved from the PVServer component. This need to be set Set Current Pkey Integer This sets the Pkey of the current player. This must be set prior to calling the Set Pkey Name or the Set Message & Send Incoming events.

Set Message & Send String .This sets the Message to be sent out to all players that have been added to the SChat component. You must first set the Pkey of the player sending the chat message.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The SChat has these outgoing events:

Outgoing Event Name Value Output Description

Send Pkey Integer Whenever the SChat's Sef Message & Send incoming event is called, the SChat fires this event. This must be wired to the MessageSender's Set Pkey incoming event. The SChat will then fire the Send Message outgoing event. This process is continued for ALL players that were added to the SChat component.

Send Message String Whenever the SChat's Sef Message & Send incoming event is called, the SChat fires this event. This must be wired to the MessageSender's Sef Message incoming event. The SChat will first fire the Send Pkey outgoing event prior to firing this one. This process is continued for ALL players that were added to the SChat component.

Remarks

None

Ξ

SMSGateway Component Vi.ew. I rjdiyiduaily Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A SMSGateway is used to send and receive SMS Messages.

Remarks

None

See Also SJMSJnlejrjrogator., TextStore

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The SMSGateway has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the SMSGateway component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The SMSGateway has these incoming events:

Incoming Event Value Expected Description

Send SMS Message Object This tells the SMSGateway component to send the SMS message that was just sent to it. This SMS Message must have been setup and then retrieved from an SMSInterrogator first. Remarks

None

Overview Build Properties jn.cpml.ng.Ey_ents Outgoing Events Back to Top

Outgoing Events

The SMSGateway has these outgoing events:

Outgoing Event Name Value Output Description

Status Message Received Object This event is triggered with each SMS message that is sent out. This lets you know the status of your SMS message that was sent out. This MUST be wired to the SMSInterrogator either directly or indirectly. Then you can use the SMSInterrogator's Ref Sfafus Code and Ret Status Text to get the status of the SMS message that you just sent.

Reply Message Received Object Not used at this time. Normal Message Received Object This event is triggered when an SMS Message is received. This MUST be wired to the SMSInterrogator either directly or indirectly.

Remarks

None

Ξ SMSInterrogator Component Vi__w j_ιd|yjd_^jal]y _Cj_Q]ponent Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A SMSInterrogator is used to get and set information about an SMS Message.

Remarks

The SMSInterrogator has the ability to return specific information about an SMS Message. This can include the text, possible message choices, who sent the message, when it was sent and any status messages. When you use it to create an SMS Message to send out you can still set the items mentioned above along with turning the Allow Response and Allow Delivery Notification on or off.

See Also SMSGateway

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Build Properties

The SMSInterrogator has these build properties:

Build Property Name Value Expected Description

Unique Id integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the SMSInterrogator component.

Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The SMSInterrogator has these incoming events:

Incoming Event Value Expected Description

Set SMS Message Siring This sets the SMS Message that was received from the SMSGateway. Once set you and query any of the Return events. (Ref)

Return SMS Message Reverse Wire This Returns the SMS Message that was created from within the SMSInterrogator. Once returned it is sent to the SMSGateway to be sent.

Set Time Stamp String This is how you Sef the Time Stamp. The ISO8601 standard is used. The format is as follows: CCYY-MM-DDTHH:MM:SS Date format where CCYY is the four-digit (2002), MM is a two-digit month number (01-12), DD is the two-digit ordinal number of the day within the calendar month (01 -31 ), and the separator character is a "Hyphen"("- "). Time format where HH is the two-digit hour in 24 hour notations (00- 24), MM is the two-digit minute (00-59), SS is the two-digit seconds (00-59), and the separator character is a "Colon"(":"). This format is the Extended Format described in the ISO8601 Section 5.2.1.1 with the separators as described in ISO8601 Section 4.4.

Return Time Stamp Reverse Wire This Returns the Time SStamp. See the Sef Time Stamp event for the format. Set Message ID String This Sefs fΛe Message ID. The Message ID must be unique for a particular sender for the duration of the lifetime of this message transmission and the receipt of one or more responses. The length of the message ID string is limited to 254 octets.

Return Message ID Reverse Wjre This Returns the Message ID. See the Set Message ID event for more information.

Set Recipient String This Sefs the Recipient. This is a unique identifier for the message recipient. The length of the message ID string is limited to 254 octets.

Return Recipient Reverse Wire This Returns the Recipient.

Set Payload String This Sets the Payload. The Payload is the actual text that is sent.

Return Payload Reverse Wire This Returns the Payload.

Set Payload Choice Index Integer This Sets the Payload Choice Index. This is a number from 0 to 5. Once you set this you still need to set the Payload Choice at 10 in order the set the text for the choice.

Set Payload Choice at 10 String This sets the actual text for the Payload Choice for the currently selected index number. (0-5)

Return Payload Choice at 10 Reverse Wire This returns the actual text for the Payload Choice for the currently selected index number. (0-5)

Set # of Payload Choices integer This sefs the # of possible Payload Choices. If this is set to 2, then the valid Payload Choices would be 0 and 1. Six is the maximum.

Return # of Payload Choices Reverse Wire This returns the # of Payload Choices.

Allow Response Trigger Event If this is triggered then a Response will be allowed by the person that the message was sent to. If you do not want to allow a response then use the Disallow Response event instead. The default is to allow a response.

Disallow Response Trigger Event If this is triggered then a Response will NOT be allowed by the person that the message was sent to. If you do want to allow a response then use the Allow Response event instead. The default is to allow a response.

Allow Delivery Notification Trigger Event If this is triggered then a Return delivery notification will be sent back from the server that the SMS Message was sent too notifying you that the message was received. If you do not want to be notified then use the Disallow Delivery Notification event instead. Default setting is not to allow delivery notification.

Disallow Delivery Notification Trigger Event If this is triggered then a Return delivery notification will NOT be sent back from the server that the SMS Message was sent too notifying you that the message was received. If you DO want to be notified then use the Allow Delivery Notification event instead. Default setting is not to allow delivery notification.

Ill Set Originator String This sets the Originator. This should be set with the same value that you retrieved with the Return Originator incoming event. You can NOT use the same SMSInterrogator to build the SMS Message that you are sending out, as you did for reading the SMS Message that was sent in. So the process would be to Ret Originatorfrom the incoming SMSInterrogator and then set that same value in the SMSInterrogator that you are using to construct your SMS Message that you are going to send back, with the Sef Originator event. If you want to send this message via e-mail then you must also call the Set Originator - Email Address.

Return Originator Reverse Wire This returns the Originator of the previously set SMS Message in the SMSInterrogator. This is used to set the originator in the SMSInterrogator of the SMS Message that you are going to send back.

Set Tracking Number String This sets the Tracking Number. This can be used for tracking purposes.

Return Tracking Number Reve.rs.e Wire This Returns the Tracking Number of the SMS Message that was sent. Set Response Code Integer This sets the response code for the last SMS Message that was received. If you don't set this it will default to success code 200. If you change this you MUST use an response code in the range of 900-999. You can use any number you wish within that range and you can also add whatever text you want to send along with it. See Sef Response Text Incoming event.

Return Response Code Reverse Wire The returns the response code of the last SMS Message that was received . This will always be success code 200. If an error code was encountered it will only show up in the error log and you can then use the error_.code chart to find out what the error was.

Set Response Text This sefs the Response Text for the last SMS Message that was received. This is a brief description of the status of the message that was sent. If you don't set this it will default to success code 200 text which is "Message accepted". If you change this use a response text that describes the error. You must also set the Response Code.

Return Response Text Reverse Wire This Returns the Response Text of the last SMS Message that was received . This is a brief description of the status of the message that was sent. This will always be "Message accepted" unless you have changed it. If an error_code.was encountered it will only show up in the error log and you can then use the error code chart to find out what the error was.

Return Status Code Reverse Wire This returns the Status Code of the last message that was just sent out. This can only be checked from an SMSInterrogator that is wired from the SMSGateway component's Status Message received Outgoing event. This is taken from the WCTP standard numeric success or error codes.

Return Status Text Reverse Wire This returns the Status Text of the last message that was just sent out This can only be checked from an SMSInterrogator that is wired from the SMSGateway component's Status Message received Outgoing event. This is taken from the WCTP standard numeric success or error codes.

Create SMS Message Trigger Event This must be called first prior to setting any values for the new SMS Message.

Set Originator - Email Address String This sefs the Originator tor e-mail sending. This should be set with the same value that you retrieved with the Return Originator incoming event. You can NOT use the same SMSInterrogator to build the SMS Message that you are sending out, as you did for reading the SMS Message that was sent in. So the process would be to Ref Originator from the incoming SMSInterrogator and then set that same value in the SMSInterrogator that you are using to construct your SMS Message that you are going to send back, with the Sef Originator event.

Return Originator - Email Reverse Wire Not used at this time. Address

Set Email Address Subject String This sets the Subject line for the E-mail being sent out.

Return Email Address Subject Reverse Wire Not used at this time.

Remarks

For a closer look at the process involved with receiving and sending an SMS message Click here.

Overview Build.Properties Incoming Events Outgoing Events Back.tP.Xpp Outgoing Events

The SMSInterrogator has no outgoing events.

Remarks

None

SQLInterrogator Component VJewJ_ndivjd_uaJy CO_mRp_n___LLndex

Overview Build Properties Incoming Events Outgoing Events Examples

Used to create and change data in a MySQL database..

Overview

A SQLInterrogator is used to actually run MySQL statements. The results are then stored in a DataCard.

Remarks

For those who are not familiar with MySQL we will give you a brief run down of the most widely used commands, and show you how to use them.

See Also

UStorelt, Lockers, TextStore

Note to Java/C++ Programmers

None

.Overview Build Properties Incoming Events Outgoing Events Back tp Tp Build Properties

The SQLInterrogator has these build properties:

Build Property Name Value Expected Description Debug <Tpggle If this box is checked then debug information will be printed to the log whenever the SQLInterrogator component is accessed. This information includes the following: Your executing SQL statements. A more detailed account of any errors encountered during the execution of your SQL statement. And in processing the results of the SELECT SQL statement, the column names and SQL data type.

Database Url String This is the Url of the Database. This is how Java knows which database to connect to. The default for MySQL is, jdbc:mysql://localhost/PureVis. This can also be set at runtime.

User Name String This sets the UserName for the database. This is the identification used by Wire to access your database tables. All privileges for this combination must be determined within your database before wire will work with it. This can also be set at runtime.

Password String This sets the Password for the database. This is the identification used by Wire to access your database tables. All privilege for this combination must be determined within your database before wire will work with it. This can also be set at runtime.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the SQLInterrogator component. Naming components makes them easier to find during debugging. Remarks

None

Overview Build. Properties Incoming Events Outgoing Events Back to Top Incoming Events

The SQLInterrogator has these incoming events:

Incoming Event Value Expected Description

Set Unique Id Table Name String This is the name of the table that will return a new unique number each time the Return Unique ID incoming event is triggered. There should be a Unique Id table for each game.

Return Unique Id Reverse Wire This returns the next Unique Id in the series. This is a Long number. Execute ext. Query This tells the SQLInterrogator to execute the SQL statement that is being sent to it. The SQLInterrogator can execute any real time queries.

Next Record R__________yire This returns the next record in the list from when the last SQL Statement was executed, And it also moves the pointer to the next record. If there are no more records then the End of Records Outgoing event is triggered In the SQLInterrogator.

Previous Record Reverse Wjre This returns the previous record in the list from when the last SQL Statement was executed. This also moves the record stack pointer back as well.

First Record Reverse. Wire This moves the record pointer to the ffrsf record in the record stack. Last Record Reverse Wire This moves the record pointer to the fasf record in the record stack. Return Result Set Size Reverse Wire This returns the Result Set Size of the last SELECT SQL Statement that was executed. This is an Integer.

Return # of Rows Affected Reverse Λ/ire This returns the number of rows that were affected by the last UPDATE, INSERT or DELETE SQL statement. This is an Integer.

Return Record ee DataCard Reve_rs.e W.ire This returns the record as a DataCard. When you retrieve a record as a datacard, it will have the column names as the keys and the data as values. Note, when you execute this, it will not advance the record pointer. You must call next to move to the next record in the result set.

Set Password String This sets the Password for the database. This is the identification used by Wire to access your database tables. All privilege for this combination must be determined within your database before wire will work with it. This can also be set a build time.

Set User Name String This sets the UserName for the database. This is the identification used by Wire to access your database tables. All privileges for this combination must be determined within your database before wire will work with it. This can also be set a build time.

Set Url String This is the Url of the Database. This is how Java knows which database to connect to. The default for MySQL is, jdbc:mysql://localhost/PureVis. This can also be set a build time.

Remarks

None Overview Build Properties Incoming Events Outgoing Events Back to Top Outgoing Events

The SQLInterrogator has these outgoing events:

Outgoing Event Name Value Output Description

End of Records Null This event is fired when there are no more records to read.

Remarks None

Fl

Stringlnterrogator Component Viewjndlyiduaily support Lⁱnks

Overview Build Properties Incoming Events Outgoing Events Examples

Used to check and manipulate strings.

Overview

A Stringlnterrogator is used to get information about and alter strings For example, you might want to extract a portion of a string or even just a character and then check it to see what it contains.

Remarks

None

See Also

Text Store. String Team

Note to Java/C++ Programmers None

Qyerview Build Properties Incoming Events Outgoing Events Back to.Top

Build Properties

The Stringlnterrogator has these build properties-

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name Stπng Optional. A name to be specified for the Stringlnterrogator component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to. Top Incoming Events

The Stringlnterrogator has these incoming events. Incoming Event Value Expected Description

Set String Stri.ng Sets the string to be examined or modified. Set Index Integer Sets the index position used for certain string functions. The first position is 0, which is the first character in the string.

Set Length from Index J.Qte_ger Sets the length of the "string work area" from the index. If you want all characters from the index to the end of the "string work area" then set this to -1. If the Length from Index + Index are greater then the String Length, then a "string index out of range" error will show up in the log when you try to execute a string event. This will also cause the program to halt.

Make String Chars Uppercase Trigger Event Converts all text in the "string work area" into uppercase letters. Push Uppercase String Tligger_Event Pushes all text in the "string work area" out as uppercase letters. This does not change the string left in the String Interrogator.

Make String Chars Lowercase Trigqer Event Converts all text in the "string work area" into lowercase letters. Push Lowercase String Trigger Event Pushes all text in the "string work area" out as lowercase letters. This does not change the string left in the String Interrogator.

Delete Chars Trigger Event Deletes the characters in the "string work area".

Push String w/deleted Chars Trigqer Event Pushes the string out with deleted characters.

Get Char String Retrieves the character at the current index.

Get Left Chars Strinα Returns the string to the left of the index, but not including the Index.

Get Right Chars String Returns the string to the right of the index and including the Index.

Get String Strino Returns the entire string regardless of the positions of the index and the length from index. If the string was altered it will return the altered string. The exception to this would be deleted characters.

Insert String Before Index String Inserts the text sent to in before the index. Push String Siring Pushes the entire altered string out. Get String Length Integer Returns the length of the string. Clear String Trigger Event Clears the string from the String Interrogator. Set Salt String Encrypts strings for use as passwords or other sensitive data. This is a string and must be 2 characters. It uses standard UNIX Crypt .

Return Encrypted String Stri.ng After you set the string and the salt this returns the encrypted string. Set Encoded Object Object Takes an object such as a datacard or even a pile of datacards and convert them into a string format that can be stored Into a database. Object encoding is a special function of the string interrogator. Encoding does not set nor affect any string also in the interrogator.

Return Encoded Object as String Returns the object as a string. The string can then be put into a String database. Object encoding is a special function of the string interrogator. Encoding does not set nor affect any string also in the interrogator.

Reset Token Position Nui! Resets the token position to the first token in the string. These tokens are separated by user defined delimiters

Add Delimiter Siring Delimiters are strings which mark and separate a larger string into pieces. The portion of a string between two delimiters is called a token.

You can have more than one value of string delimiter to tokenize a string.

Clear Delimiters Null Clears all of the delimiters you have added. Return Next Token Variant Returns the next token from the string. This token is the text between the user defined delimiters.

Remarks None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Outgoing Events

The Stringlnterrogator has these outgoing events:

Outgoing Event Name Value Output Description

Push Result String Pushes out the string that was told to push as an incoming event..

No More Tokens Null Event fires when there are no more tokens after a Return Next Token incoming event was triggered.

Remarks

None

Fl

Stringteam Component VLewjndj idually support Links

Overview Build Properties Incoming Events Outgoing Events Examples.

Used to compare 2 strings.

Overview

A StringTeam is used to compare or combine two strings. It has two "slots" each of which can be filled with a string. The slots are called SO and S1. Once you set strings into the slots, the strings are also referred to as SO (the string in slot SO) and S1 (yep, the string in s1) Sttrings can be compared against each other. You can also concatenate the two strings into one long string. You can get SO & S1 or S1 & SO. You can also append or prepend text to SO.

Appending adds text to the end of another string. Appending " cat" to "beautiful" gives you the string "beautiful cat."

Prepending adds text in front of another string. Prepending "Dodge " to "Caravan" gives you the string "Dodge Caravan".

Comparing strings:

Strings are compared one character at a time, the first character of SO against the first character of S1 , the second characters of SO against the second character of S1 , until a difference is found or there are no more characters to compare.

Strings are equal if each string has precisely the same characters in the same order.

A string is greater than another string if the ascii/unicode value for a character is greater than the ascii/unicode value of the corresponding character of the comparison string. Upper case letters values are greater than the lower case letter values for the same letter. So "Bat" is greater than "bat", "Bat" is greater than "bet", and "bet" is greater than "bat."

A string is lest than another string if the ascii/unicode value for a character is less than the ascii/unicode value of the corresponding character of the comparison string. Upper case letters values are greater than the lower case letter values for the same letter. So "Afghanistan" is less than "Bat", while "zebra" is less than "Afghanistan".

Remarks

Using both the StringTeam and the Stringlnterrogator you can do some very powerful string manipulation.

See Also

Text Store, String Interrogator

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The StringTeam has these build properties:

Build Property Name Value Expected Description

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the StringTeam component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The StringTeam has these Incoming events:

Incoming Event Value Expected Description

Set SO String Strinq Sets the SO String value.

Set S1 String String Sets the S1 String value.

Return S0S1 String Returns the string value of SO and S1 together.

Return S1S0 String Returns the string value of S1 and SO together.

Return SO String Returns the string value of SO.

Return S1 Position in SO Inteqer Returns the numeric position of the next instance of S1 found within SO. The search index is set with the Set Start Search Index first. If not specified it defaults to 0 which is the first character in the string SO. If no instance is found during the search it returns a -1.

Push S0S1 String Pushes out the concatenated string SO and S1.

Push S1 SO Strinα Pushes out the conatenate string S1 and SO.

Prepend to SO and Push String Prepends (adds string to the front of ) the string value sent to the SO string and pushes the results.

Append to SO and Push Strinq Appends (adds string to the back of) the string value sent, to the SO string and pushes the results.

Compare SO & S1 Triqger Event Compares the string value found at SO and S1 and pushes the results out. This compare IS case sensitive.

Compare Case Insensitive Trigger_. Event Compares the string value found at SO and S1 and pushes the results out. This compare is not case sensitive.

Return S1 String Returns the string value at S1.

Set Start Search Index Integer Sets the starting search index for searching if an instance of S1 is found in SO.

Clear SO String Trigger Event Clears the value at SO string to a "" (empty string). This is not the as a null.

Clear S1 String Trigger Event This clears the value at S1 string to ""(empty string). This is not the same as a null.

Remarks None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Outgoing Events

The StringTeam has these outgoing events:

Outgoing Event Name Value Output Description

Push Result Strinq Fires when you push out either strings. (SO or S1)

Equal Null Event fires if the result of a string compare shows the two strings are equal.

Not Equal Null Event fires if the result of a string compare shows the two strings are not equal.

SO Less Than S1 Null Event fires the the result of a string compare shows SO to be Less

Than S1.

SO Greater Than S1 Null Event fires the the result of a string compare shows SO to be Greater

Than SL

Remarks

None

Fl

Switch Component View indjyidua.y Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to switch and control the flow of wired events

Overview

A Switch is used to change the flow of your wiring based upon certain conditions.

Remarks

The Switch component can be wired to other Switch components to create a very elaborate switching system.

See Also

Retriever, Enumerator

Note to Java/C++ Programmers

A Switch is similar in design to a Case Statement. The main difference would be that the case must be selected first; data can then be send through once the case is selected.

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The Switch has these build properties:

Build Property Name Value Expected Description

Enable Default <Toggle> If this is checked then the Switches Default Target output event is activated.

Print Debug Info <Toggle> If this is checked then the Switch will print out debug info whenever the Switch is accessed.

Switch Names String This is how you set the names for the Switch. Each switch name in the list must end with a carriage return except for the last one.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Switch component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build_Properties Incoming Events Outgoing Events Bapk to_Tpp Incoming Events The Switch has these incoming events:

Incoming Event Value Expected Description

To Switch Variant Routes data through the Switch component.

Select Switch by Key String or Integer This will select the switch which has a particular key assigned to it. If the key matches none of the switches, and the Default is enabled, the Default switch will be selected. See Add Key to Selected Switch for more information.

Select Switch by Name String or Integer This will select the switch which has the submitted name. If the name matches none of the switches, and the Default is enabled, the Default switch will be selected.

Add Key to Selected Switch String or Integer This will assign a key to the currently selected switch. Multiple keys may be assigned to a switch. Keys are useful for grouping data. For example, "cat", "dog", and "horse" keys may be assigned to a "mammal" switch name, while "snake" and "lizard" keys are assigned to a "reptile" switch name. The appropriate switch may then be selected by key, rather than by the name of the switch.

Clear Key from Selected Switch String or Integer This will clear a submitted key from the currently selected switch. Collect Data to Switch by Key String or Integer Sets the switch by key with the data passed into the event, and then triggers the Retrieve Data to Switch event. The data retrieved will be passed through the newly set switch.

Collect Data to Switch by Name String or Integer Sets the switch by name with the data passed into the event, and then triggers the Retrieve Data to Switch event. The data retrieved will be passed through the newly set switch.

Enable Default Trigger Event Enables the Switch component's Default Target output event. When enabled, the Default Target output event will fire if a key or switch name is assigned, but not expected.

Disable Default Trigger Event Disables the Switch component's Default Target output event. When an unexpected switch name or key is received, an error will be generated.

Remarks

None

Overview Build Properties inc_om_ng .Events Outgoing Events Back to Top Outgoing Events

The Switch has these outgoing events:

Outgoing Event Name Value Output Description

Default Target Variant If an unexpected switch name or key is set into the switch, and data is passed through the switch, the data will be routed through the Default Target event. The Enable Default property must be checked on the Switch component before this event will be generated. Otherwise, an error will occur.

Retrieve Data to Switch Reverse Wire This event is triggered if either the Retrieve Data to Switch by Key or the Retrieve Data to Switch by Name incoming event was triggered. It Remarks

None

Overview BjuHd. Properties Incoming Events 0_u_tg.o.ing_Events B.ackJα Tpp

Examples

Requirements

If the Example Library is not already installed on your system, you may need to download it. To do so, download examplelibrary.zip and unzip it to your c:\purevis directory. The required sub-directories will be created automatically.

Examples

Switch Keys Example • Switch Names Example Switch Data Collect Example

(c:\purevis\library\switchV (c:\purevis\library\switch\ (c:\purevis\library\switch\ switch_keys.pvt) switch_names.pvt) collect_data.pvt)

Example Focus: Example Focus: Example Focus:

"Select Switch By Key" event "Select Switch By Name" event "Collect Data to Named Switch" event.

"Add Key" event "Default Target" event

The example shows how to have a

The example shows how to The example shows how to switch automatically retrieve data once route data through a switch route data through a switch a switch name is set. using switch names and keys. using switch names. Keys are a useful way to link multiple identifiers to a Note: To use the "Default particular switch for easier Target" event, you must check routing. the "Enable Default" property on the switch's build properties.

Fl TextStore Component View.lndiyLdualJy Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to store and alter text.

Overview

A TextStore is used to store text. The text can then be modified and the results can then be retrieved. The TextStore also has the ability to load text files.

Remarks

TextStore components can be set with text at build or runtime.

See Also

Strinq Interrogator. String Team

Note to Java/C++ Programmers

None

Overview Build Properties Incoming-Events Outgoing Events Back to Top Build Properties

The TextStore has these build properties:

Build Property Name Value Expected Description

Strings S.tring A list of strings. Once set, these strings can be returned by wiring a Retriever to fefcft them. These strings are also key names.

Unique id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the TextStore component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events Outgoing Events Back to Top Incoming Events

The TextStore has these incoming events: Incoming Event Value Expected Description

Return String Key List String Returns a list of all the String Keys. Lists are normally then sent to an Enumerator.

Set String Key String Sets the String Key with the value sent to it. And this becomes the selected String Key.

Set Value at String Key String Sets the Value at the currently selected String Key.

Clear Replacement String Key String Clears the String Key of only the String Key being sent to it.

Return Value at String Key String Returns the value at the currently selected String Key.

Set Text String Sets the text to whatever was sent to it. This overwrites whatever was in the TextStore previously.

Load Text String Loads text file. Expect the file location (directory path) and name of a text file to load. Can load any unformatted text file. ( .txt .wml .html and so on)

Return Text as is String Returns the unmodified text. This does not return the new text that was changed via the String Keys. Return Modified Text String Returns the modified text. This includes the new text that was changed via the String Keys.

Clear All Replacement String Trigger Event Clears ALL of the Replacement String Keys. Keys

Return Carriage Return String Returns a Carriage Return. This is useful when you need to add a Carriage Return to a line of text.

Return <string name> String Returns the name of the selected string name that was set at build time.

Remarks

None

Overview Build Properties Incoming Events O tgoingJEyents Back to Top Outgoing Events

The TextStore has NO outgoing events.

Remarks

None Timer Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Overview

A Timer is used to fire events at a specific interval.

Remarks

Timer components perform events that are based upon the passing of time. You can set the time between the events in milliseconds as well as setting how many events you want to occur.

See Also WallClock

Note to Java/C++ Programmers

None

Overview Build Properties Incoming Events Outgoing .Events Back to Top Build Properties

The Timer has these build properties:

Build Property Name Value Expected Description

Milliseconds Between Events [__ong This is the number of milliseconds that will pass before the next event will occur. 1000 equals 1 second. You can not set this below 0. The default is 2000. (Or 2 seconds)

Number of Events Integer This specifies how many events you want to have. You can not set it below 0. The default is 10. Unique Id Integej PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name String Optional. A name to be specified for the Timer component. Naming components makes them easier to find during debugging.

Remarks

None

Overview

Incoming Events Outgoing Events Back to Top Incoming Events

The Timer has these incoming events: Incoming Event Value Expected Description

Set Time Between Events (ms) Long This sets the time between events if milliseconds. This can also be set at build time.

Set # of Events Integer This sets the number of events that you want to occur. This can also be set at build time.

Start Timer Trigge.r.Event This tells the timer to start. Stop Timer Trigger Event This tells the timer to stop. It will stop even if it is not done processing all of it's events.

Remarks

None

Overview Buil.d.Prpperties Incoming Events Outgoing.Events Back.to Top Outgoing Events

The Timer has these outgoing events:

Outgoing Event Name Value Output Description

Fired Null This event is fired each time an event occurs. Completed Null This event is fired when all events have been completed.

Remarks

None

Ξ UStorelt Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Examples

Used to store data permanently.

Overview

Provides permanent data store of arbitrary objects on client or server using underlying third party file system for reliable scalable storage, shadowing, and for providing other back-up and high-availabilty and fast retrieval.

A UStorelt is used to store various types of data on hard drive of the computer where the PureVis file is being run from. If the file is being run from the client-side then the data will be stored on the clients computer. If the file is being run from the server-side then it will be stored on the servers hard-drive.

Remarks

The UStorelt, starts at the PureVis/purevis directory and creates a subdirectory one level down for each level of UStorelt, named with the String representation of the submitted key (which why it's STRONGLY recommended you use strings for the level 0 keys - most likely the name of the application or database, and strings or integers for the lower keys). In the directory of the last key, the UStorelt writes the file "pvdata.dat" using special Wire encoding (see encoding and decoding Fig 4 and 10) to store the data.

See Also

Lockers, SQLInterrogator. TextStore

Note to Java/C++ Programmers

None

Overview Build Properties Incoming .Events Outgoing Events Back.to Top Build Properties

The UStorelt has these build properties:

Build Property Name Value Expected Description

Number of Levels Integer This determines how many levels deep the data will go. Level Names String This is a list of the LevelNames. The number of these will match the number of levels that you selected. There is always 1 name per level.

Unique Id Integer PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name Siting Optional. A name to be specified for the UStorelt component. Naming components makes them easier to find during debugging.

Remarks

Since the UStorelt stores data in an area that is shared by all games it is highly recommended that you use at least 2 keys and the first key be used to set the name of the game.

Overview Build Properties Incoming Events Outgoing Events Back to Top

Incoming Events

The UStorelt has these incoming events:

Incoming Event Value Expected Description

Write Data Variant Calls on the UStorelt to write the data that is being sent to it into the database at the currently set keys.

Read Data Reverse Wire Calls on the UStorelt to read the data from the database at the currently set keys from within all the levels.

Set Key at Level 0: <name0> String This sets the key for level 0. if you have specified a particular name for the level it will show up inside the <> in place of nameO.

Return Keys at Level 0: Reverse Wire This returns the list of keys at level 0. This is a List. <name0>

Clear values at Level 0: TπggerJΞvent This clears any value that is at the last key that was set for this level, <nameO>

Remarks

For every level key that you have specified in the Number of Levels box at build time, you will have three entries as Incoming events. They are Sef Key at Level , Return Keys at Level and Clear Values at Level.

Since the UStorelt stores data in an area that is shared by all games it is highly recommended that you use at least 2 keys and the first key be used to set the name of the game. Thus you would set the Number of Levels to 2 and then you could name the first level GameName and the second level as PlayersName. As an example lets say that you had a game called Bowling and the players name was Denny. Then you would Set Key at level 0: GameName to "bowling" and then you would Set Key at level 1 : PlayersName to "Denny". Then you would write the data.

Overview Build Properties Incoming Events Outgoing Events Back to. Top Outgoing Events

The UStorelt has no outgoing events:

Remarks

None WallClock Component View Individually Component Index

Overview Build Properties Incoming Events Outgoing Events Exa.rnp.le_s

Overview

A WallClock is used to monitor time and help users convert it into multiple formats.

Remarks

WallClock components perform time keeping.

See Also TJtnex

Note to Java/C++ Programmers None

Overview Build Properties Incoming Events Outgoing Events Back to Top

Build Properties

The WallClock has these build properties:

Build Property Name Value Expected Description

Unique Id 3r PureVis automatically assigns a Unique ID to each component as it is added to a file. The default value is one higher than the Unique ID for the last component added to the file.Unique ID's make it easier to debug files. Debug messages contain the Unique ID of the component where an error occurs. You might have many retrievers in a file; the Unique ID lets you know which one has the problem.

PV Name Optional. A name to be specified for the WallClock component. Naming components makes them easier to find during debugging.

Remarks

None

Overview Build Properties Incoming Events 0_u_tgpingJE__e_nts. Back to Top Incoming Events

The WallClock has these incoming events:

Incoming Event Value Expected Description

Set TO Time Long This sets the time at register TO. This is the milliseconds that have passed since January 1, 1970. This is normally set by returning the modified date or time from register T1 with the Ref T1 time in milliseconds incoming event. At which point you can the return the date or time information that you require.

Return TO Milliseconds Reverse Wire This returns the milliseconds at register TO. This ranges between 0 and 999. This is a Long.

Return TO Seconds Reverse Wire This returns the seconds at register TO. This ranges from 0 to 59, This is an Integer.

Return TO Minutes Reverse Wire This returns the minutes at register TO. This ranges from 0 to 59. This is an Integer.

Return TO Hour Revej__e.Wi.re This returns the hour at register TO. This ranges from 0 to 23. This is an Integer.

Return TO Day of the Week Reverse. Wire This returns the day of the week at register TO. This ranges from 1 to 7. Sunday = 1 and Saturday = 7. This is an integer.

Return TO Day of the Month Reverse Wire .This returns the day of the month at register TO. This ranges from 1 to 31. This is an Integer.

Return TO Month Reverse Wire This returns the month at register TO. This ranges from 1 to 12. January = 1 and December = 12. This is an Integer.

Return TO Year Reverse Wire This returns the year at register TO. This is a 4 digit number. (I.e. 2002) This is an Integer.

Return Current Time Reverse Wire This returns the current time. This is the milliseconds that have passed since January 1 , 1970.

Set TO to Current Time String his sets TO to the current time.

Return TO Date Text Reverse Wire This returns the date at TO in a text format. ( February 4, 2002 )

Return TO Time Text Reverse Wire This returns the time at TO in a text format. ( 1 :59:49 PM PST )

Return TO Date & Time Text Reverse Wire This returns the date at TO in a text format. ( February 4, 2002 1 :59:49 PM PST )

Set T1 Hour Strinq This sets the hour for the T1 register. This ranges from 0 to 23.

Set T1 Minute String This sets the minutes for the T1 register. This ranges from 0 to 59.

Set T1 Day of the Month String This sets the minutes for the T1 register. This ranges from 1 to 31.

Set T1 Month String This sets the minutes for the T1 register. This ranges from 1 to 12.

Set T1 Year String .This sets the minutes for the T1 register. This is normally a 4 digit number. (2002)

Return T1 Time in Milliseconds Reverse Wire This returns the total number of milliseconds in the T1 register. This is calculated based upon how you set the seconds, minutes, hours, day of the month and year.

Set T1 Second String This sets the seconds for the T1 register. This ranges from 0 to 59.

Remarks

None

Overview Build Properties lnc__mjng„Events. Outgoing Events Back to Top Outgoing Events

The WallClock has no outgoing events.

Remarks Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES SUMMARY- INNER | FIELD | CONSTR [ METHOD DETAIL: FIELD | CONSTR I METHOD

purevis.core

Interface Buildlnfo

public interface Buildlnfo

Used with PureVis Beanlnfo interfaces to fully describe a PureVis component. The description includes, input and output events, icons and text descriptions.

When building components for the PureVis environment, each component consists of two different class files. The component itself and the Beanlnfo component.

This should be completely familiar to tradional JavaBeans developers. PureVis has a few extra items beyond those included in the Beanlnfo, these are in the Buildlnfo which needs to be implemented by the Beanlnfo for each individual component.

Method Summary

3 ava . lang .String getDisplayName ( )

A text string which will be used by the PureVis tool to describe the component on the toolbar. j va. lang .String cτetIcon (i va . lang . Obj ect ob)

Get a file name for an icon for the PureVis tool to use. j ava ut l. Hashtable getlnputEvents (j ava . lang . Obj ect ob) returns a list of input events for the component.

. av . ut-1.Hashtable gβtO tpu Eyents (Java. lang . Object ob) returns a list of output events for the component.

] ava . util . Hashtable geJtTarget ( j av . lang . Obj ect ob , int key)

Return the target for the output event specified by key. s____r_____et(Java. lang. Object ob, int key, Target target, int command)

When a user changes or adds a wire, PureVis will call the bean info for that component with the new event key and target.

Method Detail getOutputEvents public Java.util.Hashtable getOutputEvents (Java. lang.Object ob) returns a list of output events for the component. The list is a Hashtable: hashkeys=PureVis Event Keys data = the event description.

getlnputEvents public Java. til.Hashtable getlnputEvents (Java. lang. Object ob) returns a list of input events for the component. The list is a Hashtable: hashkeys=PureVis Event Keys data = the event description.

getTarget public Java.util .Hashtable getTarget (Java. lang.Obj ect ob, int key)

Return the target for the output event specified by key. At a minimum an empty hashtable should be returned. hashkey = The target component for the event hashdata = The command which will be sent to the target. PureVis will use this data to populate the Connection Info window.

Parameters: ob - The object on which should be used to find the specified event target. ey - The PureVis event key.

setTarget public void setTarget (Java. lang. Object ob, int key, Target target, int command)

When a user changes or adds a wire, PureVis will call the bean info for that component with the new event key and target. Use the information given to change the event in the object. Parameters: ob - The object who's output event was changed. e - The output event key. This was specified in getOutputEventsQ. target - The new target object for the event. comman - The command to send to the target when the event fires.

getlcon public java. lang. String getIcon(java. lang.Object ob)

Get a file name for an icon for the PureVis tool to use. In some cases (PVSocket/PVPIug), each object may use a different image as it may be specified in the component data itself. In most cases, just return a static image file name. For instance, Fan returns "./images/pvicons/Fanlcon.gif".

getDisplayName public java. lang.String getDisplayName ()

A text string which will be used by the PureVis tool to describe the component on the toolbar. This used to be the same name as the Java class, but was later changed when we needed to change the name of a component without changing the actual source code.

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER I FIELD | CONSTR | METHOD DETAIL: FIELD | CO.NSTR | METHOD.

purevis.core

Class CommandTarget j ava . lang . Obj ect

+--purevis . core. CommandTarget

All Implemented Interfaces:

Streamable

public class CommandTarget extends java. lang. Object implements Streamable

Used in PureVis events expecting return data from an input event. This is what a Retriever uses.

Components which implement return events to return data to retrievers should expect the CommandTarget type as the data to performCommand, and return the information in the following way.

• performCommand (int command, Object data) o { o switch (command)

- {

■ case EVENT_KEY: l

■ if (data instanceof CommandTarget)

■ (

■ CommandTarget targ = (CommandTarget) data ;

■ // send the [OBJECT] back to the event source

■ targ . getTarget ( ) . erformCommand (targ . getCommand O , [OBJECT] ) ;

- }

■ break;

- } o } Constructor Summary

Com andTarcret ( )

CommandTarget (int command, Target targ, java. lang. Obj ect data)

Methods inherited from class java. lang. Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait Constructor Detail

CommandTarget public CommandTarge ( )

CommandTarget public CommandTarge (int command,

Target targ, java. lang. Obj ect data)

Parameters: command - The command to pass back to targ in the return event targ - The target to use to send data back. da a - Rarely used, sometimes objects can forward data on to the event they want to retrieve something from.

Method Detail

getVersion public int getVersion () implementation of Streamable. Do not call directly. Specified by: getVersion in interface Streamable

getCommand public int getComman () get the command which the component requesting the return event is expecting.

setCommand public void setComman (int command) set the command which the component requesting the returnevent is expecting. getTarget public Target getTarget ()

Typically the component which requested the information and is expecting the return event found in getCommand

setTarget public void setTarget (Targe targ)

The target to send the return event to.

setData public void setDat (Java . lang . Object data)

Rarely used, but retrieve events may also pass data in the retrieve part of the event

getData public j ava . lang . Obj ect getData 0

Rarely used, but retrieve events may also pass data in the retrieve part of the event

encode public void encode (EncodeSt eam es) implementation of Streamable. Do not call directly. Retrievers retrieve events may someday be passed across the network. Specified by: encode in interface Streamable

Following Copied from interface: purevis . core. Streamable

Parameters: es - The EncodeStream to encode the object to

Sample Usage: es .writelnt (1, uniqueld) ; es . riteString (2 , String) ; es . writeVector (3 , aVector) ; es . writeHashtable (4, aHashtable) ; es . riteObject (5 , aTarget) ;

getNumberOfEntries public int getHumberOfEntries ( ) implementation of Streamable. Do not call directly. Specified by: getHumberOfEntries in interface Streamable

decodeltem public void decodeltem (p__.____e.Sfc__ea.i_ ds, int id, int key) implementation of Streamable. Do not call directly. Specified by: decodeltem in interface Streamable Following Copied from interface: purevis . core. Streamable

Parameters: ds - The DecodeStream to use for decoding items. id - Each unique encoded object is given an id by the encoder. That object will only be encoded once, later encodings will only make reference to the earlier encoding. This is used by decodeObject methond in the DecodeStream. ke - Each item you encode is given a unique integer key.

Sample Usage: switch (key)

{ case 1: uniqueld = ds . readlnt 0 ; break; case 2 : aString = ds . readString ( ) ; brea ; case 3: aVector = ds . eadVecto () ; break; case 4 : aHashtable = ds . eadHashtable () ; break; case 5 : aTarget = (Target) ds .readObj ect (id) break; default : ds . skipltem(id) ; break; }

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSIE | M ___0D DETAIL: FIELD | QQNSIB | METHOD

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | M.ETHOD DETAIL: FIELD. | CONSTR | METHOD

purevis.core

Class DecodeStream j ava . lang . Obj ect

I

+--purevis - core . DecodeStream

public class DecodeStream extends java. lang. Object

Constructor Summary

P_sc9d_eS_^r§._α? (java . io . DatalnputStream dataln)

Methods inherited from class java. lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toΞtring, wait, wait, wait

Field Detail classHash protected ava. util .Hashtable classHash

referenceHash protected java. util .Hashtable referenceHash

running protected boolean running

Constructor Detail

DecodeStream public DecodeStream(java. io. DatalnputStream dataln)

Parameters: datam - DecodeStream requires a DatalnputStream to us In reading a list of objects.

Method Detail

getNextReferenceld protected int getNextReferencel 0

readAll public java. util. Vector readAllO reads all the objects in the stream. Returns the list of object in a Vector.

decodeObject public java. lang.Object decodeObjec () decode a single object from the stream. Internal use only readlnteger public J va . lang. Integer readlnteger ( )

Deprecated. Use readlntegerObjectQ

readlntegerObject public j va. lang. Integer readlntegerOb ec ()

Decodes a single Integer from the stream. Typically called from a Streamable's decode method.

readlnt public int readlnt 0

Decodes a single int from the stream. Typically called from a Streamable's decode method.

readDouble public double readDouble ()

Decodes a single double from the stream. Typically called from a Streamable's decode method.

readDoubleObject public J ava . lang . Double readDoubleObj ec ()

Decodes a single Double from the stream. Typically called from a Streamable's decode method.

readString public java. lang. String readString () Decodes a single String from the stream. Typically called from a Streamable's decode method.

readLongObject public java. lang. ong readLongObject ()

Decodes a single Long from the stream. Typically called from a Streamable's decode method.

read Long public long read ong O

Decodes a single long from the stream. Typically called from a Streamable's decode method.

readBooleanObject public j va. lang.Boolean readBooleanObject ()

Decodes a single Boolean from the stream. Typically called from a Streamable's decode method,

read Boolean public boolean readBoolean ()

Decodes a single boolean from the stream. Typically called from a Streamable's decode method.

readVector public j ava. util . ector readVector ( )

Decodes a Vector from the stream. Typically called from a Streamable's decode method. readHashtable public java.util.Hashtable readHashtable ()

Decodes a Hashtable from the stream. Typically called from a Streamable's decode method.

readReference protected java. lang. Obj ect readReference ( )

readNullObject protected java. lang.Object readNullObject ()

readObject public java. lang. Object readOb ect (int objectld)

Decodes a single Object from the stream. Typically called from a Streamable's decode method. Must pass in the object id, which is passed to Streamable.decode().

skipltem public void skipltem (int id)

Call this when Streamable.decode() does not know what to do with a item key. This will happen if the stream was created with a later version of code which encodes new items the old code does not know about. The item will be skipped and process will continue unchanged.

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | _IELD | CONSTR | METHOD DETAIL: FIELD | CONSTR I METHOD Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | EIS-P | Cp ST.R | METHOD DETAIL: FIELD | CONSTR | METHOD

purevis.core

Class EncodeStream java.1 ng.Object

I

4---purevis.core.EncodeStream

public class EncodeStream extends java. lang. Object

The stream used to encode a list of components. You should not have to call this directly, it will be called for you by the PureVis tool itself or the networking components. In rare cases where you want to encode your own list of objects to create something like a Locker or MessageSender component, you can use EncodeStream to encode to a By teArray O utp utStrea m .

Field Summary static int

BOOLEAN ID

static nt

BOOLEANOBJECT ID static int

COMPOBJECT ID

static ltit

COMPRESSED

static int

DOUBLE ID

static int

DOTJBLEOBJECT ID

static rnt

HASHTABLE ID

static int

INT ID

Constructor Summary

EncodeStream (int versionType, java. io.DataOutputStream thisDos)

Method Summary encodeObj ect ( i ava . lang . Obj ect object)

Encode a single object into the stream void encodeOb ects ( ava . util .Vector v)

Takes a vector of Streamable objects and writes them to the stream. static _ava. lang. String objectToString( java . lang . Object obj )

Staic method for encoding an objec to a String writeBoolean (int key, boolean b) write a single boolean to the stream under the specified key. r_teB oleaιιOb ec_.t (int key, j ava . lang. Boolean b) write a single Boolean to the stream under the specified key. void w __L__epoαble ( int key, double x) write a single double to the stream under the specified key. writeDoubleObject (int key, Java. lang.Double d) write a single Double to the stream under the specified key.

Methods inherited from class java. lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

INTEGER_ID public static final int INTEGER_ID

INT___ID public static final int INT_ID

STRING ID public static final int STRING ID

LONGOBJECT JD public static final int LONGOBJECT ID

ONG_ID public static final int LONG ID

BOOLEANOBJECT__ID public static final int BOOLEANOBJECT ID

BOOLEAIMJD public static final int BOOLEAN_ID

I

VECTOR_ID public static final int VECTOR_ID

HASHTABLE_ID public static final int HASHTABLE ID

REFERENCE_ID public static final int REFERENCE ID

NULLOBJECT__ID public static final int NtTLLOBJECT_ID COMPOBJECT_ID public static final int COMPOBJECT ID

DOUBLE_ID public static final int DOUBLE ID

DOUBLEOBJECT_ID public static final int DOUBLEOBJECT ID

UNCOMPRESSED public static final int UNCOMPRESSED

COMPRESSED public static final int COMPRESSED

Constructor Detail

EncodeStream public EncodeStream(int versionType, java. io.DataOutputStream thisDos)

Parameters: versionType - UNCOMPRESS or COMPRESSED. COMPRESSED and UNCOMPRESSED may be a bit missleading. It is not actually using compression, but less data is written to the stream. Use COMPRESSED for short lived encodings of components. For things like network communications or temporary memory storage of components. thisDos - The DataOutputStream the EncodeStream will use to write components to. Method Detail

encodeObjects public void encodeObjects (Java. util .Vector v)

Takes a vector of Streamable objects and writes them to the stream. Each object's encode method will be called.

encodeObject public void encodeObjec (Java. lang.Obj ect obj ect)

Encode a single object into the stream

wrϊteNumberOfEntries public void riteNumberO Entries (int x)

Deprecated. Streamable.getNumberOfEntries is now called automatically by the EncodeStream.

writelnteger public void writelnteger (int key, java. lang. Integer I)

Deprecated, use writelntegerObject

wrϊtelntegerObject public void writelntegerObject (int key, j va . lang. Integer I) write a single Integer to the stream under the specified key.

Parameters: key - The key to identify this integer i - The Integer to write to the stream

writelnt public void writeln (int key, int x) write a single Integer to the stream under the specified key.

Parameters: ke - The key to identify this integer i - The int to write to the stream

wrϊteDouble public void writeDoublβ (int key, double x) write a single double to the stream under the specified key.

Parameters: ey - The key to identify this integer - The double to write to the stream

writeDoubleObject public void writeDoubleObjec (int key, java. lang.Double d) write a single Double to the stream under the specified key.

Parameters: ke - The key to identify this integer - The Double to write to the stream

writeString public void writeString (int key, j ava . lang . String s) write a single String to the stream under the specified key.

Parameters: key - The key to identify this integer s - The String to write to the stream

wrϊteLongObject public void writeLongObjec (int key, java . lang.Long ) write a single Long to the stream under the specified key.

Parameters: key - The key to identify this integer

L - The Long to write to the stream

writeLong public void writeLong (int key, long 1) write a single long to the stream under the specified key.

Parameters: key - The key to identify this integer i - The long to write to the stream

writeBooleanObject public void writeBooleanObject (int key, j va. lang.Boolean b) write a single Boolean to the stream under the specified key.

Parameters: key - The key to identify this integer b - The Boolean to write to the stream

wrϊteBoolean public void writeBoolean (int key, boolean b) write a single boolean to the stream under the specified key.

Parameters: e - The key to identify this integer b - The boolean to write to the stream

write Vector public void writeVector (int key, java. til .Vector v) write a java.util.Vector to the stream under the specified key.

Parameters: ke - The key to identify this integer v - The Vector to write to the stream

writeHashtable public void writeHashtable (int key, java.util .Hashtable h) write a java. lang. Hashtable to the stream under the specified key.

Parameters: key - The key to identify this integer h - The Hashtable to write to the stream

writeObject public void writeObject (int key, j ava . lang . Obj ect obj ect) write a Streamable Object to the stream under the specified key.

Parameters: ey - The key to identify this integer object - The Object to write to the stream

objectToString public static java. lang. String objectToString (java. lang.Object obj)

Staic method for encoding an objec to a String

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSJR | METHOD DETAIL: FIELD | CONST. | METHOD

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | EIELD I C.OUSJR | METHOD DETAIL: EIELD | CONSTR I METHOD.

purevis.core

Class MasterLogger j va . lang.Ob ect

I

+- -purevis . core . MasterLogger

public class MasterLogger extends java. lang. Object

Base class for handling logging in the PureVis system.

Components which call MasterLogger will need to save the Statelnfo when VisRunner calls setStatelnfo.

Sample Call

MasterLogger. getMasterLogger ( [serverid] , [appid] , [groupid] , [userid] , his .getUniquelDO , , "your me or

MasterLogger.getMasterLogge (Statelnfo, this .getUniquelD () , [severity] , "your message here") ;

Constructor Summary

MasterLogge ( )

Method Summary static MasterLogger getMas erLggger ( )

Static method to get the global master logger from. void log (int serverlD, int appID, int groupID, int userlD, int itemlD, int severity, java. lang. String msg)

The basic logging call. void log (Statelnfo info, int itemlD, int severity, j ava . lang . String msg)

The basic logging call. static void setMas erLogger (MasterLogger logger)

Static method to set the global master logger from.

Methods inherited from class java. lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

LOG_SEVERE public static int LOG_SEVERE

An fatal error which will probably halt the system.

LOG_ERROR public static int LOG__ERROR

An error which may cause more severe problems.

LOG_WARNING public static int LOG WARNING A warning on a potential problem

LOG_SYSTEM public static int LOG_SYSTEM

A system state message for system monitoring.

LOG_CODE_DEBUG public static int LOG_CODE_DEBUG

A temporary code debugging message.

LOG_USER public static int LOG_USER

Any severity higher than LOG_USER is a user severity.

Constructor Detail

MasterLogger public MasterLogge ()

Method Detail

setMasterLogger public static void setMas erLogger (MasterLogger logger)

Static method to set the global master logger from. The global master logger is created by the VisRunner.

getMasterLogger public static MasterLogger getMasterLogge () Static method to get the global master logger from. The global master logger is created by the VisRunner.

log public void log (int serverlD, int appID, int groupID, int userlD, int itemlD, int severity, java. lang. String msg)

The basic logging call. Parameters: serveπD - The unique id for the server, should come from Statelnfo appiD - The unique application id, should come from Statelnfo. grou iD - The unique group id, should come from Statelnfo. itemiD - The unique id which is initialized by PureVis and can be changed by the user. PVComponent. getUniquelDO. seve ity - The severity level of the log message msg - A string message which will be printed to the log.

log public void log (Statelnfo info, int itemlD, t severity, j ava . lang . String sg)

The basic logging call. Parameters: in o - Statelnfo which will be passed to PVComponent.setStateInfo(). itemiD - The unique id which is initialized by PureVis and can be changed by the user. PVComponent.getUniqueID(). severity - The severity level of the log message msg - A string message which will be printed to the log.

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSJR | METHOD DETAIL: FIELD | CONSTR | METHOD Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

purevis.core

Interface PVComponent

public interface PVComponent

Information common to each and every component

1. The PVName

2. Statelnfo

3. Uniqueld

Method Summary j ava . lang . String getPVName ( )

Return the PVName for this component. getUniqueld () returns the Uniqueld for this component. void setPVName ( ava. lang. String strName)

Set the PVName for this component. setStatelnfo (Statelnfo info)

Set's the system Statelnfo for the component. void setunicrαel (int d)

Used to set the Uniqueld for this component

Method Detail

getPVName public java. lang. String getPVName 0

Return the PVName for this component. PVName is entered by the wirer during development. setPVName public void setPVName (java. lang. String strName)

Set the PVName for this component. PVName is entered by the wirer during development.

setStatelnfo public void setStatelnfo (Statelnfo info)

Set's the system Statelnfo for the component. This is used mostly for logging purposes.

getUniqueld public int getUniqueldO returns the Uniqueld for this component. The unique id is something used for logging purposes. The number can be entered by the wirer and is used in logging to identify components from one another in log messages.

setUniqueld public void setunigueld (int id)

Used to set the Uniqueld for this component

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO_F_RAI_!ES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR |^" ETHOD DETAIL: FIELD | COj_STR | METHOD

purevis.core

Class Statelnfo j ava . lang . Obj ect

I

+- -purevis . core . Statelnfo

public class Statelnfo extends java. lang. Object

Information about the current state of VisRunner or server on which this component is running. This information can be used on compontents to pass to the logging process which gives further information about the state of the system than would be possible without it.

Constructor Summary

Statelnfo ( )

Method Summary getApplicationlD ( )

The application id is the unique identifier for the application under which this component was launched. getGroμpID O

The groupID is a unique identifier for the group of components which were loaded from the same file/location as this component getServerlD ( )

The serverlD is the unique identifier for the server on which the component is running int getUserlD Q

The userlD is the current user which is running this group of files. void s_etApplical:ionI_D (int id)

The application id is the unique identifier for the application under which this component was launched. setGroupID (int id)

The groupID is a unique identifier for the group of components which were loaded from the same file/location as this component void setServer D (int id)

The serverlD is the unique identifier for the server on which the component is running setUserlD ( int id)

The userlD is the current user which is running this group of files.

Methods inherited from class java. lang. Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

Statelnfo public Statelnfo 0

Method Detail setServerlD public void setServerID(int id)

The serverlD is the unique identifier for the server on which the component is running

getServerlD public int getServerlD 0

The serverlD is the unique identifier for the server on which the component is running

setApplicationID public void setApplicationID (int id)

The application id is the unique identifier for the application under which this component was launched. getApplicationID public int getApplicationID ( )

The application id is the unique identifier for the application under which this component was launched.

setGroupID public void setGroupID (int id)

The groupID is a unique identifier for the group of components which were loaded from the same file/location as this component

getGroupID public int getGroupID 0

The groupID is a unique identifier for the group of components which were loaded from the same file/location as this component

set UserlD public void setUserlD dnt id)^'

The userlD is the current user which is running this group of files. This id will change during the lifetime of a component as many user share the same sets of server side components.

getUserlD public int getUserlD()

The userlD is the current user which is running this group of files. This id will change during the lifetime of a component as many user share the same sets of server side components. Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD 1 CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

purevis.core

Interface Streamable

All Known Implementing Classes:

CommandTarget

public interface Streamable

Interface used by components and objects to save and reload their current state information. Used to stream componenents to disk, network or some other type of stream.

Method Detail

encode public void encode (EncodeStream es)

The encode process will call this when the component needs to save it's data to the encode stream. Parameters: es - The EncodeStream to encode the object to

Sample Usage: es .writelnt (1, uniqueld) ; es .writeString (2 , aString) ; es .writeVector (3 , aVector) ; es. riteHashtable (4, aHashtable) ; es. writeObjec (5, aTarget) ;

decodeltem public void decodelte (DecodeS ream ds, int id, int key)

The decode process will call this when the component needs to read it's data from the decode stream, decodeltem will be called for each item that was encoded into the EncodeStream.

Parameters: ds - The DecodeStream to use for decoding items. id - Each unique encoded object is given an id by the encoder. That object will only be encoded once, later encodings will only make reference to the earlier encoding. This is used by decodeObject methond in the DecodeStream. ke - Each item you encode is given a unique integer key.

Sample Usage: switch (key)

{ case 1: uniqueld = ds . readlnt () ; break; case 2: aString = ds .readString () ; break; case 3 : aVector = ds .readVector () ; break; case 4: aHashtable = ds .readHashtable () ; break; case 5: aTarget = (Target) ds .readObjec (id) ; break; defaul : ds. skipltem (id) ; break,- }

getNumberOfEntries public int getNumberOfEntries O

Tell the encode process the number of entries that will be encoded before encode is called.

getVersion public int getVersion 0

The version number for this encode. This can be used to add or remove items from the encode stream. When decoding the version can be checked and action taken to appropriatly decode older versions of the component

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD I CONSTR | METHOD

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

purevis.core

Interface Target

public interface Target

Allows components to accept input events. Input events are just a calls to performCommand with a unique command key.

Method Summary void performComman (int command, j va . lang .Obj ect data)

Execute an event based on the unique command.

Method Detail

performCommand public void performCommand (int command, java. lang.Object data)

Execute an event based on the unique command. Parameters: comma d - The unique command to execute. data - Each event includes one data object.

Class Tree Deprecated Index Help

PREV CLASS NEXT CLASS FRAMES l_Q._FRAM.ES

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

Claims

WHAT IS CLAIMED IS:

1. A visual toolset for developing software applications, the toolset comprising:

a plurality of components, each component having data and logic and being represented by a component icon; a plurality of trays for organizing the component icons, each tray configured for holding a group of icons for related components; a work area for holding component icons selected from the trays wherein each component represented by a selected icon is intended for incorporation into a software application; and a connector for logically connecting components held in the work area, each connector configured to trigger activity and carry data between components; wherein after a user has completed selecting and connecting components to be incorporated into the software application, the toolkit saves the contents of the work area into an executable software application.

2. The toolset of claim 1 wherein the toolkit is also configured to save the contents of the work area into a non-executable file that includes, among other things, layout data for the selected components.

3. The toolset of claim 1 wherein the plurality of components further comprises visual components and non- isual components wherein visible components are visible to a user running the software application and non- visual components are not visible to the user when running the software application.

4. The toolset of claim 1 wherein the components held in a tray are related by functionality.

5. The toolset of claim 4 further comprising first, second and third trays, wherein the first tray is configured to hold network components, the second tray is configured to hoi visual components and the third tray is configured to hold data storage components.

6. The toolset of claim 1 wherein each of the components also includes input channels for receiving messages and accompanying data from other components and output channels for sending messages and accompanying data to other components.

7. The toolset of claim 1 wherein the executable software application comprises a serialized file which, when run, causes a list of components and their connections to be recreated and event logic to be started.

8. The toolset of claim 7 further comprising an execution engine present on the device running the software application for interpreting the list of components and their connections created by the serialized file.

9. The toolset of claim 8 wherein the serialized file is configured to run on a variety of different platforms and in a variety of different operating systems.

10. The toolset of claim 9 further comprising a plurality of execution engines, each execution engine configured to operate on a different platform and operating system.

11. The toolset of claim 1 wherein the software application can include one of: a client-server application, a multi-user groupware application; or a shared-space application.

12. The toolset of claim 1 wherein the plurality of components can be used to create new, special purpose components.

13. The toolset of claim 1 wherein the executable software application is saved in a streamable format for convenient network transport or persistent storage.

14. The toolset of claim 1 further comprising a debugger for allowing a user to step through the flow of data between components without exiting the visual toolset environment.