Emerson Exchange 365

DeltaV Live - Tabs

Anyone else have the issue when using a Tab GEM, that on a TabItem if select an object and try to move them then the objects get kicked from the tab layer and to the main layer of say the display. Extremely frustrating, and essentially from my experience is making them almost impossible to actually use. If you move the object with the mouse, it seems to stay in the tab layer, if you use the arrow keys its an immediate jump out of tab layer to the base layer of the display

To me this is abnormal behavior, at least I believe it to be, I will open a Guardian Case so that it gets to Product Engineering, or maybe there is a fix for this, anyone else seeing this?

Benji_Kidmose

• 17 Aug 2024 3:07 PM
• Cancel

6 Replies

• Benji_Kidmose

  

  • 19 Aug 2024 2:51 PM

  Update - Even tried creating the "Tab" As a SubGem, but same results, if you move any item on a Tab Layer with the Keyboard it jumps off the Tab Layer to whatever the Main layer is, in the case of a GEM it jumps to the white space in behind the Tab Layer, but is still visible, but essentially visible on each tab.

  With Layers no longer a thing in Live, making your own "Tabs" will not be super easy just using visibility. Maybe a variable set on each Display should be created to essentially create my own layerBool 1 -32 and every object that is not the base layer gets a layerBool assigned to the visibility of the object, and then control the layers using scripting, this may be the route for the use of Tabs especially if the Tab GEM does not work as intended?

  hmmmm?

  • Cancel
• Andre Dicaire

  

  • 19 Aug 2024 5:04 PM

  In reply to Benji_Kidmose:

  I've experienced those same behaviors (cleverly avoiding the work "Issue" so I don't get in trouble). I agree with opening a GSC call to document and bring to attention of PE and Product manager. Assuming this is approved for a change in behavior, that will take time, so we need to work through the current behavior.
  
  First, Are you on v14 or v15. . I can confirm on v14 that the behavior is in v14. Expect any change will be in a later rev.
  
  What works...
  - Dragging a new GEM/Object into a Tab Page: The page must be in focus and the item (Datalink) from the palette will be assigned in the Tab Page.
  - Create a Graphic object. Select shape from Toolbar and click in the selected tab and item is created in the tab page.
  - Drag an item into the TAB page: Select an item in the palette view of the display, then use the mouse to drag the selected item in the display and drag it to the location in the tab page.
  - Dragging an item in the display area will not affect its assignment to the tab page.
  
  Note, to get the item into a Group in the Tag, you have to use the Context menu and Add to Group.
  
  What Doesn't Work:...
  - Use keyboard arrows to adjust position of item in Tab Page. As soon as you hit the arrow to move the item, it is moved from the Tab Page to the root of the display.
  - Setting focus to a TAB page and item from the Palette. Yes, the item is selected but focus is not set to the Tab Page, and you still have to select in multiple steps to bring focus to the page.
  
  If the Tab Page Item is in a Group, you can use the arrow keys to position the item in the group and it remains in the Tab page.
  
  The other annoying behavior is that you can't just set focus on the tab page by selecting it in the Palette view. You have to click in the display on the Tab object, then click on the Tab Page to bring that tab to the forefront. Only then can you drag items onto the Tab page.
  
  My enhancement:
  - Using the Arrows with a Tab Page item selected should simply affect the position within the container of the item, i.e. moves the object without changing its assigned container.
  
  - Selecting a Tab Page or a Tab Page item from the Palette should bring focus into the Tab Page, bringing that Tab to the forefront with the selected Item highlighted, without having to click in the display to select the Tab object and then the Tab page.
  
  This is clearly a usability issue in the Engineering environment. It is not a UDEP level enhancement. I'm hoping the product Manager will appreciate the frustration this can cause, and it gets addressed sooner rather than later.
  
  My work around is to use the mouse and direct property inputs to position items in a Tab Page, and I don't use the arrow keys. (that reminds me of Rodney Dangerfield's doctor telling him it hurts to move his arm, don't move it) . But just because I can avoid this, doesn't mean it is acceptable behavior.

  Andre Dicaire

  • Cancel
• Benji_Kidmose

  

  • 19 Aug 2024 5:33 PM

  In reply to Andre Dicaire:

  Thanks Andre, I am at V15.LTS, all those rules of standing on one foot while your left hand is in your pocket and whistling dixie just to make it work, I think I am on the path of coming up with my own "TAB" by using variables and visibility and not use what is provided as it is not in my mind "working"

  I have created really just 4 text boxes (or however many tabs you have, being a GEM I guess could add the same features of add and subtract "Tabs"  that when each is clicked it sets a Boolean variable to true and the others to false, then tie the objects on the CD to the variables, essentially the same way we do layers in Operate, its all code, and essentially the Visibility is the same. Will make the "TAB" we come up with for each scenario a GEM so that the layerBoolean# variables are on the GEM level and accessed by the Objects on the CD that are tied to the GEM. Now to decide if group all items for a layer and apply the Visibility there, or each Object that is on a layer. Decisions decisions. 

  • Cancel
• Andre Dicaire

  

  • 19 Aug 2024 6:32 PM

  In reply to Benji_Kidmose:

  Having spent years working with Operate and VBA, the move to Live has a steep learning curve in the Engineering tools. I'm wondering if you have any issues with how the Tabs work in runtime? I guess I'm not seeing these Engineering issues as being worth abandoning the TAB object.
  
  If you are going that way with a custom Tab GEM, then I'd go with a Group on all the items in a "tab" page. Each CD is a common global item used by multiple modules, You don't need to also create a GEM to assemble the parts for your Display. Each display will need a collection of GEMs with which to build each Tab Page, so I would use a Group to collect and manage the "page", and use its visibility expression to work with the TAG GEM you are creating.
  
  One of the things this would offer (like I should give you a reason not to use the Tab object) is that with a Group, you can easily assign an item using Add to Group when creating your display. like grpTab1 would show up in the Add to Group selection list, and boom, item assigned to where you want it. Note that if you create a Group in the Tab Page, you can assign a new item to that group, and have it in the tab page.
  
  Makes me thing that another enhancement to the Tab object would be an Add to Tab option in the dropdown menus. Like, treat a Tab page as a "group", because that is what it is, more or less.
  
  But are we solving any runtime issues? Or will we create some? As you said, it's all code, and we can achieve any specific display behavior with varying approaches. I suggest that if there is no Runtime issue with the Tabs (i.e. they work as advertised in Live, I would not abandon them based on these usability issues in Graphics Studio.

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 19 Aug 2024 6:54 PM

  In reply to Andre Dicaire:

  As for the Layers think, that is a big miss in my opinion. Layers were available in Operate and any customer that used them faces a re-engineering effort to compensate for the loss of functionality.
  
  I tried to create a runtime work around, which actually worked rather well, using a Layout variable as the layer and using bit wise assignments for the layers. A value of 3 sets bits 1 and 2. In my displays I would add a Layer Bit = True expression in visibility. I could "OR" that with additional visibility and avoid creating spurious groups just for visibility. I thought I was being clever.
  
  However, the other aspect of layers is to be able to use them in the Engineering tools. Being able to hide various components of all the GEMs or static objects by hiding a layer can be quite useful. Graphics Studio provide a separate Visibility icon, but that is a manual selection.
  
  Enhancement: have the Visibility feature in the palette tied to a layer, where a user can use this to assign an item to a layer and when set in engineering all set items can be hidden at once. You could set this within a GEM so that when you add items to displays, their assigned layer is already set. For runtime, add a layer visibility option, which could just be tied to the engineering one and hidden from view as it is a system feature.
  
  it's like the foundation for Layer visibility is half built into Graphics studio already, just not fleshed out.
  
  Use cases:
  -ufaciliting the selection of all lines in a display. In Configuration, I want to set colors and line thicknesses to all lines on a display of the same type, which I've assigned to the Line Layer in my library. Hide all other layers, select all, and change the common properties, Done. Otherwise, I have to select them using Cntrl Click either in the Tree or display and invariably have to make multiple edits.
  
  I want to hide all the Control connection lines (lines connecting valve and transmitter to Control Module GEM). Assign these to "Control Line Layer" and when this layer is hidden, or active all said lines dissappear or appear, with out any added visibility configuration on each line.
  
  If we added Layers, I'd want to see a layer naming tool so users don't have to remember layer numbers for their function. Assigning an item to a layer is by layer name. In runtime, a user would be able to configure different layer visibility states that set multiple layers with one command, resulting in all relative layers defined to become visible. Lots to things to do with layers

  Andre Dicaire

  • Cancel
• Benji_Kidmose

  

  • 19 Aug 2024 10:58 PM

  In reply to Andre Dicaire:

  Yes, the layers is a big miss in my opinion as well. What serious drawing program have you ever seen without layers? The issue of the missing layers is what I am trying to solve. We use Layers a lot in Operate, not just for Tabs, but also for different process states.

  The TAB supplied in Live behaves like a set of layers, with each tab being the pre-defined layer. Since its hidden cannot see what they are doing with the drawing area to hide what's on each "tab drawing area" when we click between them, must be complex as heck, or why hide it. 

  The Active X MS tabs, is what we use for "Tabs" in Operate . The MS tabs, really was just a nice set of buttons that could be added with text, and sizing etc. In reality all of the Layer interaction was just a click event off the Tab in VBA to set the active layer and turn off others, that's why I think just using variables to do the same thing with visibility. So when Live got a TAB item, it is not a replacement for the MS tabs, as the function was still scripting and VBA with layers in Operate, but was more user flexible as it really was just a nice looking set of buttons in a "Tab" The Live Tab provides a single use case for layers, when in reality there were 100's of use cases with layers.

  I think will just go the route of making my own "Tab" somehow, with simple scripts for visibility.  

  When Tab1 is clicked

  boolLayer1 = true

  boolLayer2 = false

  boolLayer3 - false

  When Tab2 is clicked 

  boolLayer1 = false

  boolLayer2 = true

  boolLayer3 - false

  and so on. Just need to figure out where all the variables live, ie. in a gem, on the context variables, or both? 

  As you mentioned, yes the object visibility tree for Selection Pane is layers right there, if we could get at those from design script and manipulation from run time then we would not be spending all this time getting this to work. Not likely anything we would see anytime soon, and once we have made a design decision and moved ahead, not likely to go back in Version XX.LTS at a later date. 

  I have spent the day playing with the Tab GEM, its not an elegant solution, and requires too much tip toeing around your objects in Design to be useful. The point you made earlier about the pain of design if it works as intended in runtime, we have a lot to build, I don't think I can stomach how it works, I think that's enough, time to move on and leave it be and come up with something more suiting, 

  • Cancel