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.
Excellent, I will try and experiment with that, and will let you know
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.
(2024-04-08, 09:29:11)wila Wrote: 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