Emerson Exchange 365

• Not Answered

DeltaV Live : Resize contextual display online

I would like to resize a contextual display in DVLive in Online mode.

 

Used the parameter Dsp.Height.Pt to set the height.

Can see the height of the visible content of faceplate is reduced, but the window in the original size of the faceplate is still visible.

 

If I try to increase the height, it does not have any effect.

 

Is there any other method to achieve this.

 

 

 

Regards,

Navin Singh

Navin Singh

• 12 Aug 2022 1:45 PM
• Cancel

5 Replies

• Matt Stoner

  

  • 12 Aug 2022 2:21 PM

  Changing the display size at runtime is NOT supported like Operate, You will have to define the picture size you ultimately want to support but you can do some things with zoom settings of the display. For example we use to have a single display in operator that changed depending on options that were required, this got migrated to multiple live displays and we open the correct one from the logic to ensure the display is the "correct" size but this wasn't a Faceplate so it was easy to do.
  
  What are you trying to do, just remove the "grey" space in your example?

  • Cancel
• Navin Singh

  

  • 15 Aug 2022 10:36 AM

  In reply to Matt Stoner:

  Hello Matt,

   

  Thanks for the response.

  The faceplate is an example of context display resize.

   

  My requirement is to set the visibility of different groups within the detail faceplate based on user selection.

  Since each group is of a different size would like to resize the picture size.

   

  Is there a workaround to achieve this?

   

  

  Regards,
  
  Navin Singh

  • Cancel
• Matt Stoner

  

  • 15 Aug 2022 2:55 PM

  In reply to Navin Singh:

  Since you can't resize at runtime, I would suggest doing 1 of two things, putting the script on the FP detail button to open the selected detail based on contextual menu or creating a detail that uses Tabs for each of the items. The script option would allow the user to pick the associated detail wanted when clicking the Detail button on the FP and then the module could assign any of those details as the detail to pull up from other locations.

  The Detail Button default is a Gem and a sample script to do this would be as follows:

  //Right click context menu options to open Detail Displays
  let options = {
  ['Option1 Text']: DL.DN('Detail_DIsplayName1'),
  ['Option2 Text']: DL.DN('Detail_DIsplayName2' + ',BLOCKNAME'),
  ['Option3 Text']: DL.DN('Detail_DIsplayName3')
  };

  let region = await DL.GetDisplayElementRegion(Gem.grpDetailsCallup);
  let pos = new Types.Placement({
  Option: Constants.PlacementOption.Default,
  Region: region,
  UseCachedPosition: true
  });
  let key = await DL.ShowContextMenuAsync(...Object.keys(options).sort());
  if (!key) return;
  let selectedoption = (<any>options)[key];
  let displayname = (selectedoption).split(",")[0];
  let blockname = (selectedoption).split(",")[1];
  // Open Detail Display if exist
  if (DL.DisplayExistsAsync(displayname)){
  await DL.OpenContextDisplayAsync(DL.DN(displayname),modulename,[pos],blockname);
  }

  The 'Option# Text' is what the operator will see/select and I also showed an example for Option2 that needs a blockname for the detail. If you don't need this you can remove that logic, remove the red text.

  The Tab option would be similar to what you have now except you would use 'Tab' object under Data Palette but this option would require the display to support the largest area needed where the individual details would allow for smaller display size and probably be used for multiple module types.

  • Cancel
• Andre Dicaire

  

  • 15 Aug 2022 11:09 PM

  In reply to Matt Stoner:

  The size of a pop up window is defined by the size of the picture being opened relative to the size of the monitor as defined in the layout. As Matt points Live does not provide access to the Windows level properties.
  
  Apart from the fact you cannot define the window size of the picture programmatically, managing the size of the window separately from the size of the picture seems to be something that would have long term support issues. By using separate pictures of different size, you don't have to worry about the window size logic being updated to adapt to a change in the picture sizes. Also, in Live, hiding part of a picture does not change the size of the picture. If you then resized the window height, the picture would become smaller and still show the area that is hidden, with letter boxing on the sides. You would need to zoom the picture to create a smaller window with the reduced portion of the picture visible.
  
  The Open Faceplate function opens the Faceplate defined in the MOdule Display properties. There is only one such faceplate defined. However, you can read the IDISP parameter of the module to read the default faceplate configured on the module, and from there use this to create supplemental faceplate file references. i.e. the default is called Loop_fp. You can create a second FP called Loop_fp_A. Then, in your open faceplate script, you can set which picture to open.
  
  The default OOB SG_FRAME places the Interactions in three locations: Hotspot box, Alarm Box and Status box groups. If you follow the FP_mini approach, you can use the default FP name to name your additional FP(s) and be able to call them up from the main faceplate. That will avoid having to change the default SG_FRAME interaction logic.

  Andre Dicaire

  • Cancel
• Navin Singh

  

  • 17 Aug 2022 8:53 AM

  In reply to Andre Dicaire:

  Hello Matt and Andre,
  
  Thanks for the answers and code.
  
  Based on it, I can create different detail displays for each group and open them from the main detail display.
  
  I will let you know if I have any questions.

  Regards,
  
  Navin Singh

  • Cancel