ZPL Code Viewer Widget - Renders ZPL (Zebra Printer ) Code as an image in your application

Developer
1

Hi All,

I wanted to start to share some of the widgets that we are building internally for the library to get some feedback from you as early developers.

This one is a ZPL widget that renders ZPL code into an image in your app.

image
image1286Ă—642 99.9 KB

It has one prop read only which take the ZPL code as an input.
image

customWidget-ZPL Widget.json (994 Bytes)

Please try it out and let me know if you have any feedback.

2 Likes
2

Well done Eddy! Very usefull. You give me the idea to create Label widgets that would allow Apps Builders to access ready to use ZPL templates build base on inputs (Article, batch number, EAN, …) and generate a correct ZPL code and an image. "A small step for apps builder, a big one for logistics :slight_smile:

1 Like
3

This is a very useful widget and have employed it in one of our apps.

I am encountering a very intermittent problem and wondering if anyone has experienced the same issue. I have an on step enter trigger that sets some values to build out the zpl and stores that in a variable. That variable is mapped to the custom widget. While it is hard to reproduce, there are times that the custom widget will load but the preview is not displaying.

Any thoughts on how this might happen? Is there a race condition where the widget loads after the on step trigger executes? It is intermittent so I haven’t found a way to replicate it consistently.

4

Hey @kirons,

I have seen similar behavior in the past (In my case I saw it when passing an aggregation to a custom widget). I struggled to reproduce this reliably enough to report a bug for it. The suspicion in that case is the widget runs its logic before the aggregation is calculated, so that was driving incorrect behavior.

Now that you are seeing it too, I will bring this up with the developers and understand if there isn’t something we can do to make this bahavior more reliable. Let me know if you find cases where it always fails and we will use that to resolve, otherwise I will do what I can to reproduce on my end.

Pete

5

Hi Pete, is there any update on this particular issue? I still see intermittent issues with custom widgets loading correctly. For example, on entering a step, I populate a variable that is used to populate data in a custom widget. Most of the time things work as expected, but there are times when no data is populated in the custom widget. Maybe the variable is getting populated after the custom widget loads? I can probably demonstrate if it would be helpful. In one app, I added an event that gets fired to try and reload my variable if null is passed to the custom widget. Just wanted to check and see if this is something still being investigated. Thanks in advance.

6

Hey @kirons -

Sorry about the delay on this. Took a fair bit of investigation and conversation with the engineering side to address this one the right way. Unfortunately this is something that is more on the widget builder in most cases, and just a best practice we need to better document.

Underlying root cause-
The load order is inconsistent, when the CW loads before the variable (we see this more with aggregations) so the prop is incorrect.

Correct resolution-
All widget props should be responsive to changes. There is no deterministic way to predict when the variable/aggregation will load on the app side, so we cant wait for that to happen before loading the custom widget. If your aggregation fails to load, we can’t just not load the custom widget. This is breaking the underlying concept of reactive JS frameworks.

What this looks like in practice, is each prop should have a callback function for when they change. An example of how to do this is in the Knowledge Base article on custom widgets (Custom Widgets Overview | Tulip Knowledge Base - Support for Building Operations Apps).

//Do something anytime a prop value changes

getValue('My Prop', (internalVariable) => {
    doSomething(internalVariable);
});

When “My Prop” changes or loads, the doSomething function will be called. I end up with an update function in most of my custom widget that is called by this getValue that just gets the value of each prop, and updates my custom widget.

getValue('Prop 1', () => {
    update();
});
getValue('Prop 2', () => {
    update();
});
getValue('Prop 3', () => {
    update();
});

function update(){
   $("#Prop1").html(getValue("Prop 1"));
   $("#Prop2").html(getValue("Prop 2"));
   $("#Prop3").html(getValue("Prop 3"));
}

If you share your custom widget here (or in a DM, if you’re more comfortable with that) we can look at it and help implement this.

Does this make more sense? Definitely getting into the weeds of why Tulip was created, to remove the need to understand the intricacies of app building.

Pete