How to prevent [not responding] state for too long ?

[Former Member]

Hi,

We have some batch processes that could be very long, like several hours.

To complete them, customers have to launch it at the evening before to go home.

In Citrix environment, it seems that the process is killed if it stays too many time in a "not responding" state.

What is the good way to respond to Windows, to tell him the application is fine but still working ?

I don't want the user to be able to interact neither, so I doubt about Yield().

Is there a better solution ?

Guillaume

[Former Member · Accepted solution]

I write batch programs without windows, all the code is in a non-visual object called from the application open event. I then schedule them to run automatically using the Task Scheduler tool in Windows. This removes Citrix from the process entirely.

[Former Member · Accepted solution]

It's probably the solution that we will consider for the future, adding an automatic mode to be launched on a dedicated machine, every three month in this case.

For now I just want to make sure that if I avoid the "not responding" state it prevents the process to be killed.

[Former Member · Accepted solution]

Perhaps you could run it in a background thread using the SharedObject functions. The user interface would not show as busy because it is in a different thread.

[Former Member · Accepted solution]

That sounds like a good idea.

In addition it's possible that threads allow me to parallelize and thus to speed up the process.

But, because of the actual design, it's a big piece of rewriting because the thread will need its own transaction and many global variables we use.

[former_member1333806]

My understanding of "Not Responding" is that your window isn't processing WM_PAINT messages.

As far as native PB goes, Yield() throughout your process is probably your only option, accompanied with a routine that disables/enables your entire UI before and after your overall process (there's probably a generic algorithm to do this for any window, but I haven't written one myself).

If you're willing to go to APIs, one thing I tried at one point was code my own Yield()-type function that would only process WM_PAINT messages. It basically looked in the message queue for WM_PAINT messages (PeekMessage() for message 15), removed them (the RemoveMessage parm from PeekMessage()), and pushed that message and it's parms through to the window (Send()). It worked for a while, then failed (I think with a PB upgrade, but it could have been an OS upgrade), so I'm not sure that sharing my code that doesn't work is much help.

Good luck,

Terry.

[Former Member]

Hi Terry,

I understand the same, but maybe it's another message that have to be processed, maybe WM_UPDATE.

Yield() seems to be the simplest solution and I want to keep it simple if possible.

Guillaume

[Former Member]

Hi,

At first thought, this might have been caused by Windows 7 ghost processing.

You could try to turn it off or run the application in a compatibility mode of an old Windows version.

It might be the Desktop Window Manager service who does this, have you tried turning it off?

There is also an API that you can call DisableProcessWindowsGhosting

subroutine DisableProcessWindowsGhosting() library "user32.dll"

Not sure why you are worried about a user interacting with the application when he just went home

But otherwise an alternative might be performing the batch in a separate thread using a wrapper shared object and prevent user interaction in a different way.

Ben

[Former Member]

Not knowing about this ghost feature haunts me.

But I don't think it's related to Windows 7, it was already the same with XP.

I'm not sure of what this Desktop Window Manager service is, and if I can turn it off.

I will try the API function you mentioned.