Option to allow selected row to move out of sight after refresh

Related products: Software Factory

In a new barcode scanning screen we’re constantly adding items to a list by scanning many barcodes in a barcode view. This barcode view receives updates at every scanned item which results in an insert statement to a table via an instead of update trigger on the view. The effect is that every action with the barcode scanner results in a new item in the list. New items are added from the top of the list.

The problem is that as soon as the selected row reaches the bottom of the grid it stops going further down at consecutive scans. New items are still added but they aren’t visible without scrolling up. Because we want to minimize mouse actions during the scanning process to maintain workflow this effectively keeps new items invisible.

This issue was already described in https://community.thinkwisesoftware.com/questions-conversations-78/barcode-input-2822 where an animated gif illustrating the issue can be found as well.

The solution I would like to propose is an option in subjects to allow for a selected row to appear outside the view of the grid after a refresh. With that option enabled the selected row would effectively keep moving down in our case and new items would keep appearing at the top of the grid.

Please note that I tried a process flow to move the row selection to the top after every refresh. This is not an option here as it moves the cursor away from the form in the barcode scanning tab. Scan actions need to be possible without workflow interruption and with minimal user action in the end-product.

Hi Roland, Have you tried an alternative sorting so new items would appear at the top after an insert?

I've tested sorting descending instead of the default ascending and new items to get added at the top:

Add new rows at the top

Does this do the trick?

Updated idea statusNewNeeds feedback

HI Mark. New items are being added from the top. The issue is that the newly added record doesn't become the selected record. The selection remains on the first item which you can see move downwards in the animation while new items are added. As soon as the selected row reaches the bottom of the list it stops moving further down and new items at the top are added out of sight.

I think in your example the selection keeps moving to the new record through a process flow. That is not an option here because it takes away the focus on the form that is used to add new items. It needs to be possible to keep adding items without user interaction in the application. The input form is set to be always editable and to auto-save to allow for this behavior.

Updated idea statusNeeds feedbackUnder review

Hi Roland,

You can achieve this by ‘tricking’ the UI into thinking that the row that’s on top is the row that was just being edited. This can be done using a default that modifies the primary key to ‘predict’ the new primary key.

For example, using the following data model:

Note how order_no is the key.

I’ve configured default edit mode and auto-save for this subject and i’ve configured the default to add +1 to the order_no when the row is being edited.

This changes the primary key of the row being edited to the predicted new key.

create procedure "def_continuous_editing_always_top"
@default_mode tinyint, -- 0 = add, 1 = update
@import_mode tinyint, -- 0 = regular, 1 = import row, 3 = import
@cursor_from_col_id varchar(255), -- column that triggered the default
@cursor_to_col_id varchar(255) output, -- cursor in column after leaving the default

@order_no "order_no" output,
@customer_order "scan_value" output,
@scan_value "scan_value" output


if @default_mode = 1
select @order_no = max(order_no) + 1
from continuous_editing_always_top


After that, you can use the instead-of trigger to create a row instead of editing the existing row, completely ignoring the deleted table in the instead-of trigger.

Soon with platform version 2022.2 you’ll be able to use an update-handler, a procedure that captures the update, and perform an insert instead of the update. Completely ignoring the key of the previous row in the process.


create procedure "upd_continuous_editing_always_top"
@upd_order_no order_no, -- Key values of row to update

@order_no order_no,
@customer_order scan_value,
@scan_value scan_value

insert into continuous_editing_always_top


The result will look as following:

Scanning using default edit mode and auto-save, tracking the inserted row while editing

The first row is added via Add row, all the other rows are added via editing and saving. Note that there are no process flows involved in this process.

Hi Anne,

Thank you for your reply. I have tried to apply your solution. I gave the list update permission and then set it to auto-edit /auto-save but but it doesn’t seem to work.

I’m not sure if your method works in our situation. The instead of trigger on the view already adds a row to the list where we have the issue. But because we use only that specific view to add a record to the list (by continuously scanning barcodes) that list itself isn’t being edited in anyway and thus the default procedure doesn’t run. The only tab in the entire document being edited during barcode scanning is the “Scan” view.

OK I see now what you did. It would work by adding a form to the list and then add/edit the rows there via an insert of update trigger on the table itself. That is tricky though in our case because that same table is updated via other routes as well.

I didn’t think of adding an instead of ... trigger to a table so I will definitely keep that in mind. In this particular case we will have to wait for another solution I’m afraid.

One extra addendum: the aim here was to bring user interaction in the gui to a bare minimum. The scan view allows for that because all it ever does is updates. Even if a procedure were to become available to convert an update to an insert inside the gui it would still require adding a record to the empty list first and then edit it from then on, requiring an extra mouse click. That doesn’t seem like a big deal but our people in the warehouse it really is. They would rather keep it as is because for them every extra interaction during the scanning process is a distraction.