Clear a table with Javascript in a web form

posted on July 12, 2023 • Show version history

I see a lot of posts on here regarding clearing all the values within a table, but I just want to clear the table entirely (rows and all) by clicking the X button for all rows.

My thought was to use the following code to do this

   $('.cf-table-delete').each(function(){
      
      console.log('Found Delete Button with Index: ' +   $(this).closest("tr").index());
      
      $(this).trigger('click');
      
    });

However the array returns some really strange out of bound indexes and very few of the actual delete buttons shown on screen.

Here is the console output from trying to delete a table with 3 rows for example

We found 3 with an index of 0, 1 out of bounds with an index of -1, and 2 with an index of 1. Out of all 6 of these, only 1 was actually on the form, leaving 2 rows not deleted. No matter how many rows I have, it always only finds 1 of the actual delete buttons, leaving behind all other rows.

In this example I am starting with 3 rows, I run the function once and it deletes only 1 row, then I run it again and it deletes another row. If I keep running the function, all the rows will eventually be deleted one at a time.

In further testing I found it works as expected as long as the table has no read-only fields for some reason, but I want to clear all tables of all rows, regardless of what is in them. I simply want to click every row delete button found on the form.

0 0

replied on July 13, 2023

I think you're getting weird values on the indexes because there are actually two items in each row with the cf-table-delete class, so it's trying to run on each row twice. You get a 0 because it's the first row. Then you get a -1 because that row was deleted on the last iteration, so the item it's trying to address in the current iteration no longer exists. Then it repeats because what was previously index 1 has now moved to index 0, so then you see 0 and -1 again. Maybe sometimes it processes quickly enough that it manages to get to index 2 before it updates the prior delete.

I tried it out, running through the table rows instead of the delete class. I also did it in reverse (from last row to first row) and I was able to get it to report all indexes and delete all rows.

    $($('.cf-table-block tbody tr').get().reverse()).each(function(){
      console.log('Found Table Row with Index: ' +   $(this).index());
      $(this).find('.cf-table-delete').trigger('click');
    });

When I did it in the other order, from beginning to end, it delete delete every row, but just reported the index of 0 on each one, because as it iterated through each one, it was always the first row in the table, with the prior ones having already been deleted.

    $('.cf-table-block tbody tr').each(function(){
      console.log('Found Table Row with Index: ' +   $(this).index());
      $(this).find('.cf-table-delete').trigger('click');
    });

Note that in both cases it did delete every row - unfortunately, it also deleted the ones that were the minimum number of rows for the table. I believe that is because it's processing the iteration before the form can update to remove the delete buttons.

0 0

View 3 previous replies

replied on July 13, 2023

Ah I see, there is other objects that share the same class name. I was wondering why it always found twice as many as I see on the form.

Does not seem to be causing any problems by initiating clicks on the extra objects though.

Then it repeats because what was previously index 1 has now moved to index 0

This explains the crazy indexing, I see now.

I tried your code and the indexing is more clear, but I do have the same problem. It only clicks one of the rows' delete button, leaving the rest of the rows behind. This happens if I have any read-only field in the table.

So the code is still not effective at clearing the tables, unless the table has only editable fields. Yet as a user I can click the X buttons with my mouse it works. Furthermore, my code can click all the X buttons, but it must do so one at a time by restarting the function as many times as there are rows, the for each loop does not work.

0 0

replied on July 13, 2023

I can't replicate the behavior with the rows containing fields that have readonly values not being deleted.

Are the fields being marked as readonly via the "Previous data and new rows with lookup data will be read-only, but user-added rows will be editable" setting or some other way?

0 0

replied on July 13, 2023

No other special configurations besides checking the read-only box. Here I am reproducing the problem from scratch, using the exact code

$(document).ready(function(){
  
  $('.trig input').on('change',function(){
    
   $($('.cf-table-block tbody tr').get().reverse()).each(function(){
  console.log('Found Table Row with Index: ' +   $(this).index());
  $(this).find('.cf-table-delete').trigger('click');
});
    
  });
  
});

0 0

replied on July 13, 2023

That is so weird - I duplicated the steps from your video, and it deletes every row for me.

There must be some weird difference between Cloud on On Prem (Version 11.0.2212.30987). Since I'm only 1 hotfix behind, and it's the Classic designer, I just assumed there were no differences, but I can't think of any other reason I wouldn't be able to replicate the behavior.

0 0

replied on July 13, 2023

What is extra unusual is that when I trigger it again, it successfully deletes the next row indicating that it can use all the controls. Also whether I start at the top or the bottom it successfully deletes that row. For each button it logs to the console and one thing I know about script is that if there is any unexpected errors all further code would terminate.

This leaves the only possibility that the trigger('click') method is not always hitting it's mark. It is executing, but sometimes it misses. I might try putting in a delay as while the table is trying to update with the new row count it might be blocking it. Sometimes I feel like javascript is a little too fast for interacting with interfaces.

0 0

replied on July 13, 2023

That could be it - just struggling to do the built-in updates to the table while your script is trying to run - and then just differences in processing speed between environments causing the differences between what you see and what I see.

I wish I had some better advice, but without being able to replicate the behavior, I'm kind of stumped.

0 0

Discussion

Discussion

Clear a table with Javascript in a web form

Comments 8

Follow-Ups 0

Sign in to reply to this post.