Help with client script to hide section on form

dalewechsler · ‎06-27-2017

I've read many posts about this and followed SN Guru posting about this as well. I've tried several versions of the script below and it still won't work:

This is an onChange client script - supposed to hide a section unless Category = XVALUE. Here's my script (info messages are just so I can see what the script is doing). What have I done wrong? The section will not be hidden - shows no matter what. I've also tried as onLoad script - still no dice. Any help greatly appreciated! The info messages, btw, behave as expected. The section will not hide though.

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

if (isLoading || newValue === 'XVALUE') {

return;

}

//Type appropriate comment here, and begin script below

var sections = g_form.getSections();

var val = g_form.getValue('category');

g_form.addInfoMessage(val);

if (val == 'Firewall'){

g_form.addInfoMessage('Show ' + val);

g_form.setSectionDisplay('firewall_info', true);

}

else{

g_form.addInfoMessage('Do not show ' + val);

g_form.setSectionDisplay('firewall_info', false);

}

vinothkumar · ‎06-27-2017

Hi Dale,

Simple suggestion is to create a UI policy and add the condition if the change type is so and so and in the UI policy add the variables and make it mandatory true and check reverse if false is checked. So obviously these fields become mandatory false and this client script will also execute.

Or in the UI policy script itself you can write a script execute if true to make the fields mandatory and section visible and in the execute if false, make them mandatory false and make the section visibility as false

View solution in original post

Dave Smith1 · ‎06-29-2017

Dale Wechsler wrote:

It worked really quite well - was surprised how easy it was compared to the client scripts, neither of which (onLoad or onChange) worked the way I wanted.

You've now experienced - firsthand - reasons why UI Policies, Data Policies, ACLs etc exist: to impose logic and control without the need for scripting. It's the way in which additional platform flexibility can be utilised without the requirement of coding skills, and one of the reasons why the platform is so appealing to business roles: it's opening customisation features to them without the steep learning curve of programming or learning another tool (like SharePoint Designer, Visual Studio etc)

Not everything can be done with UI Policies, but a general rule of thumb is "mouse first, keyboard second" - i.e.: try to build controls using the tools available before resorting to scripting. UI Policies are also favoured over scripting because there's less work during upgrades - more can go wrong with custom scripts when changes are applied, but UI Policies tend to be a known entity.

Dale Wechsler wrote:

Not sure whose answer to mark as the correct answer because all was very helpful.

For guidance:

review your original question and mark the one response that you believe actually provides the right answer (which you've done) - this will then make your post display an "answered" icon
mark additional responses "helpful" if you believe they contain useful information for reference purposes
use "like" on additional responses that you believe are worthy of praise, but may not contribute to the overall solution

Each of these actions "rewards" posters for their contribution, with "answered" being the highest value (10 points?), helpful being intermediate (5?) and "like" being a penny. (I can't recall these values off the top of my head - they're shown on your profile somewhere)

When deciding between "helpful" and "like" I normally compare the quantity of effort the poster afforded to the response, e.g.:

a verbose explanation with screenshots and directions = helpful
a link to documentation site or terse single-liner direction = like

Rewarding contributions (in the way you have) encourages others to participate and keep the community going, so thanks for your recognition - and welcome to the community!