Skip to main content

Looking for a suggestion to make a screen part refresh after selecting a new row.

The situation:

In green I have a selection method which all reference after each other, so starting at 1 I end up at 4 selecting a certain record.

Because of the way screentypes work, I cannot have the pink part at 5 be a reference of green 4 or else it would only be the width of green 4.

So to be able to make the pink screen part use the whole width, I have a hidden view that hold the reference to the green part (1) and the pink part (5) as a tab container with a detail tab.


I am abusing the context procedure to store the selected record of green 4 in table, so I can make the reference to pink 5 using that hidden view. All rainbows so far!

Now the tricky part. The pink 5 does not refresh, as there is no reference from green 4 to trigger this.

Anybody got an idea what can be done to achieve this refresh? Thanks in advance.

Hi Mark,

Very exotic way of modelling I must say😄 This seems quite complex, but I feel the selection of 4 determines the records of 5. Sadly the process action Go to Row cannot start a process flow, or it would to too perfect for your situation. How about a double click task?

The double click task could be activated whenever you double click a particular record. That in turn could influence the recordset of 5. Would that be a solution you and your users could work with?

@Mark Jongeling Hi Mark,

thanks for your suggestion. The double click would be an option to consider. The downside of this is that the info on screen 5 would only change on that action with the risk of a user looking at the wrong data as he/she did not double click yet or thought they did.

I’ll keep the idea in mind. Leaving the question open a little longer in case another option comes along.

We've had a similar problem but we weren't able to fix it. Abusing the context procedure is a very nice hacky way to achieve this, thanks for sharing. You could consider using an auto refresh procedure to check for the changes made by your context procedure to refresh nr. 5.

@J. de Lange The auto refresh might be something to have a look at. When reading about the use, it does seem to require an interval to trigger, so it might not be that viable as the user very likely clicks quicker on a new row than the auto refresh would pass by.

When I have time in a couple of weeks, I’ll check it out. Thank you for the suggestion!

Not entirely the way we wanted the screen to work, but this is the solution we finally went with.

As users need to get to a selected row in green 4 and we want to be certain they are looking at the correct result in pink 5, we went with a task that a user needs to use to make a selection. This stores the relevant data in a table and that record is used to show the correct data in the pink screens.

The view green 4 has been made that only the one selected record is shown and if people want to change their selection, a clear task needs to be called to remove that data from the record and show the possible options again. This results in the pink screen being empty when none is “selected”.

To make the refresh happen, a process flow was needed to activate the correct tab and call the refresh action.

Terms & ConditionsCookie settings