xsharp.eu

Hi Leonid,

OK, so (1) is fixed now, it's just that there's another problem with the debugger that also needs to be fixed.
I guess you mean that (2) still exists also in 0.6?

Hi Chris,
Yes, I checked both problems in 0.6 and the second problem still remains.

Leonid,
I have research your problem #2 and cannot find an explanation.
I will release a new build next week that fixes #1 and also has (for the VS integration) new debugger windows for publics/privates, globals, settings and workareas.

Robert

Robert,
Thank you! I'm looking forward to the new version.

Regarding issue #2, here's some more information (the log you previously pointed to to gather information): This is the moment the tab is closed. Here you can see that the function takes a long time: "XDatabase: Read File info for file" (3 minutes). Maybe more logs should be added here to understand what is taking so long inside "Read File info for file"? Or even consider the need for this function at the time of closing the tab (after all, we have already closed the tab and we don’t need anything else from it).

Leonid,
I will try to figure out what is happening in that time. I'll also add some additional logging for the next version to help in debugging this.
I doubt that the problem is in the "Read file Info", but most likely in something else that is happening but is not logged.

Robert

Robert,

robert post=26733 userid=253 wrote: I doubt that the problem is in the "Read file Info", but most likely in something else that is happening but is not logged.

I agree with you. I have a feeling that the problem is in third party code. You reported that you use Community.VisualStudio.Toolkit to integrate with VS. It was there that last time there was a problem with the functionality of highlighting identifiers:
https://github.com/X-Sharp/XSharpPublic/issues/1145

As I reported earlier, long tab closing is observed only when the "Highlight identifiers" option is enabled. And this problem also manifests itself in some way before the tab is closed: editing a very large file with each new input is getting slower. That is, in the process of editing a large file in one session, the process of typing the code gradually slows down with each new character/word typed. If you turn off the "Highlight identifiers" option, then everything described above is not observed.

Leonid,

Are you using Peek definition a lot, or are you splitting the editor window a lot?

Robert

Robert,
"Peek definition" I almost never use. I use "GoTo Definition" regularly. And I never use the split editor window at all.

In the example from which I sent you the log by email, my actions were as follows:
1. Launched VS 2022.
2. Opened the solution.
3. In the "Solution Explorer" I double-clicked on the PRG I needed. A tab with this PRG opened.
4. Edited this PRG. In this example, I didn't use "Peek definition" and didn't split the editor window.
5. Closed the tab (hung for 3 minutes).
6. Closed VS 2022.

Hi,
I mentioned earlier that the "Highlight identifiers" functionality causes problems when closing tabs after editing large PRGs. I disabled this option and have been working without it for the second week now. And I can say that the VS editor "came to life". Other issues that I hadn't previously associated with this option disappeared as well. For example, I constantly had a problem when I did a text replacement in a document (CTRL+H): in fact, the replacement took place, but the editor showed that it was continuing (as if it had hung); it was necessary to change the focus (click somewhere else with the mouse) so that the search would still report the completion of the replacement. And all that stuff. Turning off the "Highlight identifiers" option put everything in order. The problems mentioned are no longer observed.

With that said, I can confidently state that the current implementation of the "Highlight identifier" functionality has a negative impact on the VS Editor.

Robert,
The dead-hang issue described in point 1 here is already unbearable. Can I expect a new version with a fix soon?