Method Community

I would like to use the action Retrieve Value from Table on a Text Change event of a field in a grid and then use the result in an Action Sequence tied to another field in the Grid on the SAME screen, and SAME row.

For example I would like to retrieve the Item Type upon a text change event on the field Item in a grid, then I would like to use the stored value of Item Type in a conditional action sequence tied to the text change event on Quantity.

Retrieve Value from Table only appears to allow storage of the retrieved value into either "Action Result" or "Value in Screen."

The Actions Guide, April 2010, says that  "Action Results can only be used within the same Object/Field they are created in."  This would seem to suggest that the Action Result value would NOT be available to an action sequence initiated by an event tied to another field on the same screen, in the same grid, even within the same row of the same grid.

Presumably a Shared Result could be used to pass values between action sequences in the same row or grid, but this seems a bit cumbersome, and hopefully not necessary, or there's a better way?

is my interpretation of the Action Guide correct, and is it true that an Action Result value is flushed upon completion of an Event Action Sequence such that it can only be used within the single event action sequence?

What is the best way to share results within the same grid?

James

Well, nevermind.

I think I've answered my own question, or at least confirmed the limits of Action Results.  The Show Message action will only support the use of Action Results referenced in the same action sequence.  It also does not allow direct usage of a Shared Result, so presumably the Shared Result would need to be passed into an Action Result before use in the Show Message action.

Of course now I am a bit curious as to whether Action Results are passed between event execution threads when the Call Another Action Set function is used.  Would the two sequences "share" the same variable space?  But, that's a question for another day.

For now, I am assuming that if I want a value shared between action sequences of any scope that I should use a Shared Result.

Cheers,

James

Hi James,

When using the Call Another Action Set action the action results from the called action set are not available to be used within the new Action Set. Just to clarify what is the end result you are looking for; maybe there is another way of achieving the results you are looking for?

P.S When using shared results its good practice to clear the value from the Shared Result once you pull the value into an Action Result. This can be done by assign a blank value to the Shared Result.

-Michael

 Michael,

The scenario I am trying to solve is described at the beginning of my first post.  For further clarification, I am creating some logic for updating Sales Order Line Items in the line items grid when entering a Sales Order.

After the Item is selected a series of actions retrieves values from the Items table and populates Sales Order Line Item fields.  After the QTY field is updated by the user, I want to implement some quantity dependent logic to update the line item price and potentially create another row in the Grid.  The pricing logic and additional row logic depends on several fields stored in the Items table.  Instead of going to retrieve the values I need inside each action sequence in the grid, I would rather just update a bunch of Action Values on the Text Change Event of the Item.  As long as the Item stays the same, the values for the logic to be performed in the grid row will use the same information, but potentially within several action sequences for fields within the same row.

I am assuming, for now, that the only safe way to do this is by using Shared Results, but for actions that operate within the same row of a grid, or for multiple rows in the same grid, it feels a bit cumbersome to store values in a more global name space, but I can understand why the Action Results would be limited to the action sequence as the menu driven screens for creating actions provide helpful selections of Action Results used in the Action Sequence.  This forces more advanced passing a values into the Shared Result realm which should eliminate a lot of errors in more casual coding of actions. 

But, I don't understand some things being done to clear Shared Results.  For example, On Screen Open the Sales Order screen checks to see whether the shared result resultTransactionEntity contains a value, and if TRUE it then clears the value to null, then it posts the null value to the Screen in the Customer drop down.  Why not just update resultTransactionEntity to a null value without the conditional logic?  and what if someone did want to open the Sales Order Screen with a TransactionEntity selected in a previous screen?

The intention is clear that the Sales Order screen should open with a null value for the Customer in the header, but I don't understand the circular logic of checking for non null, then making the value  null, but if the value is already null, just doing nothing.  In this case, it doesn't matter what the previous screens do about updating TransactionEntity since the value will always be cleared.  Does this mean that someone should never pass this value to the Sales Order screen, or is there a problem with the way the screen updates that is solved by this clearing code?

If I wanted to call or open the Sales Order screen from another screen, for example to look a the Sales Order detail from a scheduling screen, would this clearing code make it impossible to open the Sales Order screen to a specific record?  I guess I won't know until I try, but I'm expecting this standard code may cause a problem.

The clarification you provided regarding the Call Another Action Set action, would suggest that Action Results are very temporary and indeed only persistent through the single action sequence thread.  So, I'm thinking Shared Results should be used extensively even when sharing values amongst Action Sequences in the same grid.

Cheers,

James

 James,

jnoneiliv1:

The intention is clear that the Sales Order screen should open with a null value for the Customer in the header, but I don't understand the circular logic of checking for non null, then making the value  null, but if the value is already null, just doing nothing.  In this case, it doesn't matter what the previous screens do about updating TransactionEntity since the value will always be cleared.  Does this mean that someone should never pass this value to the Sales Order screen, or is there a problem with the way the screen updates that is solved by this clearing code?

For example let’s say you create a screen that will be used as both a popup screen and as a tab link screen and in this screen's onload event you retrieve a value from a shared result. You have a button on another screens that invokes this popup screen and assigns a value to a shared result, you click on this button and work on the popup screen now you want to go to the Tab Link version of this screen to work on something for another customer when the screen loads the shared result value still exists so it will use that value to load the tab link screen and not a blank value.

jnoneiliv1:

If I wanted to call or open the Sales Order screen from another screen, for example to look a the Sales Order detail from a scheduling screen, would this clearing code make it impossible to open the Sales Order screen to a specific record?  I guess I won't know until I try, but I'm expecting this standard code may cause a problem.

The Go To Tab Link, Go To Screen and Show Screen In Pop Up actions all allow you to set the specific RecordID of the screen that will be displayed.

-Michael

That makes sense, but the action sequence of the On Screen Load event still looks a bit clunky and just setting the value to null would be cleaner instead of using the conditional statement.  I can see why this would be necessary though.