on 09-28-2016 10:32 AM
Hi All
I have Agentry application, ScreenSet, Screen and Button (With Label - "Add Quantity").
When Button is bind one Action it works as exptected.
It is pressed and execute the Action.
But when Button is bind the other Action, it automatically becomes unavailable for pressing.
How Action affects the state of the button.
My Action have Eanble Rule = Always Enable
If the rule is enable and the button is grayed out, sounds like a target issue. For Edit Transactions you need to target the current transaction. If you are adding a Subaction, the transaction needs to be set to a "Add" and the action needs to target the parent object.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Stephen.
Thank you for answer.
I have Edit Transaction - MeanObjChangeCountNum that change one field in the MeanObj.
For Edit Transactions you need to target the current transaction.
I don't see Target property in the "Edit Transaction" General Settings.
Not sure that I understand what is "current transaction".
I have action with Transaction Step
If you are adding a Subaction, the transaction needs to be set to a "Add" and the action needs to target the parent object.
I need to have Edit Transaction (not Add Transaction ) because I change value in the Object.
Konstantin,
I see your action is pointing to "Current Screen:>Current Object" Is this the object you are tried to change?
Also, is it a MeanObj?
If both are yes, then on your transaction step, you shouldn't need to set a target object. This is because it will default to the object of the action, which is current set to the "MeanObj" current object.
The point of the Target Object is if you have an action updating one transaction, then you within the same action, you need to target and update a different object.
Konstantin,
Buttons can become disabled when the target object tied to the button does not exist at runtime, or if a required object in the button's action does not exist at runtime. Agentry tries to qualify all the action steps tied to the button action before allowing you to press it. If it determines that something is wrong/missing at runtime, the button will remain disabled. For instance, you may have a sub-action in your button action that targets: Whatever collection -> First Object. Agentry will look at that collection when deciding if the button should be enabled. If there are no rows in that collection, the button will remain disabled, even if another sub-action in that action would have created a row in that collection before it was needed by the step that is failing to meet the target requirement. How do you get around this problem? Add an execute rule to sub-actions that may not have their target requirement met until the action runs. If your execute rule returns false, Agentry will ignore that sub-action step when determining if a button should be enabled for pressing. In the example case, add an execute rule that checks for the existence of one row:
TYPE
Whatever collection -> First object
Sometimes debugging these enable/disable target problems can be difficult. The best way to do this is to copy the suspected bad action and use the copy temporarily, removing or modifying steps until the problem area is found. Then make corrections to the original action.
Jason Latko - Senior Product Developer at SAP
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Konstantin,
That is a good way to look at it. It stops the client from crashing because you tried to point to a null pointer. To answer your other question, when do you need a target on a transaction action step? Only when the target is different from the object that was passed in to the action. If you pass a Whatever object into an action with a transaction step that runs an edit transaction against a Whatever object, then you don't need to set the target on the transaction step. Agentry will automatically use the Whatever object that you passed in to the action.
Jason Latko - Senior Product Developer at SAP
Jason
It stops the client from crashing because you tried to point to a null pointer.
You treat it as a positive or negative act?
I treat it as a negative act. If the button would be available then crashing means a detial information about Target which caused it. So developer can quickly understand the reason.
Otherwise he must to perform an indefinite number of activities to understand the reason why the button is not available for pressing.
Konstantin,
I agree that debugging can be difficult and frustrating at times. It gets much easier with experience. The thinking behind that design was to isolate the end user from crashes and cryptic error messages in the field. The runtime client was not designed a debugging tool. It was meant to be light weight and have the smallest footprint possible on the device. This was especially true when Windows PPC clients were the primary OS in the field, and the size of the executable was severely limited. This isn't likely to change going forward. Another way to debug such problems is to use the Test Environment in Eclipse and turn on logging for your action. The log will then show you the cause/source of an action evaluation being terminated.
Jason Latko - Senior Product Developer at SAP
User | Count |
---|---|
86 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.