bb.donnay-software.com

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...

I put this at the beginning of my error handler and it fixed the issue. Same here. Slight changes: IF IsWTSClientSession() FOR i := 0 TO 10 IF '_EDITPROTECTED' $ ProcName(i) Break(oError) ENDIF NEXT ENDIF * Somewhere else: // Check whether the current process runs in a Remote Desktop session. FUNCT...

Yes, I forgot to mention this, thanks. A RDP-session hosted by a Windows-10-machine will produce this error aswell.

Hi, Roger. A simple workaround for you may be to do this: Uh. Besides WHEN is completely different to EDITPROTECT, this would effect thousands of lines of code, it would effect the app behaviour (and the look of the UI) - and we have mixes of both. This is not a solution. Maybe I am returning a wron...

This looks like HandleEvent of the dialog is not involved. It's inside the event loop.

People just want to follower our excellent dialogues.

Anyway, same problem. I attached my _DCGETBX.PRG to help you to see the causing code.

Here is the log. It seems to be the xbeP_SystemPropertyChanged event causing trouble.

Sorry for my late answer; I once again had that top-modern corona-thing, although I'm vaccinated at least twenty or thirty times. 8)

I will test that later the day. Unfortunatley, I can't give you a guest access to our RDP server.

Hi, Roger. I was in contact with Till again about this problem. He confirmed the (mis-)behaviour, but Alaska is not going to change something there. This is what he wrote as a suggestion for a solution (translated with Google): Once again the proposed solution: in my tests, the xbeP_SetDisplayFocus ...

We had that several times already.

http://bb.donnay-software.com/donnay/vi ... 932#p15932