New values in table cells will not bind back

[ross_goodman]

Hi,

.

I have a table node

It is filled intially and table cells 4 and 5 are empty. Thesecells are filled from a read of a database table.

Processing occurs and in the database these fields are now filled with usable data and table is saved. Correctly.

The user hits the refresh button on the browser and the method that filled the table node originally is called once more.

This time the data for the cells 3 and 4 in the internal table are correctly filled with thevalues from the database and the bind of the internal table to the node occurs as it did in the first pass.

When the dynpro displays the contents of cells 3 and 4 are still empty even though they were filled in the internal table used in the bind statement.

WHY??

Do I need to use something other than the table bind to amend the fields in the context node table, or do I need to clear the node first and then bind the new content? If so what is a simple method to clear out completely the content of the table node?

[ross_goodman]

positioning of the bind was happening at the worong component level.

[ChrisPaine]

Hi Ross,

I'm a bit confused:

the user hits the refresh button on the browser 

As WDA is stateful - any press of the the refresh button on the browser will relaunch the application. A completely new memory space - completely new state - what happened before should be completely irrelevant.

If so what is a simple method to clear out completely the content of the table node?

the bind table method of IF_WD_CONTEXT_NODE has a parameter SET_INITIAL_ELEMENTS - which by default is ABAP_TRUE - if set this means that the entire context is replaced by the provided table. Not that this is a particularly good approach to managing context - especially if the tables are large.

[ross_goodman]

I am confused too.

I have watched the internal table fill with content in the new fields and then seen the bind method called with return code 0. But the screen shows with the table fields still empty!! They are correctly bound to the context elements, all the other fields fill just not these two particular fields.

Weird!

Ross

[ChrisPaine]

Ross,

is it a standard table UI element that is displaying the data - within you view which is a view of the same component in which you are updating the context?

[ross_goodman]

Chris,

The table is populated initially in a method of the window, data is changed in a method of a view within that window and saved there to the data base.

When the browser refresh button is pressed the method of the window (Handlestart) is called again, this reads the database table again and binds the now updated internal table to the table node.

The view is then reopened but the data in the table has not changed. The table node in the view context is identical to and mapped to the table node in the window context. As evidenced by the fact that table fills correctly the first time through.

Ross

[ChrisPaine]

When the browser refresh button is pressed the method of the window (Handlestart) is called again, this reads the database table again and binds the now updated internal table to the table node.

it would be my understanding that the method is not called again - but called for the first time in a completely new memory space.

do you do a database commit when you write those modified entries to the db?

[ross_goodman]

Yep, the changes are actually being made to a vendor invoice which is posted succesfully. The data read in the handlestart method is read from EKBE for the po history and is pulling the data from the hsitory record that now exist for that invoice. So all is well from a backend apps point of view.

I am going to try rereading the history in the view method and bind to the view context node instead of the window context. The when the view method outputs the success message for the invoice posting I might see the table updated immediately. Nothing better to do with my weekend he lied!!