GlideDialogWindow setSize and removeCloseDecoration on Fuji

kenny_vl1 · ‎11-02-2015

An onLoad catalog client script was created, which calls a dialog window.

function onLoad() {
   var dialog = new GlideDialogWindow("sc_cat_item_disclamer"); //create "Terms and Conditions" dialog window
   dialog.setTitle(getMessage('disclamer_title')); //Set the dialog title
   dialog.setSize(600,600); //Set the dialog size
   dialog.removeCloseDecoration(); //remove the close cross from the dialogwindow
   dialog.render(); //Open the dialog
}

I included the setSize method for future compatibility with Fuji.

In Eureka, I don't see the 'CloseDecoration' and the sizes are set as defined in the script. Just as expected.

In Fuji environment I am seeing the CloseDecoration and only the width is being adjusted according to the setSize. The height does not change. This is not at all what I expected.

It seems that the removeCloseDecoration is not working and neither is the height parameter from the setSize method.

function onLoad() {
   var dialog = new GlideDialogWindow("sc_cat_item_disclamer"); //create "Terms and Conditions" dialog window
   dialog.setTitle(getMessage('disclamer_title')); //Set the dialog title
   //dialog.setSize(600,600); //Set the dialog size
   dialog.setWidth(600); //Set the dialog width
   dialog.setHeight(600); //Set the dialog height
   dialog.removeCloseDecoration(); //remove the close cross from the dialogwindow
   dialog.render(); //Open the dialog
}

I have tried splitting up the width and height methods for testing purposes, but now the dialog window just keeps loadin and doesn't render.

When I remove the height, the dialog window renders fine.

Has anyone else already experienced similar behaviour? I am thinking this could very well be a bug in Fuji.

ChrisBurks · ‎11-03-2015

The ui_multiline_input_field is a textarea element. Whether using ServiceNow or any webpage it needs to have a size setting placed on it. By default a textarea element renders in a fixed sized. Unlike a div it doesn't change its size based on the text content within it. The size has to be set or scripted to dynamically grow.

So you have to take that into consideration when using a textarea in combination with a table element. Although a set size is placed on a table the cells within a table by default grows in size based on it's content. If a textarea is the only element used within a table cell then the table cell's size is based on the textarea's dimensions. And it's default padding and margin properties. All elements have a default padding and margin size.

If you're on Eureka I would try leveraging some of the bootstrap styling that the ServiceNow platform provides. Or try displaying your text in the table cell without the ui_multiline_input_field.

Tables are an easy way to organize the display but since bootstrap is on the platform there are more modern ways to get a nice visual display.

I hope that helps.

View solution in original post

kenny_vl1 · ‎11-03-2015

I get what you are saying and I don't want to give anyone a hard time by persisting on this, but I prefer to keep it as simple as possible for any future developers that would look at my code.

Therefore, I still prefer to use the setSize for this matter, as described in the GlideDialogWindow API: GlideDialogWindow API Reference - ServiceNow Wiki

Kalaiarasan Pus · ‎11-03-2015

I leave it upto you to decide the future course on this. But creating a HI ticket wouldn't be bad idea either.

Until then, you do have the workarounds to get through this.

Kalaiarasan Pus · ‎11-03-2015

Add this to your UI page's HTML part.

addLoadEvent( function() {

onLoadFunction();

});

</script>

Define the onLoadfunction in the client script of UI page.

Read the preference value in the client script using

"${RP.getWindowProperties().get('selectedRecord')}"

kenny_vl1 · ‎11-03-2015

This would be to pass the size through setPreference, right?

Kalaiarasan Pus · ‎11-03-2015

It is similar to passing any parameter to the page. But you will need to check it if it actually works or not. Else you would have to live with the hardcoded value in the UI page for now.