Step 1 | Step 2 | Step 3 | Step 4 |
Step 3
Clothing - Static HTML with PARAM elements. The techniques we need.
Data record | Printing |
---|---|
This example exorcizes the techniques we will need in the next step when we will add the sever side code.
First we have the label configured to use data and to work with the internal cache - see the MISC command (CMD3) where the second parameter "use data source" is set to non-zero (enables data usage) and also the DATASOURCE command (CMD19) where the first parameter is non-zero (work with the internal cache).
Second we put a few (4 to be exact) cache entries into the internal cache. In this sample they are put manually as static parameters - see CMD27-CMD30. When we put the server side code it will generate such entries.
Third we put navigation buttons to allow the user see how the the label looks with the different data records. This is not needed for the printing and can be omitted, but it is a convenience for the end-users and may help also the tracking of errors in the database. Notice the code in the onClick attributes of the navigation buttons. It performs recordset-like actions, but you will notice one difference - when you change the record the data is not automatically transferred to the label. Thus we need to call Variables.UpdateLabel to do that. There is a reason - you may need to inspect and even change the data with a Javascript without showing the records on the label.
And finally the printing. The print invocation looks like this: VisiLabel.Print(0,100). The first parameter is 0 which means do not use the default printer - let the user choose the printer and may be change some of its settings. The second parameter is a limit for the number of labels that can be printed. Why is it needed? Because the paper (and not only the paper) costs money - a mistake in the application may send data for thousands of labels. This may effectively empty the printer so this number can be used to set an emergency limit that will prevent this from happening. Thus you can set there a sensible limit - it is almost always possible to determine what will be the maximum number of labels printed in a single print operation. A good example for such a mistake is a mistake in the server side code that omits a condition in the database query. Then if your database is big you may generate a really big number of data entries. Such mistakes are most often caught in time, but a little caution is never a bad thing. This is especially useful if you decide to use the default printer and start the printing automatically when the page loads.
Now we are prepared to make the next step - change this page to an ASP page. To see the next step in action you will need to put this example on a WEB server or install ALP.