Problem with disabled windows on Terminal Server

[rdonnay]

Let's try this:

Code: Select all

METHOD DC_XbpDialog1:handleEvent( nEvent, mp1, mp2 )

IF nEvent $ { xbeP_SetDisplayFocus, ;
              xbeP_SystemPowerStatus, ;
              xbeP_SystemPropertyChanged } .AND. !::isEnabled()
  RETURN nil
ENDIF

RETURN ::XbpDialog:handleEvent( nEvent, mp1, mp2 )

[rdonnay]

It's interesting that there have been 1000 views already of this topic.

Apparently, search engines are sending programmers who are not Xbase++ programmers to this forum for the same or similar problem.

It suggests that it's more of a Terminal Server problem than an Xbase++ problem.

[Tom]

People just want to follower our excellent dialogues.

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

erroragain.png (160.58 KiB) Viewed 2203 times

[Tom]

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

[rdonnay]

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

What you are saying is true, but the error is a "secondary fault" which is caused by the system generating an event on what should have been a disabled window. That's why I agreed with Till on insuring that any such event should not be processed. Maybe I am returning a wrong value and it should not be a nil that is returned by ::handleEvent.

I could put a trap down in the routine that causes the error and force a break, but the band-aid should be at a higher level. What frustrates me is the fact that I have no way of testing this because I can not reproduce the error. If someone would give me access to a more current version of a terminal server, I could have a fix very quickly.

I hate putting fixes in my code like this. I did this once or twice for Cliff Wiernik, as you may recall, and that was a big mistake. I'm going to suggest one more change to DC_XbpDialog1:handleEvent and if that doesn't fix the problem, then I will put a trap in the DC_Getlist class to break out of the error. I just realized that there is probably no reason to process any events on a dialog that is not enabled, so let's try this first.

Code: Select all

METHOD DC_XbpDialog1:handleEvent( nEvent, mp1, mp2 )

IF !::isEnabled()
  RETURN self
ENDIF

RETURN ::XbpDialog:handleEvent( nEvent, mp1, mp2 )

[rdonnay]

A simple workaround for you may be to do this:

Code: Select all

WAS:  @ 1,1 DCSAY 'Name:' GET cName EDITPROTECT {||kd->name == 'Roger'}

IS:  @ 1,1 DCSAY 'Name:' GET cName WHEN {||kd->name != 'Roger'}

[Tom]

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 wrong value and it should not be a nil that is returned by ::handleEvent.

I'm sure this is not your mistake. Till was able to reproduce the wrong behaviour without using eXpress++. This is a situation that should not happen. I believe it's designwise in Xbase++.

I hate putting fixes in my code like this.

I can understand that very well.

I was hoping for an elegant solution, since we have that thing some dozend times a week. Maybe I look for a way to close that kind of child dialogs if a xbeP_SystemPowerStatus event comes up and I know the app runs in Terminal Server mode.

[k-insis]

> If someone would give me access to a more current version of a terminal server, I could have a fix very quickly.

You can repeat crash (with that piece of test code) if you connect from your desktop to any fully patched Windows 10/11 [Pro / Workstation] machine via RDP. A Virtual Machine will do as target too, there is no need for full blown terminal server to simulate it.

[Tom]

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

[rdonnay]

A RDP-session hosted by a Windows-10-machine will produce this error aswell.

I have a Windows 10 machine that I use as my web server.
I didn't know that I could enable RDP on that machine.

I installed Terminal Services and have been able to see the same error now that you see.

This should help a lot.
I hope I can find a fix.

What is interesting is that I can click 'Cancel' on the error window and the window disappears but the app keeps running.
This means that possibly this error can be trapped in a global error handler.