What I am hearing several folks done in this case is to kill these pop-up windows when they occur. So you would an add-on that uses a handle to the main window. Any child pages of this main window can be closed by invoking their close. The check to see if such child windows exist can be done periodically, or whenever you suspect such errors may occur.
By the way, the long term solution to this problem is that we (the ProcessBook developers) have been moving towards using the status bar and other indicators as opposed to message boxes whenever an error occurs that is not directly caused by a user action. (You'll notice that most of the add-ins have an icon on them to display errors rather than displaying message boxes). The message boxes are being removed whenever we are working on a section of code that has them (there are already far less of them than in, say, 188.8.131.52).
Yes, if that could be done it would be great! Note that it is not just "errors", but also such things as datasources for datasets not being found, or VBE compile errors.
For info, how I have handled this:
1.) Before attempting to open a display file, start a new thread.
2.) In the new thread, put a timer object. The timer event does the following each cycle:
a.) Get all top-level windows owned by the ProcessBook Application Process (enumThreadWindows for each thread owned by the Procbook process)
b.) Test each hWnd to see if it is modal (GetWindowLong using GWL_EXSTYLE and GWL_STYLE to test for WS_EX_DLGMODALFRAMEand WS_POPUP respectively). On reflection, I could have first tested the Application hWnd to see if it is disabled).
c.) If a hWnd is modal, the enumerate its child windows. I use SendMessage with WM_GETTEXT to retrieve the windowtext of each control. If it is "Cancel" or "OK", then I use SendMessage to click it.
Once the display has loaded, I let the timer click once more through, then shut-down my popup watcher thread.
A few notes:
* This seems to work OK. Thought about using the WM_CLOSE message, but found some windows wouldn't close with it (Note that this was in early testing, and I might not have been sending the message to the correct window)
* I found that GetWindowText doesn't always return the text correctly for child windows, so used SendMessage instead (again may have been an early testing problem).
* The button / control text needs to be parsed. Note that sometimes it has "&" characters in it, so these need to be stripped out.
* If developers could expose Application.hWnd (for the main window) to the PBObjLib.Application Object Library, then that would be great! In C# (which I am using), I can't get the MainWindowHandle from the Procbook process unless running at elevated security, so have to go via a convoluted route to Enum all windows and find one where the caption and Process.ID match.