Developer Portal Community

    Showing results for 
    Search instead for 
    Did you mean: 

    Suggestion: Allow to use status tiles of children in status page & configure status tile through ood

    Suggestion: Allow to use status tiles of children in status page & configure status tile through ood

    Long-established Member

    As of CPS 5.8 the status page of a mode forwarder or mode handler is limited to status tile views of the current level, so it can only display status tiles of itself and of its add-ons. I propose to allow also status tiles of its children.

    I currently have the following use case: I created a ModeHandler that can run independently, so it brings with it all the objects that it needs. I just want to drag it into the project, parameterize it and use it as it is. It also provides a status tile. However, the status tile is only visible on the ModeHandler. I don't expect the station operator to navigate to the ModeHandler on the status page so they will never see the tile. But the ModeForwarder usually has empty tiles where I could easily display it and it would bring benefit to the operator.


    My second proposal is to allow ModeHandlers and ModeForwarders to define the layout of their status page through the .ood file. It is created as a suggestion when inserting the object but can be modified by the user later, like most HMI settings right now. Saves the object user from creating the status page by themselves for standard objects.

    3 REPLIES 3

    Established Member

    Reply to first suggestion:

    Is ist not possible to use a Mod_SmartControlHost with the view from the ModeHandler on the ModeForwarder?



    Long-established Member

    I haven't tried this but I am sure this would work. But that is again more work for the user. Why not just be able to drag the child's Status Tile into the parent's (or grandparent's...) status tile overview?

    Community Moderator
    Community Moderator

    Thanks for your suggestions! I have put them in our backlog.

    About the first one: Of course it would be technically possible to make the status tile configuration more flexible but we wanted to keep the UI as simple as possible. The names of status tiles from different handlers are not necessarily unique, so we would need to work with a path to the view. Sure, we could have designed it that way. But as PKlein said, there is a workaround for this requirement, so I don't have the feeling the priority is very high.

    About the second one: In order to bring the complete status tile configuration, the OOD file would also need to be able to define status widgets. So we would have to extend the OOD syntax quite a bit. As so often, the question about the cost-benefit ratio arises, because I think we are talking about a very special case here.