Uwe Raabe

It boils down to the fact that 'THIS' just is not the upper case of 'This' on every locale. In case this is a requirement of the application, then ToUpper is not the right choice. Unfortunately ToUpperInvariant may not be either, although it will probably work for pure English text strings. For most locales upper case for ASCII characters is what one would expect, but that doesn't hold true for Turkish.

Isn't the Next Business Day dependent on the local holidays? (f.i. Bank Holidays in England)

Apparently the minds in charge think different.

Definitely!

I guess, nobody did - not even themselves.

While things are being worked on it is somewhat expected that parts are going offline from time to time. Let's take it as a sign of people being busy getting everything in place again.

Looks like a bit much. It depends on the number of design time packages. Anyway, it should not have changed unless you installed a bunch of new ones. There already exists a feature request to move that into a thread.

A new version V15.1.9 is available.

Thanks, but interfaces are not even involved in the code in question.

Wrong thread?

Those are expected in the beta reminding me to create a test case for this. The functionality (f.i. regarding the Save All) should be ok now.

@PeterPanettone Can you please try again with the latest beta 2597? If that doesn't show the problem I will provide a new release.

At least that gives me a hint where I can look at now. Stay tuned...

That is probably caused by the IDE or whatever catching the failing assertion during save of that unit. While MMX logs such an assertion it should nevertheless popup. I have uploaded a new beta catching this assertion and writing it to CodeSite. So if you reproducibly get that exception now, you should get a CodeSite message with the new beta - unless the underlying object instance is no longer valid, which would move the spot to a completely different source location. What puzzles me is that this assertion failure nor any other exception is not logged to CodeSite. After all the MMX beta hooks into AssertErrorProc as well as Application.OnException. Can you disable the JCL exception handler as well as any other ones interfering with MMX here - at least for the time needed to investigate this?

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: