Jul 172013
 

Hello everyone,

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.

 

Jun 172013
 

Hello everyone,

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.

Understanding Protected Mode

Adding a site to the trusted zone

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.