The JavaScript library is the same as the one posted in the DLS Windows release so the information in the following posts apply to the Mac version of the SDK. Keep in mind that the Web Service is built into this version.

Thanks again for everyone’s patience. We were not able to do a Beta on the Mac version but it contains all the feedback that we got from the Windows Beta. If there are any issues, please either post on the blog or send an email to sdkreply at newellco dot com. We’ll be monitoring both looking for issues and will try to respond to issues as quickly as possible. Keep in mind the more information that you include in your post/email, the better we will be able to help you.

It should be noted that the JavaScript Samples that are in older posts on the blog have not been updated to incorporate the web service correctly.

UPDATE

We’ve had some reports from our users that a reboot may be required for the DYMO Web Service to get properly configured. We are looking into this further. The way you know you are in a state that requires a reboot is as follows:

Click on the DYMO icon in the upper right on the top menu bar

Select Diagnose

If a dialog pops up and it complains about no ssl assigned to the port, you should reboot.

If you see a dialog that says “DYMO Label Web Service is running on port XXX”, then there could be a different issue.

We also know that you are interested in the Mac version. We have had a lot of issues getting the design to work on Mac OSX, we have hit a major milestone this week and we now have a release candidate for DLS 8.5.3 for the Mac. If everything passes, we should be able to release it within a work week.

As a note to all our patient customers, we really appreciate you and your patience. This has been a more difficult release than we had thought but it is finally happening. All we have now is the imminent MacOSX release. Thank you!

Update: Added link to new Javascript library version and added links to older posts for references

We apologize for the length of the delay in this release but we ran into a number of unforeseen issues trying to fix a couple of the bigger issues that were brought to our attention. The two issues that we are addressing in this release are problems with HTTPS and Network Printer discovery.

Requirements

Network Printers

This was a big issue. A service running on windows will not see Network/shared printers for a user and there are Microsoft bugs that prevent seeing these printers when the service is run as the current user. With that in mind, we had to re-implement the way the service is run. It is now a service that starts when the user logs in. This Service will appear in a user’s application tray and can be configured from there. This will allow the SDK to see any Network/Shared Printers that the user has installed.

HTTPS

Our JavaScript library now connects to the web service via HTTPS. We have to install a self-signed certificate to allow this to happen. After installation finishes, we will ask the user if they want to open up the default browser to accept the certificate. Once the certificate is accepted then all HTTPS traffic should work as normal. You can install the certificate on other browsers by going to “https://localhost:/DYMO/DLS/Printing/Check”. This is important for the Firefox browser.

New Tray application

The new tray tool has several options:

Start/Stop the Service

Configure: Which will let you specifically configure a port within the approved range.

Diagnose: This will confirm that the service is running and identify the port.

Notes

The KB2954953 patch no longers needs to be applied for the service to work

We’ve seen some issues where the service needs to run with elevated permissions to see the printers. We are working on this issue.

We’ve seen some crashes when the service starts or at the end of the install. We are investigating but you should be able to start the service from the C:\Program Files (x86)\DYMO\DLS Web Service\DYMO.DLS.Printing.Host.exe

The Mac version is being tested right now and we hope to have a version released soon.

We appreciate your patience! We are working on this as hard as we can and understand your frustrations with delays. We want to insure that we release a quality product that can meet your demands. Your feedback is valuable to us!

A new version of our JavaScript library is now available. This release addresses compatibility issues with IE11. If your web application is compatible with IE11, we strongly recommend that you upgrade to the new version.

I wanted to talk a little bit today about the DYMO SDKs and compatibility with Windows 8. I’ll start with a quick answer: DYMO SDKs only work with Windows 8 desktop style applications. They do not work with Metro/Modern/RT style applications. Let’s dig a little deeper into why our SDKs do not work in Metro style applications and I will also describe a workaround for printing DYMO labels within a Metro application.

Metro Applications and COM

All of our SDKs use core DYMO assemblies that are installed with DYMO Label Software (DLS). For our older DYMO Label SDK, you add a reference to the DYMO COM objects directly in your application. For our “native” .NET DYMO Label Framework, we’ve created a wrapper assembly that calls our core DYMO assemblies through COM. Either way, COM is a necessary component for our SDKs to work.

Windows 8 Metro/Modern style applications operate under a different set of rules than desktop applications. One important rule being Metro applications are not allowed to access the registry. What does this mean for the DYMO SDKs? As discussed earlier, all Windows DYMO SDKs require COM to function and without registry access the loading of a COM object will fail. This means that, unfortunately, printing a label using the DYMO SDKs in a Metro application is not possible at this time. There is a workaround which requires a bit of work, but I will describe the basic process to get you started.

Workaround

After installing DLS, any time a new DYMO printer is connected to your machine it registers as a standard Windows printer. This means that you can print to your DYMO printer from any application just like you would any other printer. For instance, you could type some text in a Microsoft Word document and print it to your DYMO printer. They key to getting it to print correctly on your label is to make sure the document size you are using in Word matches the label type you have in your DYMO printer.

Following the principles described above, you could create a printable document in your application, place anything you want on this document (text, images, etc.), and print this document to your DYMO printer. The creation of the document and anything on the document is entirely your application’s responsibility since you would not be using our SDKs. What your printable document is depends on what environment you are working in. One example would be an XPS document if writing a .NET WPF application. A great example for creating and printing a document within a Metro application can be found on Diederik Krols blog. Following Diederik’s tutorial and making sure that your document size matches your label size, printing to a DYMO printer from within a Metro application should be fairly straightforward, albeit not as easy as using a native SDK.

Conclusion

Over the past several months, we have received many questions regarding DYMO SDKs and Windows 8 support. We have taken note of this and are currently researching ways to improve our SDKs and provide support for as many platforms as possible. For the time being, we hope that the workaround described above will provide those of you writing Metro applications with a viable method of integrating DYMO printers into your applications.

Today I wanted to talk a little bit about a common problem a lot of our SDK developers run into involving Internet Explorer’s Protected Mode. Protected Mode was introduced in IE 7 alongside Windows Vista and was designed to prevent malicious code from being executed in an IE process. Protected mode essentially forces the IE process to run with very restricted privileges, preventing any unwanted executables or code from being run. Any operation from loading an ActiveX control to writing to the registry could potentially be blocked by Protected Mode.

So, what does all this mean to a DYMO SDK developer? A lot of our developers load our SDK in their web applications by using ActiveX controls. As mentioned earlier, if IE is running in Protected Mode and a web application attempts to load an ActiveX control, this operation will be blocked. Luckily, Microsoft has provided a way to securely allow web apps to load ActiveX controls: Trusted Sites.

Any site that is marked as “trusted” will have more privileges than one that does not. To allow a site to load ActiveX controls, users must specifically add a site to the trusted zone. This ensures that the user is in full control of what is allowed to run in their browser. If you are using ActiveX controls and your users are having troubles running your DYMO SDK application, your first step should be to ensure your site has been added to the trusted zone. Below are a couple of links to information about Internet Explorer’s Protected Mode and also a walk through on how to add a site to the trusted zone.

Labelwriter.com is currently down. If you are linking to the JavaScript SDK file that is hosted on Labelwriter.com your web application will not work at the moment. As a best practice in the future, we recommend that you do not link to the JavaScript file that is hosted on our servers but download a copy and host on your own servers. This will prevent a couple of issues:

Any outages on our end will not affect your application

Any updates that are made to the latest JavaScript file will not break your application

While Labelwriter.com is down, you can download the latest version of the JavaScript file from here.

We apologize for the inconvenience and hope to have Labelwriter.com up and running again soon.

Update:

The Labelwriter.com server is now up and running. The old JavaScript file location is accessible again.

We would like to get some feedback about what printers all of our SDK developers are using. Answer in the poll below and let us know which printer/printers you are using in your DYMO SDK applications. Thanks!

As promised, this is the second post in the FAQ series. Today, we will be getting a bit more technical and diving into some questions regarding SDK code. Let’s get started!

1. I am trying to create a label with several objects but this seems difficult to do using the SDK APIs. I feel like I am creating my label the wrong way. How should I be creating my label using the SDK?

Although it is possible to layout a label entirely using our APIs, we recommend that you first create your label using DLS and then load this label with our API. For most SDK applications this approach should work well as it will reduce the amount of code for creating the label as well as allow you to edit the data on the label based on any user inputs. For instance, let’s say your were making an application that would create name badges for a conference your company was hosting. You could create a label in DLS with two text fields: one for name and one for company. Then, as attendees arrived at your conference registration table, you could simply type in the name and company of the attendee and your application would update the data on the label using our APIs and print out the name badge. See the code samples below to learn how to load the label and update the label data using both the older SDK and newer Framework. For the purpose of these examples, assume your label was named “NameBadge.label” and your name and company text objects were named “NameTxt” and “CompanyTxt”, respectively.

2. Every time I print to my Twin Turbo the label prints from the left tray. How can I print to the right tray?

Changing to the right (or second) tray is relatively simple in both the SDK and the Framework. However, it may be difficult to find this setting without knowing where to look. In the SDK, you simply specify a tray number (an integer) to indicate which tray to print to. You will use the Print2() method instead of Print(). In the Framework, there is an enum you use in conjunction with the LabelWriterPrintParams class. See the examples below.

DYMO SDK

DYMO Label Framework

_dymoAddin.Print2(1, false, 1);
The third parameter in the line above indicates
the tray number to use.

To create a continuous label, you must use the DYMO Label Framework. The older DYMO SDK does not support continuous labels. The layout mechanism of a continuous label is quite different than that of a die-cut. A continuous label uses a cell layout system instead of the fixed location system of a die-cut label. For example, if you were using a die-cut label and wanted to place three text objects side-by-side-by-side, you would manually set the location (x,y coordinates) of the three objects on the label.

However, for a continuous label, you would need to add three subcells to the root cell of the label and then insert each of your text objects into one of the cells.

Continuous labels are the simplest way to create a label on the fly. Continuous labels automatically size to their content (unless otherwise specified) and provide an organized layout system. Below is some sample code illustrating how to create the label displayed above using the DYMO Label Framework and continuous labels.

4. I would like my application to interface with a DYMO scale. Is there a DYMO scales SDK?

We do not provide an SDK for DYMO scales. Our scales conform to the HID standard and can be accessed this way. The HID standard for scales is documented in section 4 of this document. Jan Axelson has a useful page on HID development with plenty of examples. Nicholas Piasecki and Mike O’Brien also provide some useful resources on HID scale development.

That wraps up this second FAQ post. Hopefully all of you developers found these posts useful and continue to use our SDK and our printers. I hope everyone enjoys the rest of this holiday season and has a happy New Year!

Hello everyone! It’s been a while since we have had a new post here on the blog (other than occasional Firefox update post). We have been busy working on many new and exciting things that we are looking forward to sharing with you in the coming year! This past year has also seen a number of new products from DYMO including:

An update to DLS to support our new printers (you can download it from here)

We thought we would wrap up the year with a post answering some of the most frequent SDK questions we receive. This will be a 2 part series with a second post coming later answering more of your FAQs. This first post will answer some of the more high level questions about getting your DYMO SDK app up and running. The second post will be a bit more technical. Without further ado, here we go!

1. I have downloaded and installed the DYMO SDK from this web page. However, I am unable to find or load the DYMO COM type library in my project. What am I doing wrong?

In fact, you really haven’t done anything wrong. There has just been a bit of miscommunication. The DYMO SDK installer (which can be found here) only installs samples, no binaries. To get the DYMO binaries, all you need to do is download and install the latest version of DLS (which can always be found here). Once DLS is installed, you should be able to find the type libraries as described in this post.

2. Is there a difference between the DYMO SDK and the DYMO Label Framework?

Yes. The DYMO SDK is our older API that is built using COM. You add references to our COM type libraries in your project and you’re off. The DYMO Label Framework is our newer API that we encourage all developers to use. The DYMO Label Framework is “native” to .NET, being written mostly in C#. You add references to our binaries in your project just as you would any 3rd party .NET library. The DYMO Label Framework also provides a greater feature set than the older DYMO SDK, which leads us to our next question.

3. I have downloaded and installed DLS and added a reference to the DYMO COM type library in my project. However, I cannot print to my tape printer using the SDK. What is going on?

The older DYMO SDK does not support printing to tape printers (i.e. the LabelManager series). It only supports printing to die-cut printers (the LabelWriter series). In order to print to a tape printer, you will have to switch to the newer DYMO Label Framework which supports both tape and die-cut printers. In fact, there are several other advantages to switching to the newer DYMO Label Framework. See the chart below.