We're using HttpGet to retrieve data from an XML web service, and it works well. The problem is sometimes the web service takes a long time to return, and when our app is in the call to HTTPGet, the entire VFP window goes black while it's waiting. We see it on Server 2012, and also on a windows 7 PC. I don't see it if I run the application locally on my Windows 10 pc as an app in VFP.

It seems to occur during the initial connection process, rather than the actual data transfer. If I override OnHTTPBufferUpdate and display a status message, it hangs for quite some time before the first status message appears. Then the messages appear quickly.

Is there any way to prevent the screen going black? Hanging with a wait spinner is OK. The black screen confuses our users. Here's the code we're using, pretty straightforward.

lcColorsXML = loHTTP.HttpGet("http://api.xxxxxxxx?updatedsince=" + lcUpdatedSince, alltrim(vendor.x), alltrim(vendor.x)

Chris,

Sounds like you have connection issues with the server operation or you are uploading data to the service - there are no hooks for capturing the upload process and while you're in that call VFP is effectively hung while it's waiting to hear back. Unfortunately there's no good workaround for this with this implementation since it's FoxPro based (single threaded). There are async versions of HTTP get you can use that will avoid this but they are more complex to work with if you need to capture the result data and not as reliable.

I think the problem is excaberated on Server OSs because the server is not optimized for UI operation, so there are fewer UI update cyclces provided on the server which makes the problem worse. Basically the server assumes you're running unattended. You can try switching the Windows Optimizations to be UI based on the server which should give you similar behavior to what you see on Windows client versios. It's configured in Advanced System settings.

+++ Rick ---

We're using HttpGet in WWInternetProtocols as part of a VFP 9 desktop client application. The client app is connecting to a web service to retrieve XML data, that's where we're seeing the black screen. I think what's really happening is:

1. We make a connection to the web service to download the XML data using HttpGet
2. The web service runs a query of some sort behind the scenes that takes upwards of 60 seconds to complete. This part is a black box to us.
3. When the query finishes, they start sending the XML data back to us.

#2 is where VFP hangs on the client desktop and the VFP desktop goes black. Once the data downloads we become responsive again.

I think you're right in that there's not much to be done. We're just going to put a message on the screen beforehand that says something to the effect "Downloading data...please wait...the screen may freeze...don't worry :)"

If you have operations that take this long it's a good idea to offload them to an asynchronous task or a separate thread. There HttpGetExAsync() which may work to run asynchronously but as I mentioned it's not quite as full featuerd as the direct HttpGet Operation.

Web Connection also has a ThreadRunner class that allows running FoxPro code on separate threads with notifications. It's a bit involved to set up but actually works really well for offloading long running tasks and then getting notified. It works by either creating a COM DLL of the code or distributing a PRG or FXP file along with your app that handles the external task.

There's an example that demonstrates making many simultaneous HTTP requests asynchronously here:

How Thread Runner Works

Another way you can do this that's maybe simpler is to simply create a separate EXE that executes the task and let it run in the background. Write out progress or completion to a file and occasionally check for the file. I've used this approach in a few occasions to offload processing from the main Foxpro process prior to the multi-threaded functionality.

+++ Rick ---

Thanks for your help Rick.