Mar 212011
 

We receive a substantial number of questions regarding what to install on a client machine to be able to run an application that uses the DYMO SDK. Should it be DYMO Label software,  DYMO Label SDK, or both?

The answer is — only DYMO Label software has to be installed on a client machine to enable/support DYMO SDK functionality. The DYMO Label software installer includes all necessary binaries needed to run an SDK application. It installs printer drivers, installs libraries and services, and registers the COM components. The latest production version of DYMO Label software installer can always be found on http://www.dymo.com/en-US/online-support/dymo-user-guides. Beta versions with extended SDK functionality are available on this blog.

By contrast, the DYMO Label SDK should be installed on a developer machine only. In fact, it is not required, because the  DYMO Label SDK installer installs documentation and samples only. If you are familiar with the SDK API you might not need it at all. The latest version of the SDK installer is available on http://www.dymo.com/en-US/online-support/online-support-sdk#.

Jul 212010
 

A common question after reviewing the SDK sample applications installed with the SDK installer is “how can I set my own specific data onto the label in a format and layout of my choosing?” To do this you create a label using DLS 8. You can add label objects (Address, Text, Barcode, Image, etc.) onto the label and save it as a ‘template’ for your SDK code to use.

Scenario 1: Adding a TEXT object

First, run DLS 8 and design a label. Go to the Designer tab and edit the label. For this example, add a TEXT object by double-clicking on ‘Text’. You should now have a resizable rectangle on your label (see screen shot below).

Next, double-click on the rectangle to set the text object properties. Select the Advanced tab from the resulting dialog box. In the edit control titled ‘Reference name’ choose a unique name for this object (see screen shot below).

In this sample, I chose to name the object ‘TEXT1’. Your SDK code sets data on this object using this unique name. For instance,

Framework SDK (sample written in VB.NET)

Private Label As DYMO.Label.Framework.ILabel
Label = DYMO.Label.Framework.Framework.Open("c:Documents and SettingsAll 
UsersDocumentsDYMO LabelLabel FilesTestLabel.label")
Label.SetObjectText("TEXT1", "Testing, testing")
Label.Print("DYMO LabelWriter 450 Turbo")

DLS SDK API (sample written in C#)

myDymoAddin = new DymoAddIn();
myLabel = new DymoLabels();
if (myDymoAddin.Open(@"c:Documents and SettingsAll UsersDocumentsDYMO 
LabelLabel FilesTestLabel.label"))
{
    myLabel.SetField("TEXT1", "Testing, testing");
    myDymoAddin.StartPrintJob();
    myDymoAddin.Print(1, FALSE);
    myDymoAddin.EndPrintJob();
}

Output:

This sets the text, “Testing, testing”, onto the TEXT object which you named TEXT1 on your label. The exact same process would work for creating an ADDRESS object or a BARCODE object. You would simply refer to any other object you create by the name assigned in the Properties dialog (“TEXT1” in our example) and change the corresponding line of code which sets the data onto this object. For example, if I had added a barcode object and assinged it the name ‘MYBARCODE’, my call to set the data for this barcode object might resemble the following:

myLabel.SetField("MYBARCODE", "97820315");

See Scenario 2 (below) for greater detail about adding a barcode object.

Scenario 2: Adding a BARCODE object

If instead, you would like to add a barcode object (either in addition to the TEXT object from Scenario 1 or all by itself), again, run DLS 8 to add this object to your label file template. Go to the Designer tab and edit the label. Add a BARCODE object by double-clicking on ‘Barcode’. You now have a resizable rectangle on your label (see screen shot below).

When you size the barcode object make sure its large enough to hold the barcode for your data! Next, double-click on the rectangle to set the barcode object properties. Select the Advanced tab from the resulting dialog box. In the edit control titled ‘Reference name’ choose a unique name for this object (see screen shot below).

In this sample, I chose to name the control ‘TEST_BARCODE’. Your SDK code sets data on this object using this unique name.  Next, click on the ‘General’ tab of the properties dialog box. You are now presented with options to change the barcode symbology (see screen shot below).

The code sample below will set the barcode data to ‘9876543’ for the particular label printed.

Framework SDK (sample written in VB.NET)

Private Label As DYMO.Label.Framework.ILabel
Label = DYMO.Label.Framework.Framework.Open("c:Documents and SettingsAll 
UsersDocumentsDYMO LabelLabel FilesTestLabel.label")
Label.SetObjectText("TEST_BARCODE", "9876543")
Label.Print("DYMO LabelWriter 450 Turbo")

DLS SDK API (sample written in C#)

myDymoAddin = new DymoAddIn();
myLabel = new DymoLabels();
if (myDymoAddin.Open(@"c:Documents and SettingsAll UsersDocumentsDYMO 
LabelLabel FilesTestLabel.label"))
{
    myLabel.SetField("TEST_BARCODE", "9876543");
    myDymoAddin.StartPrintJob();
    myDymoAddin.Print(1, FALSE);
    myDymoAddin.EndPrintJob();
}

Output:

Conclusion

The format of the label (objects found within the label and their locations) printed from your SDK application can easily be edited using DLS 8. The data passed to the objects is controlled through the SDK application itself. Using the SetField() functionality you can set your desired data into the formatted label template with total control.

Jun 252010
 

If you are using the DYMO SDK from a .NET application you might run into a problem where the application throws an exception when trying to instantiate DymoAddin or DymoLabels objects. The error message is like this:

System.Runtime.InteropServices.COMException (0x80040154). Retrieving the COM class factory for component xxxx failed due to the following error: 80040154

To fix this try the following:

  • make sure you have the latest DYMO Label v.8 installed. The latest version is always available from the download section on dymo.com. currently the latest version is 8.2.2.996
  • if you are running on 64-bit Windows make sure you compile your application as 32-bit (switch TargetPlatform from default AnyCpu to x86). See this and this. If you can’t change the TargetPlatform, try the beta SDK that adds 64-bit support
  • reimport interop references to SDK libraries. Remove Interop.Dymo.dll from the project settings; add reference to “DLS7 Compatibility COM Type Library 1.0” COM library; recompile your application.
Jun 152010
 

Introduction

Developing web/browser-based applications might be a hard task. One of the difficulties is that an application is a client-server application. The application consists of the two parts, one runs on the server side inside a web server, another runs on the client side inside a web browser. If a part of the application does not communicate with the external world, e.g. it performs some computation, it might be irrelevant or not very important to understand where it’s running, the server side or the client side. But if the part is communicating with the external world, e.g. it performs printing, it is extremely important to understand the rules and requirements of such communications. To complicate life, modern IDEs and frameworks provide high-level tools and these often hide/abstract core interaction logic between the browser and the server.

The goal for this post is to analyze possible use cases/scenarios related to label printing in web applications. For each scenario the necessary software, installation location, usefulness, etc will be discussed. After reading the post, the readers should be able to answer questions like «Why does my application work great on a development machine, but stop working/crashes/does nothing after deployment?» if awaken in the middle of the night; or even better if such questions will never arise :)

Different Scenarios

In context of label printing the important questions are:

  • Where is the printer connected? On the server or on the client/user machines?
  • Where does the printing happen? On the web server or on the browser?

So, we have four different scenarios.

Printer Connection

User PC

Server

Print From

Browser

Scenario #1

Scenario #4

Web Server

Scenario #3

Scenario #2

Lets look at each scenario in detail.

Scenario #1

In this scenario the printer is connected to the client, and printing itself is done on the client/browser. It is a «typical» scenario because is it a classic web-application scenario. The server might be thousand kilometers away; the server cannot access and does not know anything about local label printers installed on users machines. Note: the printer might be not connected directly to the user machine, it might be a «shared» printer on a local network. It is still can be considered as a «local» printer, because it is available from client machine. The point here is that the printer is available from client machine but NOT available from the web server machine.

Server Requirements

There are no special requirements for the server. It might run on any operating system, use any web-server software (like Apache or IIS), etc. Very likely that it will host one or more label files (.label) to be available on the clients.

Client Requirements

Because the printer is connected to the client/user machine, the printer drivers must be installed on the client. Anything else is optional but the most convenient way to do printing is to use the DYMO Label Framework JavaScript Library. In this case DYMO Label software should be installed on the client as well.

Hints for Developers

There should not be code in any language but JavaScript that accesses printing functionality, e.g. there should not be any ASP.NET event handlers those try to create DYMO.Label.Framework or DYMO.DymoAddIn objects.

Load a label file from the server using any AJAX library.

Scenario #2

In this scenario a printer is connected to the server. Printing itself is initiated on the server side as well. Possible types of labeling applications using this scenario are:

  • Some sort of “hard copy” logging. E.g. each operation/transaction is printed on a continuous label roll, like a receipt.
  • In intranet the label printer might be the only one available on the local network, so it might be suitable to connect it on the server.

Server Requirements

Because the printer is connected to the server, printer drivers must be installed on the server. Anything else is optional. If the server is running on Windows the most convenient way to do printing is to use DYMO Label Framework. In this case DYMO Label software should be installed as well. If the server is running on Linux, then you would probably use some PDF library to generate label content then print it using the CUPS API.

Client Requirements

In this case no special/additional software is needed on the client.

Hints for Developers

Check you have no JavaScript code accessing any print related functionality.

Scenario #3

In this scenario the printer is connected locally on the user’s machine but the printing itself is initiated on the web server side. It is really usable only for intranet, because server has to have a connection to a user (all users) printer(s).

Server Requirements

The printer is not physically connected to the server, but printer drivers must be installed on the server because the server has to have a “queue” for the remote client printer. Anything else is optional. If the server is running on Windows the most convenient way to do printing is to use DYMO Label Framework. In this case DYMO Label software should be installed as well. If the server is running on Linux, then you would probably use some PDF library to generate label content then print it using CUPS API.

Client Requirements

Because printer is connected to the client, printer drivers should be installed on the client. Also, the printer itself should be “shared”, so the server can make connect to it and can send print jobs.

Hints for Developers

Check you have no JavaScript code accessing any print related functionality.

Scenario #4

In this scenario the printer is connected to the server, but the printing is initiated from the client. Again it is only usable in intranet/local network setups. Even though, it is hard to think about any good use cases here, because scenario #1 or #2 would be more applicable here. Try to avoid this setup.

Hybrid Scenarios

Of course, some installation might require hybrid scenarios. E.g. your application developed using scenario #1 and works great. Later you decided to add a label preview feature, so user can look at the label before printing. Unfortunately you have to support IE6. But the label preview feature does not in IE6 (it uses data URLs, not supported by IE6). In this case you could modify your setup and install DYMO Label Framework on the server. In this case a label preview can be easily generated on the server and be passed to the client as a regular image URL, not as a data URL.

Conclusion

Developing a web application might be a hard task but it doesn’t have to be. Try to think about your application deployment requirements in advance. Based on that, determine what scenario is the best fit for the application. After that you can think about what should be installed on the server and  client machines and what tools/libraries to use for development.

If you run into a problem, try to determine what scenario your application is using. Knowing that you will know what should be installed in the server and client machines. You might need to rewrite some code if it is placed in a wrong place, that is why it is better to think about it in advance. Don’t hesitate to contact DYMO – we are always glad to help.