I have been searching high, and low for a solution to this problem. I am very suprised I have seen no mention of it by anyone.
I have placed Microsoft's WebBrowser control within an application, and, using that control have opened an Excel spreadsheet. This works reasonably well and allows me to control, atleast somewhat, how much a user can do.
The spreadsheet is displayed for the user and is being used to allow them to import data into the database, while giving them an oportunity to correct the data, and manipulate it as necessary before importing. All of this has been working quite smoothly with only minor issues, except one.
The major problem I have been having has to do with refreshing the screen. When the control is simply being used to display an html document it experiences no problem refreshing, however, when the control is used to display and interact with an Excel Spreadsheet it sometimes fails to redraw itself when it has become obscured. (A window appears in front because it popped up, or the user has switched to another application, etc.).
Is there any sure fire way to get the window, specificly the control to refresh when it is visible again? In the mean time to do testing I have attached a button to the window which makes the control (WebBrowser) visible=false and then immediatly visible=true. This has worked well, but is not acceptable once the application is deployed.
I am using Progress 8.3C, but have also experienced the same problem with 9.1A. As well the WebBrowser control exhibits this behavior with 4.x and 5.x versions of Internet Explorer. Office 97 (Excel) was used in all cases. (Multiple computers were used as well, same behaviour).
If you wish to duplicate this problem please try the following:
Drop a WebBrowser control, reasonably sized on a Progress Window, then run. Simply drag and drop a spreadsheet onto the control. The control will then open the spreadsheet. Now, repeat as necessary, obscure the window.
Sequence of events:
When the window redraws the control (Spreadsheet) is drawn FIRST, then, Progress draws its Window and seems to obscure the control when it draws the background (again, not always). The control then never seems to get a message to correct the now corrupted screenspace.
I *think* this may relate the the optimizations Progress has taken by using the ERASEBKGRND message to paint the screen, causing the WM_PAINT messages to never occur.
I am going to attempt to use the MsgBlster control I found elsewhere to trap the messages and force a repaint but I would be *very* interested in an alternative solution.
I have placed Microsoft's WebBrowser control within an application, and, using that control have opened an Excel spreadsheet. This works reasonably well and allows me to control, atleast somewhat, how much a user can do.
The spreadsheet is displayed for the user and is being used to allow them to import data into the database, while giving them an oportunity to correct the data, and manipulate it as necessary before importing. All of this has been working quite smoothly with only minor issues, except one.
The major problem I have been having has to do with refreshing the screen. When the control is simply being used to display an html document it experiences no problem refreshing, however, when the control is used to display and interact with an Excel Spreadsheet it sometimes fails to redraw itself when it has become obscured. (A window appears in front because it popped up, or the user has switched to another application, etc.).
Is there any sure fire way to get the window, specificly the control to refresh when it is visible again? In the mean time to do testing I have attached a button to the window which makes the control (WebBrowser) visible=false and then immediatly visible=true. This has worked well, but is not acceptable once the application is deployed.
I am using Progress 8.3C, but have also experienced the same problem with 9.1A. As well the WebBrowser control exhibits this behavior with 4.x and 5.x versions of Internet Explorer. Office 97 (Excel) was used in all cases. (Multiple computers were used as well, same behaviour).
If you wish to duplicate this problem please try the following:
Drop a WebBrowser control, reasonably sized on a Progress Window, then run. Simply drag and drop a spreadsheet onto the control. The control will then open the spreadsheet. Now, repeat as necessary, obscure the window.
Sequence of events:
When the window redraws the control (Spreadsheet) is drawn FIRST, then, Progress draws its Window and seems to obscure the control when it draws the background (again, not always). The control then never seems to get a message to correct the now corrupted screenspace.
I *think* this may relate the the optimizations Progress has taken by using the ERASEBKGRND message to paint the screen, causing the WM_PAINT messages to never occur.
I am going to attempt to use the MsgBlster control I found elsewhere to trap the messages and force a repaint but I would be *very* interested in an alternative solution.