Uwe Raabe

At least that most likely rules out any parsing problem. That would also match the fact that I was not able to see that problem on my system. Note that the current beta catches the error from the call stack you posted first and writes some error message to CodeSite instead.

The question is: doesn't it save all files or ist it just that something stays as modified so that the Save All icon is still active?

Please try again.

Make a password protected zip file and send it to uwe <at>uweraabe <dot> de. Send the password inside a personal message in this forum.

That is irrelevant. The error appears when MMX parses the code - it doesn't try to compile it. As long as it is syntactically correct that will do. I just need the unit, not the project. If you can strip the unit while keeping the exception thrown that would even be better. That could be a bit tedious as there are more than 600 as constructs in the code where probably the majority would have to be enclosed in try-except blocks conditionally raising an exception or not. I prefer spending my time in finding the real cause instead.

The problem I have is that as long I cannot reproduce it here, I simply cannot find out the root cause. The current beta catches the error at the source position from the first call stack. The new call stack throws an error at a different position. My guess is that the error is not related to the position it is shown, but has its root somewhere before. If the sources are the same as with the first call stack, then the error shown there should have been logged. As you have no log the relevant code either succeeded or has not been executed. The code in CustomPascalExplorers shown in the call stack makes the assumption that some instance is of some type and a simple AS should work. If that is not the case then something has been going seriously wrong. I need to find out what that is and how to detect and prevent it and that requires a reproducible test case which I don't have in the moment. If something has garbled the internal data structure then just masking these exceptions will do more harm than good. It would help a lot if you could provide the unit triggering that error.

I somehow expected that. After catching the first error it is most likely to stumble over the next one. The question is: Did it write something to the log file?

You may have a hard time getting this amount in these days.

You may have to provide a value in ResourceOptions.PersistentFileName to allow storing the structure and data from the last retrieved records when online. If you deploy a basic file with just the structure (best created from an online connection during development) that may fit your needs.

I have uploaded a new beta version that allows to do some logging: MMX Beta Setup There is a new entry in MMX properties MMX Debugging: Enable log to file, close IDE, install CodeSite Tools and restart IDE. Then try the same as before to trigger the exception and look in the given folder for the log file.

To be fair, it at least contains a simple question and thus seems pretty valid for this forum:

Why not using the longer descriptive name for the declaration and then add a shorter type alias later. That way everyone can choose, while the more descriptive name is used by the IDE tooling.

Same here. Unless you are able to provide a reproducible test case we will have hard time to help you.

There are also some code templates in Delphi to simplify writing these comments: summary, params, returns, remarks

As a short time workaround you can use the Trial installed from the ISO. A link for that as well as other information can be found in this blog post: Some Embarcadero Servers Are Experiencing A Hardware Outage

It's not like they did it on purpose.

I just want to emphasize that the DocWiki is not only back again, but also seems to be pretty fast and stable now.

I wish I'd know. There are other cases with a similar error, but I wasn't able to reproduce it, nor could I spot the trigger. In case you can manage to create a reproducible test case I would love to use that for finding the root cause. As long as I am not able to reproduce any code change would be a blind guess.

You might already have seen it: When you go to https://quality.embarcadero.com/ there is a notice at the top saying: So be prepared (presumably already today) for not being able to file new reports or edit/comment on existing ones. Searching and reading should be possible. While this will most certainly lead to complaints, it is definitely a good thing and long awaited change.

Actually QP ought to be a subsystem from the internal Jira. The InternalTrackingLink ist a hint for that. One of the reasons to make QP read-only is probably to allow for a final synchronize before moving the internal Jira to the new one.

It may be delayed, but not necessarily. The development systems should be functional even without these servers.

Can you try with Light as the initial theme?

AFAIK, they plan to internally use a cloud based Jira (you won't get any other) while getting rid of the public QP instance in favor of limited public access to the new one. At least that has been discussed for quite a while, because the synchronization between the internal and external instance was error prone and often lagging behind. So the statement that the current system seems to work fine probably didn't take into account the whole picture. On the other hand, as I mentioned in my initial post, such criticism was somehow expected. The same as my expectations are mostly based on speculation, so are others. Personally I just feel better expecting an improvement. So for me it stays to be a good thing until it turns out otherwise.

Are you talking about the Community Edition? That would be the only one I know of available to the public without an ISO.

The blog post recently got an update: https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/