A developer familiar with ADO or other database ActiveX library will
easily notice the similarities between the Variables object and the
recordsets in these libraries. However, the Variables object is dual. It
can work with its own internal cache or bind to an external recordset-like
object provided by the external data access facilities in use. Once
configured and connected it is navigated much like a recordset. Lets put
some lines of code to illustrate this (see also the installed
examples).
Lets connect to MS Access database:
var vars =
objVisiLabel.Variables; // Get the object in a variable to minimize
the typing work
vars.CacheMode = false; // Change to external data source mode
vars.DSType = 0; // We will use ADO to manage the external data
source.
vars.ConnectString = "Provider=Microsoft.Jet.OLEDB.4.0; Data
Source=G:\\databases\\clothing.mdb;";
vars.Query = "SELECT * FROM T";
// Assuming that the database is there and the table exists
// we can fetch the fields returned and thus auto-configure the object
with the appropriate fields.
if (vars.FetchFields()) {
// We have the fields
// there we can end for now and may be leave the user define
links with the elements
// on the label.
} else {
// error something is wrong with the database or the query
}
If everything is correct at this point we have a configured
Variables object: It "knows" how to connect to the DB, what
a query to execute, and we gave it a chance to try it and learn what
fields are returned. During this test the object deleted any exiting
fields previously configured in it (if there were any) and created
automatically fields that match the fields returned by the query. They
are named after the names returned by the query and they have types
set to the closest COM type match of the DB field type.
//
Lets put a HTML button that resets the DB connection
<INPUT TYPE="BUTTON" VALUE="Reset" onClick="vars.Reset()">
// Of course we can use any other user interface approach for the same
purpose.
If we want to give the user means to move to another
record we can do this like this:
<INPUT TYPE="BUTTON"
VALUE="Reset" onClick="vars.MoveNext();vars.UpdateLabel();">
The
set back of the above code is that it does not deal with errors. If we
did this early enough to ensure that the user will be able to click
the buttons in Ignore errors mode:
vars.IgnoreErrors = true;
It will be ok because the errors will just be ignored and
nothing strange for an end-user will happen - no error messages.
However we may want to be precise and show the error to him/her. Then
we can use code like this:
vars.IgnoreErrors =
false;
try {
vars.MoveNext();
vars.UpdateLabel(false);
} catch (e) {
// Deal with the error. For example simply show the error:
alert(e.description);
}
Still in many cases the end users are not to be bothered with such
errors. Then we can go for the middle:
vars.IgnoreErrors
= true;
if (vars.MoveNext()) {
vars.UpdateLabel(true);
} else {
// Show simple error.
alert("No more records");
}
We do not check the details about the error and just check
if the operation was successful. Is this enough? In most cases yes -
if the database connection has been successful and we just navigate
through the recordset there is not much else that may happen unless
there is a general problem with the machine (such as low memory,
disrupted network connections etc.). If that is so a MoveNext failure
most likely will be the last thing on our mind. So why bother
the end-user with messages he/she may not understand.
Note that the
above examples are in Javascript with assumption that we use a DHTML
page. As we mentioned using external data source in WEB page is not
too convenient. For instance the page in which we write this is
probably generated on the WEB server by ASP, JSP, PHP or other script,
while the database in the code lines above is accessed on the local
machine. Of course with a different connection string we can access a
database server on the network, but typically the data needed for the
label is known for the server side of the application (for the ASP,
JSP, PHP script for instance). So the above sample lines are not the
best way for an WEB application. In fact they illustrate what a stand
alone application would do - such as a desktop application written in
VB, C++, Delphi or other language. The remarks illustrated by
Javascript are also true for such application and just the syntactical
constructions will differ. For WEB applications it is more convenient
to use the cache mode and send the data to the label from the WEB
server and not leave the control fetch it on its own.
So, lets
now illustrate the typical techniques for an WEB application. Note
that we will be very brief here, a fully working code can be found in
the installed examples.
In HTML pages Active Label is embedded like
this:
<object classid="clsid:09A02CEE-410B-47BA-A837-E62C9C8D70BF"
id="VisiLabel" width="100%" height="400">
... Series of <PARAM> tags
</object>
The PARAM elements between the OBJECT tags
specify the settings and the contents of the label (see the reference
in Data, file and command formats).
Alternatively the label can be initialized by using DATA attribute in
the opening OBJECT tag or using a SRC parameter. No matter which
method is used you can fill the contents of the internal cache of the
ActiveX during the initialization.
................
