Debug closes original source #2314
Comments
|
The debugger would open source in a new debug editor and it closes the debug editor after the debug session is terminated. Please describe what the editor behavior is like in your own debug session:
If possible, please use some screen captures to show the editor area before debug and during debug. |
|
Hi @mkwan01 , I'm not sure whether this is what the OP sees, but for me, the behavior is as follows:
|
|
That is exactly what is happening @heymchri Thanks for clarifying. |
|
Thanks @heymchri for the hint. There is no VScode API to tell whether an open editor is a debug editor. We are currently using the short name on a tab label to determine if this name matches an existing debug source file. If the short name matches, then it is considered as a debug editor and we will close it. This solution is not as good. It can match other existing editors with the same base name. We can change the algorithm to match for the full name. Can you compare the labels on the two editors (one for debug and the other is opened before debug), and let me know whether the full labels are the same? You can hover on an editor tab to see its label. If their labels are still the same, then we will still have problem in the new solution. |
|
hi @mkwan01 I also tried this for a source member: So in both cases, there is a difference in the full label name. |
|
Thanks @heymchri for the information. Can you also capture the Debug Adapter Protocol log from the Debug Console for the first debug session (where the source is located under /home/HEYMCHR)? I want to make sure that my new solution would work for this case. Thanks. |
|
Hi @mkwan01 - not sure what you mean with the Debug Adapter Protocol log - is this what you're looking for? |
|
@heymchri Yes, that is the one I am looking for. Specifically, I want to check the loadedSource event, which looks like the following: Please attach your loadedSource event for the first debug session where the debug source is located under /home/HEYMCHR. |
|
@mkwan01 The loadedSource event shows: Full log: |
|
Thanks @heymchri . The DAP log confirms that the name field of the loadedSource event contains the full path of the source file in the IFS debug scenario. |
|
Just a thought - this appears to have been a recently introduced problem - so how did it work before? |
|
The old behaviour is to close the currently active editor, even if the active editor is not for the current debug session. This solution also has its own set of problems. We will try to fix the problem by matching the full path of the source tab against the loaded debug source files. |
|
The fix will be available in the coming debug client update (around early December). |
|
This problem was fixed in debug client v2.0.2. The new debug client requires a debug service update via the following host PTFs: Please note that you need to regenerate the SSL certificate after updating the debug service. |
|
Hi @mkwan01 Unfortunately the latest version 2.0.2 of the debug client still closes the original source... 😢 My case:
When checking the editor windows, they both have the same label: the full IFS path |
|
@chrjorgensen This is a limitation, if the debug editor and the source file editor has the same label. The fix addressed the cases where the two labels are different. In these cases, only the debug editor is closed after the debug session is terminated. As we have no way to tell whether an editor is a debug editor from VSCode API, we can only use the editor label matching solution, which is better than the original solution, but it still has its own limitations. |
|
@mkwan01 @chrjorgensen I tested this as well, and for both stream files and source members this now works OK for me - the original editor tab stays open after the debug editor tab closes. |
|
@heymchri Source members work here also - because the label for the member is I noticed your two labels for streamfiles in your comment above also are different, where your opened streamfile has a label starting with @mkwan01 You've probably already investigated this, but is it possible to only close one editor window instead of all having the same label? Or open the editor window with a unique label like e.g. |
|
@chrjorgensen my source is in git so I have my stream files locally. ~/dev/ in my case equals /Users//dev/ |
When running the debugger the original source is closed when the debugger terminates. This didn't used to happen and forces me to reopen the source after each debug run.
Active extensions
Remote system
Enabled features
Shell env
Variants
{ "american": "#@$", "local": "#@$" }Errors
[ { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPD4090: Printer device PRT01 not found. Output queue changed to QPRINT in library QGPL.\nRNS9308: Compilation stopped. Severity 40 errors found in program.\nCPC0904: Data area RETURNCODE created in library QTEMP.\nRNS9310: Compilation failed. Program DIEXAMP1 not created in library PARTNER400.", "cwd": "/home/PARIS" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPD4090: Printer device PRT01 not found. Output queue changed to QPRINT in library QGPL.\nRNS9308: Compilation stopped. Severity 20 errors found in program.\nCPC0904: Data area RETURNCODE created in library QTEMP.\nRNS9310: Compilation failed. Program DIEXAMP1 not created in library PARTNER400.", "cwd": "/home/PARIS" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPD4090: Printer device PRT01 not found. Output queue changed to QPRINT in library QGPL.\nRNS9308: Compilation stopped. Severity 30 errors found in program.\nCPC0904: Data area RETURNCODE created in library QTEMP.\nRNS9310: Compilation failed. Program DIEXAMP1 not created in library PARTNER400.", "cwd": "/home/PARIS" } ]The text was updated successfully, but these errors were encountered: