Weird after-popup bug for editable table contents

Weird after-popup bug for editable table contents

  

On OutSystems 10 for Web...

I must say, I've never encountered this before.

It looks as though when you are in the notify for a popup, editable tables are mysteriously one row larger:

The "From table list" is a count of the list of records in the editable table. Update, which does an Ajax update of that last container, works fine - table list is always 2.

...but if you use the popup:

...all of a sudden, the editable table has grown:

If I click Update again for a regular Ajax refresh, it's fine again:

The delete also seems to be one row behind (though I'm sure I'll see that issue elsewhere if I look) if you try to Ajax update from the delete action:

Maybe there's a good, semi-official way of... doing the Ajax Update twice or something to get past this?

-- Ritchie

Hello Ritchie

The Editable Table list has always one more line than the number of visible lines. But in general, the Length of the list is set to the number of visible lines.

For some reason that is beyond my knowledge, when you try to fetch the number of lines from inside an OnNotify of a PopUp, it returns the real number of lines. There is no workaround here, besides assuming you have to take 1 from the Numer of lines.

The same if you fetch from the UI, on a Refresh from the OnNotify. But in this case, there is a workaround

You can refresh the Editable Table before getting the number of lines in the UI. Now the number will be correct. Of course, you have to save your data and restore it... 

And saying so, I would advise against trying to figure out the number of lines in an Editable Record. At least from inside an OnNotify...

Maybe someone more used to the Editable Records can give you a better answer :)

Cheers,
Eduardo Jauch

I wonder if the editable table widget is violating some rules. I threw a breakpoint in the save row action, and the widget comes out with something I've never seen before: the list does not match the length:

I found this out because I was trying to copy out the table widget's list and maintain the edits and deletes in a local variable, but as soon as it comes back from the Ajax Refresh, it "reconciles" it to a length of 2:

Side effects from cheating with the one extra line?

It looks like I might be able to get around this by:

* In the save row, copying the widget row list to a local list using a ListClear/ListAddAll (instead of, say, an Assign, which preserves the list weirdness and breaks after the refresh) gives a proper list that does not increase in length after an Ajax refresh

* In the delete row, the row is not gone yet, so directly using ListRemove on my local copied list with the widget's List.CurrentRowNumber works

Not the workaround I was hoping for, but I'll see if it's suitable enough :)

If anyone is peeking at editable table issues, I hope they see this :)

-- Ritchie

Here's the updated solution which shows the local variable list tracking better than the widget itself.

Solution

Hey Ritchie,

Editable Table widget is a strange beast with some behaviours that just don't feel natural...

In this case, a workaround is to create an action, I called it "RefreshListLength" just to refresh your "From table list" expression and added a button (called it "RefreshList_Bt", with "display:none") to run that "RefreshListLength" action.

Now, on both the Delete action from Editable Table and the OnNotify, replace your ajax refresh with a Widget_Click from RichWidgets that references the "RefreshList_Bt" button.

I've attached your OML with these changes.

Solution

Didn't attach the OML :)


Thanks, Tiago - Widget_Click seems to be the equivalent of the "second update" I was thinking of, delaying the response until OutSystems' own internal accounting is caught up.

Interestingly, I tried out Widget_Click on the Save event, and that did not work - the first row added claims a row count of 2 :)

(Funny, Mark J was just talking to me about Widget_Click this week!)

Obrigado! Tudo bem :)

-- Ritchie

OutSystems 10.0.9 and this problem is still there, with a slight change. There is ALWAYS one empty record added to the EditableTable recordset and the length too is ALWAYS one more than was actually entered.

Here is screenshot of an EMPTY Editable table, NO records were added by the user yet. Note there is already exactly one empty record and the length is 1 (NOT ZERO).

This is followed by a screenshot where EXACTLY 1 record was entered, note the length is still 1, the one empty one always there......

This is followed by a screenshot where EXACTLY 2 records were entered, note there are 3 records, the one empty one always there and the length now 2 (ONE less than the actual recordset).


This messes up everything. I cannot check if record is empty because if it is empty it has length=1, if it has 1 record it has length 1 GRRRRRR!!!!!! (In my case the user must enter at least 1 record upon close of the parent screen)

So workaround is to check if Length=1 then check if the first record is all empty/zero fields then I assume table still empty and that one record is this dummy.

I suspect OutSystems needed this dummy empty record for the functionality of the editable table, so perhaps it cannot be done without it. Then perhaps be consistent and also when there are no rows added yet, only the dummy one present, make the length 0 and NOT 1, that will then be consistent. Then further I use the Length and a counter to traverse the table records instead of ForEach.

OK OutSystems, I reckon time to fix this.........????