SmartToolbarController - Causing App To Exit? Cancel The title field is required!

1. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   15 Apr 2020

   Link to this post

   I have been working with PTS for a week on an issue where our app will just close after making a call to SonicMQ. In reviewing logs the 4gl adapter appears to be throwing a STOP. The funny thing is if I call my method from a simple ultrabutton on the form it works just fine.
   
   /*------------------------------------------------------------------------------
     Purpose:
     Notes:
    ------------------------------------------------------------------------------*/
    @VisualDesigner.
    METHOD PRIVATE VOID ultraButton1_Click( INPUT sender AS System.Object, INPUT e AS System.EventArgs ):
     
     THIS-OBJECT:RefreshInventory().
     
     RETURN.
    END METHOD.
   
   However,
   
   If I call the same METHOD from the Toolbar the app will just close.
   
   METHOD PRIVATE VOID PriceToolbar_ToolClick( INPUT sender AS System.Object, INPUT e AS Infragistics.Win.UltraWinToolbars.ToolClickEventArgs ):
   
    THIS-OBJECT:RefreshInventory().
     
     RETURN.
    END METHOD.
   
   The RefreshInventory METHOD is basically using the sonic 4gl adapter to perform a requestreply so it will be in some for of wait-for-message in the adapter.
   
   I am not saying this is related to the toolbar but the issue only happens from the toolbar. I have even gone to a few of our old forms and tested from an ultraToolbarsManager1 and it works just fine.
   
   I was just wondering if you had any thoughts on if there is something in the SmartToolbarController that could be causing this?
   
   Thanks in advance.
   
   
   
   
   
   
2. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   15 Apr 2020 in reply to Roger Blanchard

   Link to this post

   Error handling and especially stop conditions are generally more fragile with GUI for .NET and hybrid classes in particular.
   
   Do you have a .NET Stack trace or a protrace/procore file?
   
   Generally, *every* (.NET) Event handler should have a CATCH block. You can use the 
   
   {Consultingwerk/Windows/uicatch.i}
   
   include file. In this case, I would suggest to utilitze the catchStop feature of OpenEdge 11.7.5 and beyond to handle STOP conditions. An uncaught error thrown from a handler of a GUI for .NET event will be turned into a .NET Exception and will be thrown to the .NET side.
   
3. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   15 Apr 2020 in reply to Mike Fechner

   Link to this post

   I was using a CATCH (shown below) so I commented my CATCH and used yours. No difference. There is no procore or protrace. It is as if the app is exiting gracefully. You can see a STOP in the 4gl adapter. It is the weirdest thing. If I run against PASOE I do not see the issue either. The logic that connects to SonicMQ is server-side so I am seeing this in PDSOE or when running shared memory on the server.
   
   
   
   @VisualDesigner.
    METHOD PRIVATE VOID PriceToolbar_ToolClick( INPUT sender AS System.Object, INPUT e AS Infragistics.Win.UltraWinToolbars.ToolClickEventArgs ):
     
     
     DO ON ERROR UNDO, THROW:
      
      IF VALID-OBJECT (rMainMenu) THEN
       rMainMenu:CURSOR = System.Windows.Forms.Cursors:WaitCursor NO-ERROR.  
      
      CASE e:Tool:Key:
       WHEN "Excel" THEN
       DO:
        IF THIS-OBJECT:orsTabControl1:ActiveTab:Key = "Items" THEN
         THIS-OBJECT:ItemBrowser:ExportToExcel().
        ELSE IF THIS-OBJECT:orsTabControl1:ActiveTab:Key = "Inventory" THEN
         THIS-OBJECT:StoreInventoryBrowser:ExportToExcel().
       END.
       WHEN "Refresh" THEN
       DO:
        IF THIS-OBJECT:orsTabControl1:ActiveTab:Key = "Items" THEN
         THIS-OBJECT:ItemSearchAdapter:RetrieveData().
        ELSE IF THIS-OBJECT:orsTabControl1:ActiveTab:Key = "Inventory" THEN
         THIS-OBJECT:RefreshInventory().
       END.
        
      END CASE. 
      
      {Consultingwerk/Windows/ui-catch.i}                                         
      
      /*   
      CATCH eError AS Progress.Lang.Error:
       LogManagerWrapper:WriteError(eError).
       MESSAGE ErrorHelper:FormattedErrorMessages(eError)
        VIEW-AS ALERT-BOX ERROR.
      END CATCH. 
      */
      
      FINALLY:
       IF VALID-OBJECT (rMainMenu) THEN
        rMainMenu:CURSOR = System.Windows.Forms.Cursors:DEFAULT NO-ERROR.      
      END FINALLY.  
       
          
     END.
     RETURN.
     
    END METHOD.
4. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   15 Apr 2020 in reply to Roger Blanchard

   Link to this post

   A CATCH for Progress.Lang.Error won't handle a STOP condition. You need to use the new catchStop behavior and the specific Stop-Classes available since 11.7.5.
5. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   15 Apr 2020 in reply to Mike Fechner

   Link to this post

   Yes, we have catchStop 1 enabled and tried the following with no luck.
   
   
   CATCH eStopError AS Progress.Lang.StopError:
       LogManagerWrapper:WriteError(eStopError).
   END.