Per Nintex Inline Function definition, inline functions evaluate only at time of initial form load and do not refresh or update upon changes during form runtime.
So, the behavior in your case may vary, depending on whether you are entering in New Mode or Edit Mode. In New Mode, there is no item Location available, so the assumption is your condition statement would always resolve to false, thus "View2". In Edit Mode, since there is an item value in Location, your condition statement might be expected to work.
Does the above agree with what you are experiencing?
Regards,
Tim
I created Calculated Value control to see what is stored in Location control and it has the value as per selection but the view is not being applied. Even if the value was empty I would still expect to see View2 but instead default view is visible.
@Mikekolt do you just try to bump your posts count?
This version of the formula works:
fn-If(fn-Equals(Location,"A"),"View1","View2")
Maybe someone else can explain why this variation of the syntax works. I didn't see anything obviously wrong with your statement. Just tried the above variation for fun and it worked.
HOWEVER, this is only a partial victory. Please understand that as an inline function this still only fire at initial form load. Thus, here is the behavior you can expect:
1) New Mode - no value exists in the SP list Item Property of Location at the time the form is loaded, so the formula will resolve false and you will get View2.
2) Edit Mode - the value of Location will exist for the item selected in the list prior to clicking Edit. Thus, the formula will resolve correctly and as expected, View1, if editing a list item with Location A and View2, if editing a list item with any Location other than A.
Your calculated value control is returning the value of the Location in the Location CONTROL. Calculated fields do update during runtime, when there is a change on the form. However, the value of the item property does NOT change during runtime. Item property values are exchanged with the form only two times, upon initial form load (edit and display) and upon form save (new and edit).
So, think the above will work for you for edit purposes. However, if during the editing the user changes the value of Location, this will NOT change the lookup view after what was captured at initial form load.
One possible solution to your issue that I can think of:
Install two different list lookup controls on your form, one hardcoded with View1 and the other hardcoded with View2. Create a rule for each to hide the lookup you don't want, based on the Location value selected in the choice field. To avoid having both or neither lookup show on the form in New Mode, you could put a default value in the choice control, so the rules would always put one or the other lookup in place.
Good luck!
Curious about your goal with the two views? I am only aware of using alternate views in this way when trying to achieve multiple filters (one filter in the Nintex control for list lookup and any additional filtering done via the list view).
The functionality you described makes me wonder if you could achieve your goal with having your SP list setup with a lookup column and have that drive cascading lookups on the Nintex form. This lookup approach functions in runtime and will alter the selections available based on a form choice selection as you describe. Sorry for the bother if this is something you already know and can't use in your scenario.
@Rudixx what if you use nested If statement. First check if it's a new mode, if it's then create a view for new mode in your list and use it here. If it's edit mode then using and function you can apply location based views.
@TS13
Thank you for your extensive response. I appreciate the time you took to get back to my query.
I originally tried to set up two different controls with hardcoded views and a rule to hide them based on Location control but the problem is that the answer from those controls is required therefore when one of the control is hidden, Nintex won't let the user submit the form because the hidden control is unanswered.