I was creating a conditional formatting rule in an interactive table today. At some point I wanted to create a condition based on a table record field that was not displayed in the table. However I noticed that only table record fields that are displayed in the interactive table can be used. Am I missing something?
I think it would be very useful to make all table record fields available. Same remark in case we use an object list as the data source (i.e. make all object keys available).
Hi @fti ,
Thank you for the feedback! You are not missing anything, we initially implemented it so that table record fields that are displayed will only be available for conditional formatting. That being said, if you can provide more information on the use case(s), this would be beneficial for us to prioritise in the next iterations.
@canaalpaslan Sure, no problem. In my specific situation, we have a table where each record represents a failed ZPL label printing. One of the table columns contains the ZPL code that didn’t print properly.
The idea was to list these failed printing in an interactive table, allow to select a record and reprint the ZPL label.
I wanted to highlight in yellow / orange the records that didn’t contain anything in the ZPL code column since in such a situation, we have nothing to reprint. This would allow the user to see for example that failed printings reported by app X never (or not always) contain ZPL code and give us a hint that app X should be debugged.
thanks @fti could I just confirm -the ZPL code column is present on the underlying table, but you’re not showing it in the visual interactive table widget, is that the case?
Is there a reason you’re hesitant including the ZPL code column in the interactive table? Including it could visually explain why the row is highlighted - and would be easier to debug if the highlighting were off.
@OlgaStroilova I forgot to state the obvious, sorry! Indeed, the column is present in the table but not shown.
Is there a reason you’re hesitant including the ZPL code column in the interactive table? Including it could visually explain why the row is highlighted - and would be easier to debug if the highlighting were off.
That would indeed be a possibility. However:
the ZPL column itself is perfectly useless for the final user; all they care about is reprinting what they attempted to print earlier. Pieces of information such as station name, app name, step name, user name and most importantly date and time are way more interesting to them.
Displaying the ZPL column with a very small width would be a possibility but the minimal width is too large to me and takes up valuable screen space.
Since I don’t want to display it, the only possibility with the current working would be to set and display a boolean column stating if the record is valid or not. But it’s annoying to have to do this to work around a feature limitation. Plus this additional trigger would pollute all apps that implement reprinting which would generate a lot of repetition.
Using an error message instead of conditional formatting is definitely possible too but more frustrating to the user: they will be hit with an error message when clicking the row or when clicking the print button, for something they are not responsible for.
Hiding / filtering out invalid rows would work too but this could confuse and frustrate the user since they might be looking for a failed printing and not find it.
The main goal of what I’m trying to do here is to improve user experience. Here the color would give an intuitive hint to the user that something is wrong. Associated with a key under the table (like in geographical maps), this would give a solution I personally like.
@fti I have come across similar scenarios. My solution has been to include the column in the interactive table, set it to the minimum width (too large in my opinion as well), and size the widget so the column is just out of view. The one side effect is a horizontal scroll bar now present at the bottom of the table. In certain cases I have hidden that with a rectangular shape widget if I don’t want the operator to see it. That can become odd if the table ends up being multiple pages though.
+1, conditional formatting is great but often times I have “backend” fields that are irrelevant or confusing to the operator, but would like to use them to drive formatting.