Nicely worded Doug. _____
From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Wednesday, May 27, 2009 2:26 PM To: arslist@ARSLIST.ORG Subject: Re: Need to make an error message more friendly. ** Nyall, The key here is that you are trying to trap a specific instance where this generic error message can come up and provide a message that you control to give better indication about this specific situation. The various suggestions about changing menu styles and such help control what can be entered, but do not allow you to specifically address the issue. Also, there seems to be a constraint about adding anything or doing any checking on the remote form. So, all the options here are adding things to the source form only. The only way to accomplish what you want with a special error message for the specific case you have is to do your own validation or trapping of the problem and displaying your own message. So, here are some options: Option 1 -- Easy, quick and dirty however is inflexible This works ONLY IF you know that there is a bad value -- say 2008A -- that is causing the problem. Simply add an active link that fires BEFORE the active link that does the push to the other form that fires on the same conditions that has a run if 'field' = "2008A" and an action that says to display an error message and you can say that value 2008A is not allowed. You can be as specific as you want with the message. NOTE: This is easy but it is inflexible since you need to know the exact value that is wrong and need to keep up if there are other values that can be wrong. This is an option only if the menu is essentially static even though it is a lookup. Option 2 -- A bit more work, much more robust and flexible than Option 1 but still requires keeping definitions in sync Add (or use an available existing) temp field. It doesn't matter what the field is since you are really not going to be using it, you are just going to do a NULL test on it. Add two active links that run BEFORE the active link that does the push to the other form that fire on the same conditions #1 if the field in question has a value (no need to test if it is NULL), perform a set fields that has a qualifier that is the same as the qualifier for the menu that is on the other form with the following added on AND 'field on target form' = $field on current form$ This does the same search for a subset of records to display AND says to see if there is one that is the value I am supplying. Assign the field value you are looking up to the temp field you have arranged for with the option for what to do if there are no matches set to "Assign a NULL value" #2 runs at a higher execution order than #1 has a run if 'temp field' = $NULL$ and an action that is an error message that says exactly what you want to say. This adapts to any value and changing menus. However, it is dependent on the qualification. So, if the menu definition on the other form changes, you will have to change the active link set fields qualifier in #1 to adapt. Option 3 -- requires AR System 7.1 or later, is the most complete solution, but is also a bit more work Redo your logic to move the push fields to a filter that fires on "Service". Then, change the active link that does the push to perform a Service action against your form (probably passing a code in some field to tell it that this is the operation you are performing in case there are multiple service conditions) and have the operation performed. At this point you have the IDENTICAL operation you have now but instead of the active link performing the operation, it calls an operation on the current form and a filter performs the operation. But, the error is the same and you still want it fixed. HOWEVER, this is where you can then use the second new feature of 7.1 -- error handling (available only for filters which is why I had to get you to move the operation to filters first). Define an error handler on the filter that does a push. If an error occurs during the push, the error handler will get called. The error handler would have a run if qualification of $ERRORNUMBER$ = 306 AND $ERRORMESSAGE$ LIKE "%536870913%" (note that the actual keywords are different strings, but you can look up the exact wording) This would be true ONLY for error 306 on the field of interest. Success, the error handler would not be called Any other error and the error handler would run the ELSE branch (which is empty) and return the error If it matches however, the error 306 would be suppressed completely. You would then have an action on your error handler filter that would be an error message of the text that you wanted to have. Essentially, you have trapped the error you don't want in this case and substituted your error. You could alternatively have kept running or whatever you wanted but you wanted an alternate error. This last one is the most work, but it works no matter what the values are today or change to, no matter what the menu in question is. I hope this shows the variety of types of things you can do to handle situations like the one you are describing and that there are often different options -- with different implementation costs -- that you can choose from depending on what you want to accomplish and how far you need to go with the solution. I hope this set of ideas gives you something to think about and that helps with your situation, Doug Mueller _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of MCCAVITT Nyall Sent: Wednesday, May 27, 2009 12:52 PM To: arslist@ARSLIST.ORG Subject: Re: Need to make an error message more friendly. Hi Joe, Tried that but as the Pattern attribute is set to $MENU$ then this gives the same error. What I am trying to do is catch the error and displayed a more user-friendly error message. Thanks. Nyall _____________________________________________ Nyall McCavitt CND/COE/VI/SQ (BE.25) Tel: +33 (0)1 69 88 73 02 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: mercredi 27 mai 2009 20:58 To: arslist@ARSLIST.ORG Subject: Re: Need to make an error message more friendly. ** You do not have to change the Menu type.. just the field property of the field that the menu is attached to. You will find this option in the first default tab of the field property in the mid upper right corner of the field property dialog.. Joe _____ From: MCCAVITT Nyall <nyall.mccav...@eurocontrol.int> To: arslist@ARSLIST.ORG Sent: Wednesday, May 27, 2009 1:29:20 PM Subject: Re: Need to make an error message more friendly. Hi Joe, Unfortunately I cannot change the menu type as it is based on a search of another form. Thanks. Nyall -----Original Message----- From: Action Request System discussion list(ARSList) on behalf of Joe DeSouza Sent: Wed 27/05/2009 17:41 To: arslist@ARSLIST.ORG Subject: Re: Need to make an error message more friendly. Make the character menu's display type as drop list and you will never have to deal with that error.. Joe ________________________________ From: MCCAVITT Nyall <nyall.mccav...@eurocontrol.int> To: arslist@ARSLIST.ORG Sent: Wednesday, May 27, 2009 10:38:25 AM Subject: Need to make an error message more friendly. ** Hi, Environment: ARS V7.1 (Solaris) running with a remote Oracle 10g database. One of my users has complained that the standard error message from Remedy for a certain condition is not very user-friendly and I cannot see an easy way of making the message more friendly. Any suggestions would be welcome. The simplified situation is this: One one form, called A1, for this example, I have a field called 'Menu' which has a menu attached to it. The values in this menu are 2008A, 2008B, 2008C and 2008D. There is a button on this field which when clicked on copies the data from form A1 to form A2 by means of an Active Link. This second form also has a field called 'Menu' with an attached menu, but in the case the menu values are 2008B, 2008C, 2008D i.e. the value 2008A is missing from the menu on the form A2. When an entry is being created on form A1 with a value of 2008A in the 'Menu' field and then the button is clicked on the user receives the following error message: ARERR [306] Value does not fall within the limits specified for the field : (Pattern - $MENU$) : 536870913 The error message itself is clear enough as to why the error has occurred but the problem is that is uses the Database ID to identify the field where the problem is. This is OK for an Administrator but the user would like to have the name of the field i.e. the database label value. Personally I would like to have the database label value, the form name and the data value that has caused this error. Thanks in advance. Nyall _____________________________________________________________ Nyall McCavitt CND/COE/VI/SQ (BE.25) Tel: +33 (0)1 69 88 73 02 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
