3 Replies Latest reply on Mar 2, 2013 12:36 AM by ainwood

    Suppressing dialogs when opening a Processbook Display




      This is somewhat related to this thread:




      I have a C# application that I am using the batch files, and turning on Macro Protection works with respect to preventing VBA code running.  However, I have another problem.  In some of the files I am opening, there are other errors or issues.  For example, one set of files uses PI DataSets that actually read from Access Databases.  If these datasets aren't configured properly (many aren't!), then when the display is opened, the user is presented with a dialog to select the correct database. 


      Is there any means of supressing this?


      What I have found is that if I open the file manually, I get this alert.  I hit "Cancel", and get a message "No data to display".  If I then close the display and re-open it, I DON'T get the message.  This gives me hope that there is some sort of application setting that controls this behaviour.  The setting is  not a persistant one, as it only works provided that I don't close the ProcessBook application before reopning the display. 


      Anyone know what I can do to address this?







        • Re: Suppressing dialogs when opening a Processbook Display
          Ahmad Fattahi

          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.

            • Re: Suppressing dialogs when opening a Processbook Display

              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,

                • Re: Suppressing dialogs when opening a Processbook Display

                  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.