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

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:

Does this do the trick?

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.

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
)

as
begin

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

end

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.

Pseudo:

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
)
as
begin

    insert into continuous_editing_always_top
    (
        order_no,
        customer_order,
        scan_value
    )
    values
    (
        @order_no,
        @customer_order,
        @scan_value
    )

end

The result will look as following:

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.

Does this status update from under review to open (21 days ago) mean that this will be in the next version? As around 20 people in our warehouse would love to see this added to our barcode scanning menu!