Mar 222011
A small announcement. We’ve released a preliminary version of the documentation for DYMO Label Framework JavaScript library. It is available here.
Documentation for .NET classes is coming soon.
A small announcement. We’ve released a preliminary version of the documentation for DYMO Label Framework JavaScript library. It is available here.
Documentation for .NET classes is coming soon.
Why is dymo.label.framework.LabelSetBuilder() returning undefined?
ah… use new…
var labelSet = new dymo.label.framework.LabelSetBuilder();
Anyone else get an extra blank label after printing AND the print job gets stuck in the queue on a Mac OSX 10.6.6 with Dymo Label 8.3.0.1413?
Yes, when I press the feed button only one label advances.
I have this problem when printing from Javascript or directly from the Design software.
Could you please provide more information about your setup? What printer are you using, what label type are you using? what objects are on the label? maybe you can e-mail a label file itself? did you install DLS 8.3 on a clean system or upgraded from previous version? if yes, from what version?
Thanks,
Vladimir
Using a LabelWriter 400 Turbo, Standard shipping Label 2/18″ x 4″. Clean install on two different Macs with same result. Labels has an Address Object, a few text object, couple horizontal lines, a QR Barcode, and a small image.
I opened a support case that has the label attached, Ref# 110330-000000
We are writing a new product that uses the Dymo label printer. My current issue is that I don’t want the users to install the label software. Just the driver, and our software. We use your .NET SDK, so I don’t know if that secretly uses your label software components.
Anyway, the client shouldn’t be designing labels, or have the over head of that installation. Our footprint needs to be as light as possible.
Is this feasible?
We are working on a “slim” version of DLS installer which will install drivers and SDK components only, but it will not be ready for several months.
I would recommend to use DLS installer for now, you could run it silently from your installer by passing /s parameter to DLS8Setup.exe
Otherwise, the installation of needed components might be really complicated. If you have to do it that way I could sketch required steps, but this will be unsupported install, meaning DYMO tech support will not troubleshoot installation problems on your customers machines. To simplify steps, could you provide information about your application and the environment?
– what is .NET runtime version? 2.0 or 4.0?
– what SDK API do you use? Old DLS SDK API? New DYMO Label Framework? do you use javascript?
– Windows platform? XP or Vista/Win7
– 32-bit or 64-bit? or both?
– what printer type? LabelWriter? LabelMANAGER? both?
— .NET 4.0 (Would never want to back to previous versions after all the great improvements in this stack)
— The .NET label framework dll. The .NET native one, it appears. Which is great so far.
— Windows 7 for the most part. Possible Vista
— Currently both 32 and 64 bit. We compile ANY CPU in .NET, but I imagine your drivers might have to be specifically compiled.
— DYMO LabelWriter 450 Turbo. For now, it seems suitable.
Thanks,
Brian
OK, so you will need:
– install drivers. for 32-bit use this msi; for 64-bit use that msi. If you don’t want use our msi, you can grab all drivers files from DLS “Drivers” subfolders and install them manually using DPInst
– install .NET assemblies. You will need three assemblies: DYMO.Label.Framework.dll, DYMO.DLS.Runtime.dll, DYMO.Common.dll. All of them should copied into your application bin folder upon compilation. Just install them into the same folder as your application, no GAC is needed.
– you will need two more “native” COM dlls, used by the assemblies. The COM dlls are DYMOPrintingSupport.dll and DYMOBarcode.dll. Because you compiling to AnyCPU, you will need to install 32-bit or 64-bit versions of COM dlls depends on version of Windows. 32-bit versions could be found in the main DLS installation folder, 64-bit versions – in x64 subfoldfer. Install them into your application folder.
– you will have to create a manifest file for your application to avoid global registration of the COM dlls. For an example you can look at DLS8.exe.manifest. this manifest is for 32-bit version (we compile as 32-bit, due to Microsoft Jet dependency). Create two version of manifest depends on the platform and install one accordingly.
– test on a clean machine and hope it works :)
let me know if you have other questions.
Hi, I’m proving my printer from CMD in windows, because I need to print from there, but, nothing happen with that, in the print spooler shows “low evel local document” for a 1 sencond and desepear.
these are (Commands):
* echo “Hello World” > testfile
* net use “\\Computer-Name\Printer-Name”
* copy testfile “\\Computer-Name\Printer-Name”
Note:
-When I’m using in port USB002 or USB001, nothing happen
-When I’m use in port LPT1 or COM1 in the print spooler shows “low evel local document”, printing, but, it doesn’t work, can you help me please?
Please check the answer here: http://developers.dymo.com/2017/05/30/new-dls-8-released-this-fixes-security-certificate-issue-for-windows/#comment-84754
Wondering if documentation is available for a recent release? The link provided in the first message in this thread points to documentation that is almost 7 years old.
Hi Rod,
Our SDK interface has not changed since the documentation was created. It is current and up to date.
Ron
I’m in agreement with several others on here who have suggested that the SDK docs be clearly linked to from the main SDK page – I had to find the link to them by searching the forum for this 2011 post. This only took minutes but so would including the “latest sdk reference docs” as a sticky post.
The existence of a js sdk was also something not immediately obvious to me when I first checked out the product here: http://www.dymo.com/en-US/online-support/online-support-sdk. The closest it comes to mentioning in-browser support on that page is the note about a Safari plugin (which does not inspire much confidence for cross-browser hopefuls). You folks might sell a few more units if this js support was called out more clearly in the product pages (with the dev docs clearly linked to), as it’s a differentiator.
Looking forward to digging into the sdk – thank you!