Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.

Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.

Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.

Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.

Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.

Perhaps it is better to open a new discussion on the "not responding state".

Situation:

"main-program" (Menue)

          Call Thread "program-1"       (window 1 with user-action)

          Call Thread "program-2"      (window 2 with user-action)

In a normal environment, I can start processing in "program-1" and switch to the "program-2" window or the "main-program" menu window during processing with no problems and limitations.

In the Thinclient environment, it is no longer possible to switch to another window if a processing routine is running in the current window. If the mouse is clicked into another program window, the program falls into the "not responding state" until the processing in "program-1" is finished.

If a progress dialog (for example w$progressdialog) is used, the window of "program-1" will expand to the entire screen and will be reset to the old size only after the end of the processing. The User see the "not responding state" and cannot do any other action in this application.

If processing takes more time, the server runtime detects no more a client activity unless you use the "w$progressdialog" routine.

For me, it looks like the AcuToWeb extension has affected multithreading in general.

Can this be influenced by any configuration settings?

All Components are Version 10.1.