You might want to have a quick look at the PowerPoint presentation before proceeding.
There are several ready-made client applications which you can immediately use to access the test server you made in the first part of the workshop tutorial. You have already used one, namely, the "Instant Client" which lets you browse the control system and access and test not only your server but any server in the control system. The Instant Client will only let you access one server and one property at a time, however. You can of course call up multiple instances of the Instant Client using "Options" -> "New Client".
You should probably become familiar with the bevy of available tine command line tools. At the command line (on Windows, open up a "DOS" box) type 'tget'. You should get a resonse message something like:
So typing something like 'tget "/WORKSHOP/MYSERVER/Device 0" Amplitude' should return the multi-channel array of temperatures (beginning with Device 0). Note that since there's a blank in the device name (unless you changed it!), you have to enclose the <device name> string in quotes, otherwise 'tget' will try to interpret the string following the blank as the property!
Analogous to 'tget' is 'tmonitor' which starts a data link to the device and property in question and doesn't stop until you type 'quit' or 'cntl-C'. You might want to have a look at some of the other available tools in the command line section.
Okay, let's do some "nuts and bolts". That is, let's examine some of the fundemental client API calls, as well as transfer modes.
To begin with, we'll write a simple non-GUI client application which accesses your test server and writes out reponses as a text dump, either at the console, or if you are a Visual Basic enthusiast, in a text box (okay, that's a GUI).
If you want to ignore the "nuts and bolts" then putting together configurable client applications, which 'read' the desired behavior from an application database and then connect control points to displayers, might be the way to go. With these kinds of applications, you don't program at all. On the other hand, you end up with a primitive application which can display data and change settings, but otherwise is extremely difficult if not impossible to massage or filter the data in anyway prior to display. It is also difficult if not impossible to react on some event in one displayer (say a click in a chart) and take decisive action in another displayer (e.g. use the timestamp obtained in the click to retrieve a history snapshot to display somewhere else). To do these sorts of things, you need to program (or you'll be jumping through some rather exotic hoops).
TINE lends itself to primitive application builders such as DOOCS jDDD or JoiMint as you might expect, but we'll be looking at rich clients in what follows. And to do that we'll have to have a look at the basic tine client-side API.
Java programmers will want to look here.
C programmers will want to look here.
VB.NET programmers will want to look here.
VB 6 (legacy) programmers will want to look here.
LabView programmers will want to look here.
Exercises: