2015 Aug 28 11:45 AM
Hello AiE Team,
I just have one simple question to the eclipse debugger options, will you be able to add possibility to set break-points in eclipse but run GUI debugger instead of eclipse one? Eclipse debugger still is to slow if you compare it to GUI one. Also the navigation to the previous steps is not present (or I haven't found it yet).. and I could put here some more points, but if we would mix both solutions so setting breakpoins in eclipse and run debugger of GUI then it would be perfect. Maybe you could do it also using GUI host so new tab in eclipse would be added, but this is not necessary.
Cheers
Łuaksz
2015 Aug 28 1:58 PM
Hi Lukasz,
one question: What do you mean with 'Navigating to previous steps' ?
Regards,
Thomas.
2015 Aug 28 2:03 PM
Thomas,
when you are in Standard screen of debugger you can see ABAP & Screen stack where you can navigate to the callers of current step. You can then view the variables content and in which line function/method was called.
2015 Sep 01 11:01 AM
Hi Lukasz,
this is actually availabe in Eclipse debugger (though it's buggy in my opinion):
you can click on any item in the call stack and you can see the variables there by double-clicking them:
Note the small "white arrow" in source code line 125. That indicates where you acutally are and note the variable I have selected on the right-hand side.
With some bigger call stacks it happened once in a while that this doesn't work properly. I could see the variables and the "white arrow" just for some higher levels (e.g. 3 levels). All higher items (4+) had no "white arrow" and I couldn't see any variables. A double-click had no effect. I can constantly reproduce this issue for some programs. Is this a known bug Thomas?
If you don't have these options in your debugger this could be due to Netweaver Version. As far as I know many things have changed in the later releases especially for the eclipse debugger (watchpoints, editing table lines etc.)
Best regards
Tobias
2015 Sep 01 11:38 AM
Thanks Tobias, this I haven't seen so far. In my debugging view I had it hidden. But still GUI debugger is much faster than eclipse one, so the option to allow run debugging in GUI but setting break-points in eclipse would be really helpfull.
2015 Sep 01 11:52 AM
Hi Lukasz,
we have completely different handling of breakpoints in eclipse compared to SAP GUI.
Therefore the break-points are bount to the IDE where they are created.
Setting of SAP GUI breakpoints in Eclipse is not feasible.
Can you explain a bit in detail what makes the eclipse debugger feel slower compared to SAP GUI.
What we know already is that we are slower in case a new editor is opened in eclipse. The behavior in GUI debugger is completely different because only the displayed source in changed in the debugger.
We can think of a similar mode in eclipse where the debugged code is not displayed in a editor but just in a debug window. But we will then loose all editor functions during debugger. Is this acceptable?
Regards,
Thomas.
2015 Sep 01 12:13 PM
Thomas,
I work with eclipse on two locations:
1) at work with SAP server in Germany
2) at home with local installation
Debugger works better at my local installation, so one thing is for sure the number of requests going in the background and poor connection. What I see is also that at each step I do in debugger then it seems like whole source code and all data in memory is refreshed. Additionally when you preview internal table then it getting much more worst, so then each step even of code like if sy-subrc eq 0 takes way to much time.
For me most important is speed of debugger, not editor functions, so I could live without them. But this is my opinion, others maybe like them much.
Regards
Łukasz
2015 Sep 01 12:25 PM
Hello Thomas,
I basically agree with Lukasz here. It's a "nice-to-have-feature" that code be changed during a debugger session. But performance is even more important. I can confirm that it slower to debug in eclipse. As Lukasz describes it feels like code is refreshed even for every "F6" click. I am currently working on a local in-house system here. Debugging in SAP GUI feels like everything reacts instant. Debugging in eclipse is much slower (try "F6").
Thomas, do you know about the callstack related bug i described in my last post? This one can be very annoying for large call stacks.
Regards
Tobias
2015 Sep 01 1:24 PM
Hi Thomas,
I agree with Łukasz, that debugging in Eclipse feels slower, especially if you are watching more variables or a table in the view for internal table. However I do lot of debugging in Eclipse anyway and use the feature of editing source code directly from GUI a lot. This is really very usefull. If others insist, please make it switchable option.
Have a nice day!
Ondrej
2015 Sep 01 1:46 PM
Hello Tobias,
I tried to reproduce the call stack issue that you described in our own systems with a simple recursive method (callstack depth 150) and in a realistic scenario (callstack depth ~30) but I couldn't observe any unwanted behaviour.
So I guess that either this issue was already fixed and you are missing some update or that there are other factors besides the call stack depth that cause this bug.
To further handle this issue it would be very much appreciated if you could create a customer incident describing this issue. At least we need information about your NetWeaver version (Release + Support Package) and the support information of your ADT (within ADT choose menu "Help"->"Collect Support Information..." and add the resulting zip file to the ticket).
Maybe we would also have to check the issue in your system if we cannot reproduce it own our side.
Thanks and best regards,
Armin
Edit: A colleague of mine mentioned that he made a fix that could be related to this issue a couple of moths ago. Maybe you could also try to update your ADT version in a first step and see if that is helpful.
Message was edited by: Armin Beil
2015 Sep 01 3:39 PM
2015 Sep 11 3:52 PM
Hello Armin,
I upgraded my ADT a while ago. I tried to reproduce this again within the last week and failed. Maybe it's already fixed. I will open an OSS message as soon as this issue occurs again.
Thanks for your help.
Best regards
Tobias