Widget Assembler Notes

  • The Gui_DynamicGrid_Layout class is used when “Entity Images” are being displayed and its implementation does not make use of the Gui_Layout_Interface. You’d think Gui_ImageWidgetEx would implement Gui_Layout_Interface but it does not. What’s a little more uncomfortable is the relationship between the widget interface, layout classes and the Gui_WidgetAssemblerEx. Where the dynamic layout does not use the layout interface at all the grid does by casting the widget interface objects to the layout interface.
    • Discussed with Dwayne…1) remove the exposing of the widget list from Gui_Widget_AssemblerEx by making Gui_Layout_Base a friend.   2) Rename Gui_Layout_Interface to Gui_Grid_Interface since Gui_Grid_Layout is the the only layout derivation to use this interface.

 

  • Currently Gui_WidgetAssemblerEx has image widget loading code. This should be moved into the PS updater class.

 

  • Change the name of Gui_EntityImage_View to Gui_NavigationView or something that represents the 2D/3D-ness that the view will represent. This splitter/view class will be allow the top pane to split between a Gui_WIdgetAssemblerEx and Dave’s soon to be derived class that uses the hierarchy to allow for 3D display which can then be saved to a 2D layout.

 

  • A new Gui_Widget_AssemblerEx derivation will need to be made to support Plant Setups need for allowing a “View” to be created using image widgets and menu widgets representing Inspection Points. In the PS implementation, the addition of an IP onto the canvas should create a menu widget by default with a connector that can be attached to a point on the image. The connector should be allowed to be maneuvered around the edge of the source IP. The destination end of the connector should only be allowed to be attached to a destination connector type, in this case an image widget. As the destination connector type is moved or resized, the connector end point should adjust accordingly.
    • Some of these issues are general and will be included so as to allow the Reporting Client to use these  features for custom report creation.
    • Additional general issues include being flexible enough to handle resolution adjustments and adjusting to print within the selected page size.
    • The existing menu widget will need to be ported to the new widget hierarchy.

 

  • A new Gui_Widget_AssemblerEx derivation will need to be created to support the Reporting Clients need for creation a custom report. The specific need in 4.7 is for the Die Hemmer report which is the same functionality needed in the PS description above with the exception of the IP in this implementation will be represented by a trend chart with a maximum of 5 jobs being displayed.
    • It would seem that the only difference at this point in this class and the PS class is the type of widget created when an IP is added to the canvas.
    • It may be that there is a derivation of the existing Gui_Widget_AssemblerEx that includes the common implementation and then the PS and RC specific types just implement a hook method to supply the type of widget to be created when an IP is added to the canvas. Alternatively the common code could be pushed into the existing Gui_Widget_AssemblerEx.
    • The existing trend chart widget will need to be ported to the new widget hierarchy. Porting this widget will allow us to investigate how we’ll handle pushing data into the trend chart.

 

  • In converting the current PTV’s in PS to the new line of assembler code the list control within the Gui_EntityImage_View will be able to be used. The problem will be in determining which container to display. The current PTV displays either the Aps_InspectionPoint or Aps_ExternalInspectionPoint. The only difference between these types is that the latter filters to only external IP types (offline cell IP’s). In order to display only IP’s that are assigned to the PTV being displayed we’ll need to create a database view that returns the appropriate IP’s. The problem is completely a display problem in that I don’t want to have to derive a new class from both Aps_InspectionPoint and Aps_ExternalInspectionPoint.
    • One solution that might work would be to implement the tableName method of both classes to return the new database view when the current level is the PTV level.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*