bb.donnay-software.com

I put this at the beginning of my error handler and it fixed the issue.

I put this at the beginning of my error handler and it fixed the issue.

Same here. Slight changes:
It doesn't fix the problem itself, but it works. Thank you very much, Roger!

Hi,

This solution reminds me of a joke.

A large ship was docked in the port of Antwerp. The engines would not start and every day this breakdown cost tens of thousands of euros. All the engineers were called in and no one found the solution.
The last hope was an old engineer who was asked to look into the problem. He went into the machine room and turned one screw 180 degrees. He asked to try again and the engines started.
The captain asked for the bill and the engineer said 5,000 euros.
The captain asked: do I have to pay 5,000 euros for 5 minutes of work.
The engineer replied: No, the work is 100 euros, the years of knowledge to know which screw caused the problem is 4,900 euros.

Moral of this joke: Experience and knowledge are priceless.

This solution reminds me of a joke.

But, to be honest. This simple and brillant solution (I was thinking about that direction) prevents any errors inside the FUNCTON _EditProtected from being trapped, or errors in which this function maybe involved, even indirectly (wrong codeblock). This is not a problem as long as everything is okay, but it may cause big trouble if not. This is why I added "IF IsWTSClientSession()", and I'm thinking about adding more stuff like this in order to prevent this one from becoming a real killer.

Anyway, I'm very, very thankful for that idea, and my support people will be aswell.

Tom,

To be clear, the solution of Roger is not a joke, it is simple and efficient.

It reminds me to the joke because with his experience he solved it in an hour once he could test it and saw what happened.

Hi, Chris.

I understood what you were trying to say.

To be clear, the solution of Roger is not a joke, it is simple and efficient.

This is true.

What I learned from this experience is that trapping events, as recommended by Till, doesn't always work.
I also learned that I could access my Windows 10 server via RDP.
I always had used Teamviewer for this.
RDP is much preferred for it's drive mapping to the client.

Tom - I too was a bit concerned about trapping all _EDITPROTECTED errors, but I considered it a small risk in your case.
By the time you were ready to deploy your software to a Terminal Server, I would think it had been well tested.

BTW - The reason this happens only with _EDITPROTECTED is because that code block is not associated with an object that is disabled or hidden and therefore it can process events.
I never use EDITPROTECTED for that reason.
It was originally provided (many years ago) to deal with the issue that a disabled get would always be grayed, and some customers didn't like that, so this was really a workaround.

so this was really a workaround.

Democracy is a workaround.

Like this and some other workarounds, EDITPROTECT turned out to be a clever solution.

Democracy is a workaround.

Very well said.
Democracy in America is in need of some error traps.
I thought we always had them, but they need some rewrites.

BTW - The reason I expected a Break(oError) would work was because, many years ago I made sure there was a BEGIN SEQUENCE and END SEQUENCE in the DCREAD GUI event loop. The Break simply breaks to the END SEQUENCE, empties the Event Queue, and goes to the top of the loop rather than exiting the program.