User Guide

Ruby Component
Ruby Limitations
Our main aim for Ruby in FlowBotics Studio was to provide a scripting mechanism that binds tightly into our graphical programming
environment and allows you to do things that were not possible before or were very difficult previously using graphical programming
techniques.
Ruby integration brings a massive number of benefits but this is Ruby within FlowBotics Studio and as such there are some limitations when
compared with using pure Ruby via text files and the command line.
The vast majority of people will be able to use Ruby in FlowBotics Studio without encountering any of these limitations. However, for some
advanced users of Ruby there are certain aspects of the implementation in FlowBotics Studio that you should be aware of as they may
restrict some of the things you might want to do. This section covers those limitations.
Single Interpreter
The first thing to note is that there is a single interpreter for each instance of FlowBotics Studio. This means that if you open two schematics
within the same exe they will share the same interpreter – the same Ruby airspace so to speak.
Individual Ruby components are always completely self contained so any instance variables you use there relate only to the Ruby
component in which they are declared. However, if you declare global variables or classes in one schematic then they will be visible in the
'Ruby space' of the other schematic.
Most of the time this will not be an issue. It's just worth knowing in case you happen to run into any behaviours that may arise from this.
Standard Ruby Libraries
The standard installation of Ruby comes with a number of libraries. We don't currently supply all of these with FlowBotics Studio. In fact we
only supply one, win32 (used for connecting to external DLLs).
The main reason for this is that if you choose to export to a standalone exe, because the libraries are external to Ruby you would need to
distribute the library files alongside your export.
We hope to be able to provide an automatic way of dealing with this in the future so that you don't need to think about dependencies on
libraries – instead it would all be dealt with in the export process. This would allow us to be able to offer the full set of standard libraries.
Declaration Order
Because all Ruby components share the same interpreter you can declare globally available classes and variables in one Ruby component
and they will be available in all others. This is a very useful feature. However, you need to make sure that when you re-load your schematic,
the declarations occur before they are needed. To do this the Ruby component that contains the declarations must be interpreted before any
Ruby components that use those declared items.
When FlowBotics Studio loads a schematic it starts with the top-level schematic and then loads each component on that schematic in the
order they were added. When it reaches a module it will load the schematic for that module and the process continues in the same way.
The earlier a Ruby component appears in this ordering the earlier it will be interpreted. So let's say that you have some class declarations in
a Ruby component that are only used in a particular module. If you ensure that the Ruby component is the first component in the schematic
for the module then all will be fine.
Unless you really plan ahead and add the Ruby component for your declarations first it's likely that you'll find yourself in a situation where
you need to change the order of components so that it's the first one. You can do this by selecting all the other components, cutting them and
pasting them back in.
170 of 212