Call Screen Action from another Screen Action

On our radar
Much better if we can call multiple screen action in one button's/link's destination screen action.
Created on 14 May 2014
Comments (18)
I'm pretty sure we've seen this idea before, but I can't find it right now.
Same here. It's been suggested at least once before.

Thanks, I hope Outsystems team will implement this.

Indeed, this is similar to this one and this one.
They should be merged to sume up the likes :)

The maintainability would be horror.

if you enter screenaction 1, you refresh a part
if you enter screenaction2, you refresh a part.
so, how do you tell, what part is going to be refreshed first?
what happens, then, does it trigger something else which ends up clicking an action in jquery?

or do you get simply 2 refreshes of a container, which you don;t want.
so you have to implement logic to check if it comes from screen-action1, or from a button.

In the other ideas.
create a plain action for reusablity parts.
and refresh-query is the most commonly used part, which Outsystems already implemented nicely.

so, imho, just no :)

Hi Forum Users!

I have asked myself this question recently and come up with a solution.

I, personally, believe that being able to call screen actions as if they were Private Methods gives the power of functionalising Web Block and Web Screen specific logic within the Web Block/Web Screen.

The way to do this is by using Event System (on forge). It has an action called InvokeNotifyWidget which calls the OnNotify on a Widget using the widget's RuntimeId (using reflection I think). Unlike the normal NotifyWidget, this one runs synchronously (an added bonus).

Using this feature, just add a Web Block that has nothing but a dummy call to Notify Widget (put an IF in Preparation with condition set to False that leads to NotifyWidget on its True branch). This means you can now set a Screen Action as the OnNotify in a consuming Web Block/Web Screen.
Next, set the "Name" property of this empty web block to something in the consumer (for this example "FuncTrigger") and then call InvokeNotifyWidget in your origin screen action and pass in the empty web block's id ("FuncTrigger.Id"). The OnNotify handler will then be called, effectively calling that screen action from the origin screen action.
It's too much back-and-forth to the client. It's basically doing two post-backs, one for the original call, and then a second for the REAL call. So viewstate goes to the client and back to the server twice, user sees two post backs occur, etc.

Justin James, it doesn't! At least if you're using Event System, which invokes the OnNotify via reflection (Sea Millo got it right), therefore not requiring two postbacks.
Ah, good to know!

I would like calling screen actions from screen actions to be implemented!
So strange this request has so little votes, i was sure there would be a huge topic about this when i ran into this problem.

The Event System in the forge is pratically the same then a for the Widget Click (which is a workaround that requires extra work)
Incorporating all functionality in the RefreshTable screenaction seems very dirty to me, and is also a workaround.
While i do understand the problematics, the multiple callbacks possibly being disruptive to the client, this is not in all situations the case.
They should allow it at least for those situations. (detect them, otherwise warn or block)

Also how hard is it for Outsystems to design the functionality of the screenactions mechanic so that it aggregates callbacks thus preventing back-and-forth's?
Merged this idea with 'Refresh Actions' (created on 2016-06-30 15:14:27 by Caio Santana)
It would be useful to have a way of refreshing/re-executing actions in a Screen Action context (similar to Refresh Data ).


The source of a Table Records called MyTableRecords is a list returned by an action called MyAction instead of an aggregate or adv. query directly.

Currently, if we desire to get an updated list from MyAction, in the RefreshMyTableRecords action we must call MyAction again and assign the newly returned list to the previous MyAction in the preparation.

This is messy and could be simplified with a Refresh Action feature.

Merged from 'Refresh Actions' (idea created on 2016-06-30 15:14:27 by Caio Santana), on 2016-07-01 09:07:08 by Goncalo Borrega
I see my idea has been merged to this one but I don't think they were related. I wished for a "Refresh Action" feature, and it would apply only to Actions, not Screen Actions.

Also I don't see how that could be achieved by calling Screen Actions recursively.

Sometimes I need to reuse same code inside the screen. One difference between this idea and function is that I need to reuse the elements and page context. Another is that I could transfer the flow avoiding code duplication

Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega

Can't you create a Action and reuse the same logic in multiple screens.

Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega


While not supported by OutSystems, a great forge component for achieving this is the Event System: http://www.outsystems.com/forge/component/597/Event+System/

It allows you to make event handlers and point them to screen actions. You can then trigger an event handler from another screen action, making your screen actions reusable.


Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega

We had the same problem, but solved it by reusing the same screen action and adding a parameter for the different functionality required.

It's utterly ridiculous that this can't be done, and it leads to massive duplication of code.

Someone at outsystems need to sort this out.  If someone there is blocking the addition of this basic fundamental programming concept, someone in charge there needs to move them sideways into another role.