- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 04-24-2019 02:57 PM
I just had to set some fields in a form opened via GlideModalFormV3, all answers found seems to be outdated or at least not working in scoped application on the madrid release. So I thought I share my findings if somebody else stumbles across that problem.
It seems this was the old way to do it, but apparently in madrid the window object is null in the onLoad Callback Function.
var d = new GlideModalForm("Create Problem", "problem");
d.setOnloadCallback(onLoadCallbackFn);
d.setSysID(-1);
d.render();
function onLoadCallbackFn(oGlideModal) {
//window is null
var oModalGForm = window.frames["dialog_frame"].g_form;
}
After some trial and error I found out that the parameter of the callback function has a $window variable, this can be used to find the g_form of the opened ModalForm.
var d = new GlideModalForm('Problem', 'problem');
d.setOnloadCallback(onLoadCallbackFn);
d.setSysID(-1);
d.render();
function onLoadCallbackFn(modalForm) {
//This works in madrid (at least in a scoped app, didn't test it in global scope)
var iframe = modalForm.$window.find("#dialog_frame")[0];
var iframeWindow = iframe.contentWindow ?
iframe.contentWindow :
iframe.contentDocument.defaultView;
var d_form = iframeWindow.g_form;
}
EDIT:
Just found out if you just want to set field values you can also use "sysparm_query", didn't try it out yet. But I thought this also is worth sharing.
var d = new GlideModalForm("Problem", "problem");
d.addParm("sysparm_query", "short_description=TestSetField"); // populate fields
d.setSysID(-1);
d.render();
- 1,743 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
It worked like a charm. As you said old answers found seems to be outdated.
Thank you Martin.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I know this post is a bit older, but I was experiencing the same problem and it came up in a search. I had a case where one UI action was working and one was not and couldn't figure out why until this bit of knowledge came back to me. I always forget this, but by default now ServiceNow sets the "isolate script" value on UI actions to "true". That includes cases where you copy an existing UI Action via Insert or Insert and Stay! The isolate script option prevents scripts in UI actions from interacting with DOM elements in the browser. Your method seems to circumvent that, but straightforward attempts to access many things through window.[] will fail when isolate script is enabled.
If you want to use window.frames["dialog_frame"] directly, you will need to disable the "isolate script" field on that UI Action. Use caution when doing this though, by disabling isolation you can create UI Actions that interfere with each other or other scripts and elements on the page. Pay close attention to how you define your action name, function names, and variables to make sure you don't collide with other scripts/variables.
Your workaround method might actually be better though. From what I can tell, it might avoid some of those pitfalls I listed above as you are very specifically locating and pulling a certain element without everything else in your UI Action being in that broader scope. Thanks for posting this for us future developers!