-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial regression start/end ignored in 2.0, honored in 2.1 #820
Comments
Assigning @bberenz just so he can take a look and help decide how to move forward. My instinct is to do nothing and close as |
We could probably support the old behavior when receiving a legacy message by wiping out boundEnd here, but as you pointed out providing both an 'end' and 'width' is already unsupported in both versions so I'm not sure if there's a benefit to adding that in? |
Right, I think our window to write an upgrade routine was missed when #442 was merged. Now we're 18 months in with 2.1 and it seems like directing developers to correct the data is the highest level of compatibility (vs. correcting the regression but potentially breaking user space again), despite the fact that we've already broken user-space. Perhaps a warning? (Edit: Done in #829) |
Adding a note, that to honor This isn't intuitive, but reverting that decision can have other side-effects. |
Quoting:
Workaround:
width
for scales that honorstart/end
, removestart/end
for scales that honorwidth
).The issue is unobvious at first, but it's a change in behavior when both
start/end
ANDwidth
are provided. Note, providing both is discouraged, but the old 2.0 API spelled out the behavior, quoting:The documentation: @v2.0.7
tray/js/qz-tray.js
Lines 978 to 979 in 28aaefd
This documentation (and apparently the behavior) was removed in 2.1.
QZ Tray 2.0.12 behavior:
width
is honored overstart/end
QZ Tray 2.1.3 behavior:
start/end
are honored overwidth
To reproduce, try this code against qz-tray.js version 2.0.12, and then again against qz-tray.js version 2.1.3:
start/end
.start/end
is honored, the weight is returned from the scale.start/end
.width
is honored, the weight isn't returned untilW\r
is sent twice, and then the weight is returned as a 16-character string, e.g.�000.45 000.45
.I believe the Avery Weigh-Tronix prefers
width
, hence the regression in behavior.This is a pretty specific regression which is introduced by incorrectly providing conflicting parameters, I'm not sure if it's worth writing an upgrade routine for since the upgrade routine could actually cause regressions for other people.
The text was updated successfully, but these errors were encountered: