When application is started twice, then the instances affect each others waitstates

[jdijkstra]

We have made a rather big ERP application, the platform is Progress OpenEdge. It is a 32 bits windows application. Some of the windows in the application are showing HTML thanks to the great Antview control. The application is using the AntViewGlobal interface.

Our users have the habit of starting two instances of the application, because if one instance of the application is busy doing a lengthy operation (like a report with difficult queries) then they can use the second instance to get work done in the meantime.

Since we have released a version that uses Antview, our users report that they can not use two instances anymore. Well, they can, until one of the instances is busy (and showing the IDC_WAIT cursor formerly known as the hourglass) because then the other instance is also showing the same cursor and is also blocked for input!

This has me puzzled for weeks. How can a cursor in one process affect the other process.

This morning I did an experiment: I removed Antview from the application. It behaved normal again: one instance busy and blocked for input during a length operation, the other instance available for input. Added Antview back in and the problem came back.
So, the problem is something in Antview.

Then I started experimenting with settings. I have tried to specify different app-id in each instance, by using 
     AntViewGlobal:AdditionalBrowserArguments = '--app-id=somevalue'   (where each instance has a different somevalue)
That caused a different problem: the first instance would work fine but the second instance could not create the webview control.
That means to me that AntviewGlobal is indeed global, very much so.

So then I tried to use Antview without AntviewGlobal, and set the AdditionalBrowserArguments in the Antview itself. That did not help. 

I am out of ideas. Do you have any suggestions?

[wila]

Hi,

That's weird.

First off, the AntView global object is global to the application and not to the whole of the windows operating system.

The "--app-id" chrome flag that you tested this with is not intended to just randomly add a tag, it was designed for application-mode.
See the following links for a bit of an idea:
https://peter.sh/experiments/chromium-co...-switches/
https://askubuntu.com/questions/1222021/...cli-option
https://superuser.com/questions/33548/st...ation-mode

I'm not too surprised that adding an app-id doesn't work well with WebView2 and I wouldn't draw conclusions from using it.

Just to rule out this path.. some additional questions from my side as I am not that familiar with Progress OpenEdge.
I expect that each time you start a new version of your application that it has its own process ID.
In other words, when you look at your application instances from Windows Task Manager, I would expect to see two lines in the "Details" tab and each having it's own "PID" number.

With that out of the way, let's see if we can figure out what is happening here.
It certainly is not something I would expect to see.

Can you tell us more about the process that is keeping the first instance busy?
What is it processing? Is this waiting for a website to complete.. something else?
What AntView method is being called in the first instance when the process is waiting?

thanks,
--
Wil

[wila]

Hi,

Been doing some digging...

So as you might know, the WebView2 control that AntView wraps is uses an Out Of Process COM model.
As such when you create the WebView2 control it starts a bunch of msedgewebview2 processes in the background. Similar like how all the major browsers nowadays start many processes to handle browsing websites.
Your application's WebView2 component then communicates with those background processes to make it look like a native control to your application.

As you can imagine this is all very resource intensive, so the smart WebView2 developers are re-using those background processes when you start the second instance of your application. 
You can see this by querying for the process ID in AntView via BrowserProcesID.
The 2nd instance of your application will report the same Process ID as the first instance.
I _think_ that this background process re-use is what is biting you.

Is there no way to prevent the 2nd instance from re-using the existing msedgewebview2 processes you might wonder?

WebView2 determines if it re-uses the existing msedgewebview2 processes or not  based on the User Data Folder that is used.
It seems the current version of WebView2 is ignoring our ability to change the User Data Folder setting for this via the UserDataFolder property, so we are currently researching why that is so.

You can probably test the above "background process re-use" hypotheses by having a copy of your application in a different folder, start that copy for the 2nd program instance and see if the lock up issue still occurs.

--
Wil

[jdijkstra]

Hi Wil,

Thanks very much for looking into this.
To check again I have just now started the application two times. In Task Manager, tab Details I see two separate lines for "prowin32.exe" with different PIDs. The Processes tab is showing something strange: one of the Prowin32 apps appears to have 4 WebView2 children and the other Prowin32 app appears to have no WebView2 children. But this is not actually true because these apps are the same, I am seeing an html view in both of them. A little screenshot:

   

The busy program can be busy with anything at all, like waiting for a stupid database query that reads a lot of records, or reading and parsing a bunch of files from a directory (and storing the found data in the database). Just anything that takes long. These are tasks that existed in the application before we added the Antview OCX and the tasks do not seem to be HTML of Antview related at all. 


No Antview method is being called in the first instance when the process is waiting :-)
Although, well now that you mention it, maybe there is. The main window has an Antview OCX and it displays the main menu of our app (we have made a mainmenu HTML project and Antview navigates to it). When the user clicks a menu item, which is an HTML element, then the HTML project does a PostMessage call and our Progress OpenEdge sourcecode catches the Antview.OnWebMessageReceived event. In the eventhandler we save the parameters in a variable and start a timer. When the timer fires it onTick event we parse those variables to see which menu-item was clicked and launch the requested Progress procedure. We use that timer to make sure that the OnWebMessageReceived has returned before we launch the menu-item, so I THINK there is no Antview method being called, but you never know. Some method may still be unprocessed without me be aware of it? 
But still, how would that affect the other prowin32 process?

Weird indeed.

---

You can probably test the above "background process re-use" hypotheses by having a copy of your application in a different folder, start that copy for the 2nd program instance and see if the lock up issue still occurs.

Excellent, I will try and experiment with that, and will let you know

[wila]

Hi again,

The issue that we were seeing down here with the UserDataFolder property not being respected was -as expected- a bug in AntView. It only happened when you call CreateWebView from the OnCreate event as then the control was being created before the actual global setting was applied.

This has been resolved and I will send you a private version of AntView in a bit.

With this resolved, we were also able to test and see if the WebView2 background processes are being re-used if a different UserDataFolder is set for each application instance. Turns out that it does indeed not re-use the existing background processes once you use a different UserDataFolder.

I will send you the private build by email in a bit.
--
Wil

[jdijkstra]

Awesome, I will test it as soon as I get the private build. Thank you very much for all your help

[wila]

For others reading this.

The customer has let us know that the issue was resolved by setting the UserDataFolder for the second instance to another value.
By doing that the 2 application instances no longer shared the same background processes and as such the blocking issue that was reported has been resolved.

--
Wil