Function Module MESSAGES GIVE, how to find error? - abap

I call the FM MESSAGES GIVE into Function Module MRM_SRM_INVOICE_SIMULATE, how do I find the point where the error is generated?
Thanks

Further data is needed to give you appropriate help.
But have you already tried to add a breakpoint in the MESSAGE statement?
To do this:
Open debugger via /h + action
then in menu Breakpoints -> Breakpoint at -> Breakpoint at statement [Shift+F5]
in the pop-up window grid, write MESSAGE in the first line and then click Ok.
after that, you need to replicate the error and the debugger will stop in EVERY MESSAGE statement reached in runtime.
Note: there may be many MESSAGE statements reached. Yo need to check one by one using F8 key.

Extract the message ID MSGID and message number MSGNO from the list of messages as displayed.
Then try the following:
Try to find the place where the message was triggered by static code analysis: In transaction SE91, navigate to the message given by MSGID and MSGNO, then perform a Where-Used-List for the single message. This will give you the code places where that message is issued. Put a breakpoint at each place and repeat the transaction that leads to the message. The system should stop at the point where the message is issued.
Some developers issue their messages dynamically (with variables for MSGID and MSGNO), so that the points where they are issued cannot be found by static code analysis. This is bad, but there is another way to find it. The breakpoint at statement MESSAGE as described in the answer of #cape_bsas usually stops too often, but you can put a watchpoint on the field SY-MSGNO, instructing the debugger to stop as soon as SY-MSGNO assumes the given message number.

Related

Error detection in AS400

I now basics of VBA and use it to send or get data in AS 400, but I am not so advanced to understand documentation of IBM "Host Access Class Library". I want to know how can I detect error in AS400 for now I am using script below or skip errors by self, outside of running macro.
Sub check_error()
autECLSession.autECLOIA.WaitForAppAvailable
autECLSession.autECLPS.wait 100
autECLSession.autECLPS.SendKeys "[reset]"
End Sub
When error appear I cannot use some commands like autECLOIA.WaitForInputReady, So instead I use 'wait 100' in my 'check_error' but it not always work. So how can I detect error, is there any command to do that? Or a method to handle it?
This is a massive topic that, unfortunately, depends on the application. There are so many ways that errors can be presented to the user on a 5250 display that one method can not fit all circumstances. It might be best to just ask us about your specific use case rather than all use cases.
However, let me give you a high level view of some of the ways errors can be presented.
External Message Queue
This is when the program sends a status message to the *EXT message Queue. These messages are displayed on the last line of the display. They do not appear in the job log, and are typically not used for exceptions, but they also do not end the program.
Program Message Queue
An application can define a message subfile which is a record format that displays on the screen between lines 1 and 24 on an 80x24 screen, or between lines 1 and 27 on a 132x27 screen. Where it appears, and the number of display lines it uses are defined in the display file DDS. The appearance of a message in this message subfile may be the only indication of an error, but it may contain informational messages as well. You are going to have to determine which it is by the text of the message. In conjunction with the message, a field may also be reverse imaged, or colored in a way that indicates an error, but the keyboard is not locked, and there is no audible indication that there is a problem.
DDS Error Messages
DDS error messages can be defined that lock the keyboard, reverse image the field, and display an error message. These messages can be displayed on any line as well, which is configurable in the DDS. In addition to the typical display lines, there is an addition line: 25 on a 80x24 screen, and 28 on a 132x27 screen, that is accessible to these messages.
Custom Error Messages
And sometimes an error is indicated in a completely custom way, for example by populating a text field somewhere on the screen.
The point is that you need to know your application, and how it provides user feedback, and without that knowledge, we can't help you.

Detect or Suppress Action errors during script automation

I've run into an issue with the automation of one of my Photoshop scripts where it can be completely halted by an error in a supporting action set. The script does about 99% of the work, but the remaining 1% has to be done in an action due to the work being done (the work is NOT scriptable, or at least not efficient in the least to put to script). The problem I'm running into is that, if there is an error in the layer name in the action, Photoshop pops up an alert about the issue, halting the whole process until I click the "Ok" button on said alert.
Is there any way to catch these errors (a simple try/catch on the action activation code doesn't work), or at least suppress the errors so they don't halt the entire process? Thanks in advance for any help!
Edit: Correction on the error type; it's not an "Ok" alert, it's a "Continue/Stop" alert. The message accompanying it is "The object "layer "layerName"" is not currently available". This happens if the person creating the action failed to rename the layer before performing their work on it and halts the entire automation process until I click continue or stop.
You should convert the action to a script using ActionToJavascript.jsx. After which you can then modify the script to look out for errors - such as you mentioned with the layers not being named correctly.

VB.NET: Stop smoothly in debug.assert (false) line

I always write code like this:
If SomethingIsTrue Then
'DoThis
ElseIf SomeOtherThingIsTrue Then
'DoThat
Else
Debug.Assert (False)'Doh!! I forgot to handle a certain condition
End If
In VB6 this worked great. During testing my app in the IDE, it just stopped in the Debug.Assert(False) line, and I saw where I missed something.
But VB.NET does not stop there but instead gives me a huge messagebox. This seems to be standard behaviour for Debug.Assert.
I have 2 questions, please:
1) How can I make it stop smoothly in that line instead of showing the messagebox?
2) How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
Thank you!
I would write something along this line:
if debugger.isattached=True then
debugger.break
end if
Just wrap it in a shared sub, and you can simply call it in the else statement.
The code is typed without visual studio at hand, so I hope it will work.
How can I make it stop smoothly in that line instead of showing the messagebox?
Just click Retry on the message box that pops up. From MSDN:
Clicking Retry sends you to the code in the debugger if your application is running in a debugger, or offers to open a debugger if it is not.
Clicking Ignore will, well, ignore the message.
How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
I don't mean what you mean with at runtime, since all asserts happen while your code is running, hence at runtime.
If you mean that asserts should be ignored while running your application without a debugger, just make a release build instead of a debug build. The Debug.Assert method works only in debug builds, and the point of debug builds is that they are easy to debug.
If you want nonetheless suppress the message box, see Customizing Assert behavior:
For example, you could override the TraceListener.Fail method to write to an event log instead of displaying the Assertion Failed dialog box.
To customize the output in this way, your program must contain a listener, and you must inherit from TraceListener and override its TraceListener.Fail method.

Commands not executing after a statements

I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED

Xcode debugger vs NSLog - dictionary keys and values

I'm trying to get better at using the debugger rather than just always printing my debugging message out via NSLog. This morning I thought I had a great use for it - to find how the changed values of a KVO dictionary. But when I set a breakpoint just after the appropriate code and ran with debugging on, all I saw in the debugger was this in the summary:
{(int)[$VAR count]} key/value pairs
and expanding the item never gets to any key or value.
But when I print out the "change" dictionary via NSLog I get the key and the value:
[timestamp] appName[3643:707] observeValueForKeyPath new filePath change: {
kind = 1;
new = foo;
I guess I have two questions:
Is there a way to get dictionary keys and values with the Xcode debugger?
Is there a set of rules of thumb for using the debugger vs printing log messages?
I'm (still) using Xcode 3.2.6.
Thanks!
EDIT: I realize that "foo" is not a valid file path. At this point I'm still testing sending a value around via KVO.
Set a breakpoint on the spot you want to check the value of the variable and run your application. When the breakpoint gets tripped put your mouse over the variable in the debugger. A little popup should come up, move your mouse over the arrows on the left side and another menu should popup. Click on "Print Description" and it should display something similar to a log in the console.
It is just a case by case method but a lot of it is just personal preference. You will just have to find what works for you.
If I am going to check a variable a lot at a one specific point, I will go with a log. It is usually the quickest way to see if something is working right
If I am checking how a part of the code affects a variable I will use the debugger and step through the code. It is also useful for checking the values of lots of variables in a section of code.
You can using a future set, which defenetely working in Xcode4
When u setup breakpoint, where is a option to don't stop execution of program and write to log anything what u want.
I'm not sure if it working well in Xcode 3 bcs I familiar with 4 but here is work.