Bartender Printer not printing in BT file

I have a data directive auto printing and for some reason it’s not printing the printer that I selected in the auto print parameters… Any ideas?

This is the line that usually shows the printer selected… it’s working in live but not in Test, FYI.

%BTW% /AF=“\--------\KineticBartender\Labels\ECMPackSlipLabel.btw” /D=“” /PRN=“” /DBTEXTHEADER=3 /R=3 /P

Here’s the printer parameter filled out:

Here’s the printer set up in printer maintenance:

1 Like

IDk what is happening, I just copied the auto-print widget from the data directive that was working and pasted it into my new one and changed the printer and it started writing the printer… no idea.

Problem is, when I switch the report style because the widget I copied references a different report style, it stops working. @kve or @JasonMcD, for widgets, isn’t the code saved somewhere? I’m trying to figure out why one works and one doesn’t.

The post on dumping sources is here:

Stat at the top for the whole thing. But you might be able to just do the checkboxes.

1 Like

Thanks Jason, I can’t figure this out, the original data directive works, but this new one doesn’t write the pritner to the file… very odd.

Should be able to find the XML in Body

SELECT Body, * FROM Ice.BpDirective;
2 Likes

Ha, no help here, but to commiserate, I’ve got a label that prints fine here there and everywhere except when I call it from an EFx, then somehow it grabs the 203 DPI driver instead of the 300 DPI driver.

Which results in it shrinking, like so:

Printers! :smiling_face_with_three_hearts:

3 Likes

For me it’s the actual file that’s not printing a parameter set in the widget.

Thanks Haso, running a compare now when I set both directives up exactly the same… see if I see anything jumping out.

Utah,

Can you go into the directive and change the printer from Receiving to something else, Save it and exit, then go back in and change it back to Receiving, Save and exit?

In our label program I will occasionally get ‘old’ printer values that get exported in the drop file. It’s like I have to ‘refresh’ the directive with the printer in order to get the updated value.

Not saying that this is happening here, but it’s an easy check.

I appreciate your reply, I have changed it to and from, nothing writes to the file.

1 Like

I am going to try using classic! For creating the data directive.

1 Like

Making the data directive in classic fixed the issue. Parity, parity, parity.

4 Likes

Good to hear that you got it working Utah. Hope you don’t have this issue in July :joy:

Edit: maybe submit a case to verify it’s an open PRB.

1 Like

I got the case going, I’ll make sure it gets tied to something.

1 Like

Looks like it is a known bug I stumbled upon a Critical Problem when looking for another PRB.

1 Like

The fact is the kinetic designer for the data directive generates different code than the classic designer when configuring the auto-print widget.

2 Likes

Thanks for thinking of me

1 Like

Problem Number:
PRB0309441

Problem Description:
PrinterName is not written to Bartender output file when explicitly set in Auto-print BPM Action.

Expected Behavior:
The printer name should be provided in the Bartender output when it is explicitly set in the auto-print action of a BPM.

Additional Info:

  • Reproduced the issue with GenRcpt (and presumed to affect all Bartender labels).
  • If the BPM is configured to use the Default printer, it correctly pulls and includes the label printer set at the company level in the output.
  • This is not viable as a workaround because the company uses multiple printers/locations — labels must route to different printers based on location.
  • Issue occurs on both Cloud and On-prem.

This appears to be a regression in Kinetic (introduced after 2025.1.11), where the Auto-Print widget in BPM fails to pass/populate the explicitly selected PrinterName into the Bartender output (.bt) file header when not using the company default.


The developer told me it was marked complete 2 days, so I think it should be in the next minor patch.

2 Likes

Thanks man