Kilian Hekhuis wrote:
Any response yet? I might have encountered the same or a similar issue in combination with Silk UI Tabs component and the LoadOnClick = True property. On one of those tabs I have a webblock with it's own preparation, which will only be executed if the tab is opened. This preparation returns a record which should populate the form widget; but the widget remains empty. If I switch the LoadOnClick to False, the preparation of the webblock is executed when the page loads and the form widget is populated as expected.
The workaround to assign the loaded record to the form works however.
I'm having a similar issue with a form not being refreshed after an AJAX request, but in my case there's no web block involved.
In my dashboard I want the form to be shown initially without any data (blank), ready for creating new records. In the screen preparation I have a query for Id=NullIdentifier() to (not) populate this form -- yes, I could have used a local variable with the correct entity type, but in that case I would not have come to this problem. :)
In a button-associated Action (called through AJAX) I create a new record using the data entered by the user in the (previously empty) form. After creating the record, I want to show an empty form again, ready to create a new record. In order to accomplish that, in the same Action I refresh the Id=NullIdentifier() aggregate present in the Preparation and I refresh the form (Ajax Refresh), but the data entered by the user in the form that should now be empty is still shown, despite the Id=NullIdentifier() query having been re-executed. While debugging I can see that the results of the refreshed query are correct, but the wrong values are still shown in the form input elements.
As in the previous comments, I had to re-assign the form record to the result of the query:
<EntityForm>.Record = <PreparationAggregate>.List.Current
Without this assign operation, the form didn't refresh according to the updated query results, making it look like the binding had failed in this scenario.
Hi Pedro, I think what you describe is intended behaviour. The Form, as the EditRecord, retains a local copy of the record, and you need to explicitly assign it after a refresh query.
@Rob: I'm not sure whether I ever got a reaction. I'm on holiday now, so I can't check. I'll take a look when I get back (in two weeks time)
@Rob: On 26-1-2016, I got word from OS they were passing this issue to R&D, after which it was closed. I'm not sure whether it was fixed in a release. For reference, the issue number was #1079809.
I also have the same problem, unable to track what issues has been reported and unable to followup the status of reported issue. Sometimes support case is closed without a solution! or open case without a response.
Any news about this bug being fixed? there is any work around?
Thx in advance