Problem with disabled windows on Terminal Server

[Tom]

Hi, Roger.

This is some kind of uh-uh-problem. I already discussed it with Alaska Support.

I have an non-modal application window showing a modal dialog. By (not so good) design, this modal dialog uses some tables with same aliases and stuff like the parent dialog does, so all tables are closed and pointers are saved before the modal child dialog is build. After this dialog ends, it restores all workareas, pointers and so on. But in the parent dialog, there are lots of WHEN and, especially, EDITPROTECTED clauses referencing those tables - which are closed while the child dialog is shown, so evaluating EDITPROTECTED would cause trouble. This is no problem, since the parent dialog is disabled because the child is MODAL. But. If this is used in a Terminal Server situation and the session is closed and re-opened again,for the time of a twinkle of the eye, the parent dialog gets the display focus - and SetDisplayFocus() and/or SetInputFocus() is evaluated. This only happens on Terminal Servers and only if the session was disconnected and re-connected again. The child refreshes somehow, and the parent refreshes aswell - although it is disabled. EDITPROTECTED fails, since there are not tables. This is caused by the call of _EditProtected in line 4725 of _DCGETBX.PRG (build 267).

Till Warweg confirmed that this is not intended, but they don't have a solution. He suggested to reflect that situation somehow, but I don't have an idea. The dialogs are huge and full of legacy code, and the number of clients using Terminal Server grows day by day. Any ideas? Moving the child to a thread is not a solution.

[Tom]

I'm trying to build a small sample tomorrow that demonstrates the problem.

[rdonnay]

I'm trying to build a small sample tomorrow that demonstrates the problem.

That would be very helpful.

I work with applications on a terminal server all the time, so it will be easy for me to test this.

[Tom]

Hi, Roger.

If you compile and run the attached code and use the button "Test" showing a very simple dialog, you may log out from your computer and come back or you may minimize a Terminal Server session where it runs - this works fine. But if you close the session while "TestWindows" ist open and re-open the session, the app will crash somewhere in "_EditProtected", since the main window gets the display focus (although it's child is modal) for a second and tries to evaluate the EDITPROTECT clause.

Code: Select all

#include "dcdialog.ch"
#pragma library("dclipx.lib")

FUNCTION MAIN()
LOCAL aStruct := {{'NAME','C',50,0},{'VORNAME','C',50,0}}, GetList := {}, GetOptions := {}, oDialog, cName

DbCreate('kunden',aStruct)
DbUseArea(.T.,,'kunden','kd')
APPEND BLANK
REPLACE NAME WITH 'Meier', VORNAME with 'Horst'
UNLOCK

cName := Name

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

@ 5,1 DCPUSHBUTTON CAPTION 'Test' SIZE 7,1 ACTION {||TestWindow(oDialog)}

DCREAD GUI FIT ADDBUTTONS PARENT @oDialog EVAL {|o|SetAppWindow(o)}
RETURN NIL

FUNCTION TestWindow(oOwner)
LOCAL GetList := {}, oDialog
SELECT kd
CLOSE

@ 1,1 DCSAY 'Just something'

DCREAD GUI FIT ADDBUTTONS MODAL PARENT @oDialog

DbUseArea(.T.,,'kunden','kd')
DbGotop()
RETURN NIL

PROCEDURE AppSys() ; RETURN

[skiman]

Hi Tom,

Maybe Roger will find a solution for this, but I was wondering why you are closing your files? You saves the pointers to everything before you closes the files. These pointer are used after re-opening to create the same position for every file. Why not just saving the pointers and restores them without closing?

Another solution could be to open the files with another alias in your modal? I have a function fileopen(...) to open my files. If I use fileopen("customers") which is used to open a customer file and all the indexes with alias customers. If I use fileopen("customers1") it opens the same file with the alias customers1.

Another thread would be the easiest solution, but you mentioned this isn't an option.

[Tom]

Hi, Chris.

This is not the code of my application.

I have reasons to act this way. The code called by the calling window (in my application) is a very huge planning system, which normally runs in it's own thread, but the same system may also be called in a somehow reduced version from somewhere else and it can't be in a thread or non-modal then. I struggle with this problem since years now; believe me, I tried everything to get around there, but the only way to eliminate it would be to re-write tons and tons of code. Please, don't waste your time with suggestions. I know them all; I tried them all.

Anyway, this is misbehaviour. A window having a modal child should not get the display focus. The reason is not inside eXpress++! It's by the design of Windows RDP or XBase++. If Roger doesn't come to a very simple clue, I will try to force Alaska to find a way.

Thanks!

[skiman]

Hi Tom,

This is not the code of my application.

Oh, I thought it was your application.

[Tom]

Oh, I thought it was your application.

My application is not as complex as this.

[Wolfgang Ciriack]

My application is not as complex as this

I am missing the "Hello World" in your application

[Tom]

I am missing the "Hello World" in your application

Wait for the next major release! It will be even able to print it!
Edit: In color!