Select value of field based on another node - InfoPath Dev
in

InfoPath Dev

Select value of field based on another node

Last post 07-03-2013 10:10 AM by Shrout1. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 07-02-2013 08:25 AM

    Select value of field based on another node

    In my attached form I am trying to set the "Sub_Node" field (which is in a repeating group) equal to the "Master_Node" field if the user chooses "No" for the "Sub Node Differs from Master?" option button. If the user chooses "Yes" then they will be able to type in their own value.

    I'm not sure if I'm having trouble with my XPath selectors or exactly what I am doing wrong, but it seems that despite my conditions evaluating as intended, I get no values in my target field.

    The only 3 nodes that matter are Master_Node, Sub_Node and Sub_Node_Checker.

    Filed under: , ,
  • 07-02-2013 07:27 PM In reply to

    Re: Select value of field based on another node

    Here's a copy of your form - I changed your default to use a substring function for this, give it a try.

    Hilary Stoupa

  • 07-02-2013 08:11 PM In reply to

    Re: Select value of field based on another node

    Wow! I don't think I *ever* would have thought to try it that way. Let me ask you a couple questions about the way you did this if you don't mind: Microsoft's sytnax for substring: substring(field, start, end) substring(Master_Node, 1, (Sub_Node_Checker != "true") * string-length(Master_Node)) I would venture to guess that if (Sub_Node_Checker !="true") (i.e. "Sub_Node_Checker = "false") returns "true" then that entire piece of the function returns as "1". If "Sub_Node_Checker" = "true" on the other hand, then that returns as "0". Because of the multiplication that takes place at the end of your expression this would cause the substring to return no characters. Does that hold true? Also, could you tell at all *why* my conditional selectors were failing to function? Strange that "../my:Sub_String_Checker" consistently returned the "true" or "false" when value used separately but when used inside of the "sub_node" field as the conditional value for selecting "Master_Node" (//my:Master_Node[../my:Sub_String_Checker = "false"]) nothing would be returned whatsoever. That boggled my mind for about 5 hours today. How can an expression evaluate to "true" or "false" and then behave as though it is returning "null" when being used as a conditional statement nested inside of a larger xpath expression? I am truly amazed by your solution! I would never have thought to implement something in that fashion; truly a tribute to your experience that such an outside-of-the-box solution would come to mind. Thanks again!
  • 07-03-2013 07:34 AM In reply to

    Re: Select value of field based on another node

     You give me waaaaaaaaaaaayyyyyyy too much credit - here's where this originated: http://blogs.msdn.com/b/infopath/archive/2006/11/27/conditional-default-values.aspx

    So - the difference (of course) between != 'true' and = 'false' is != 'true' also handles for the field being blank - I tend to prefer whatever expression will handle for the unexpected. :-)

     And yes - wrapped in parenthesis, we are getting 1 or 0, which we can multiply by the length of the string to figure out how many characters to return (all, or none...)

    I do not know why this works the way it does - I imagine the secret is somewhere in the XPath specification, but I am not able to read that without suddenly getting very sleepy.

    As to what was going wrong with your expression - I apologize. I didn't even really read it, just blew it away and used my own.

    Hilary Stoupa

  • 07-03-2013 08:16 AM In reply to

    Re: Select value of field based on another node

    Hey! I hate to come back to this but I realized a slight problem... Whenever the "Master_Node" is changed, all the fields clear (if the "Sub_Node_Checker" is equal to "true"). I believe this is due to the fact that the "Sub_Node" field recalculates on change. Since the "Master_Node" is a part of the default expression, it forces the field to re-evaluate, do the fancy "multiple by 0" trick and then reverts itself to a blank state.

     

    I tried using the pipe operator with two substring functions, but apparently InfoPath (or XPath) wants valid nodes targeted on each side (NodeA[condition] | NodeB[condition]) and isn't happy with a "substring" function. I also tried concatenating two substring functions together, but due to the self-reference and the re-calculation of the field at each change InfoPath ends up in an infinite loop (well, dies at 16 calculations).

     

    Here is my hacked together substring function:

     

    concat(substring(../../my:Master_Node, 1, (../my:Sub_Node_Checker != "true") * string-length(../../my:Master_Node)), substring(../my:Sub_Node, 1, (../my:Sub_Node_Checker != "false") * string-length(../my:Sub_Node)))

     

    Is there a way to keep the field from clearing when the Master_Node value is changed? I tried making my Pipe operator version work again, but it just doesn't want to cooperate.

  • 07-03-2013 09:50 AM In reply to

    Re: Select value of field based on another node

     Ah - I was wondering if using a default would bite us. I'll take another look later today....

    Hilary Stoupa

  • 07-03-2013 10:10 AM In reply to

    Re: Select value of field based on another node

    Lol - well, I gave it some thought over lunch and the solution is actually quite simple...

     

    I just need to use a third node. Instead of storing the "Sub_Node" value in "Sub_Node" if "Sub_Node_Checker" is "True" (I.E. the sub node value differs from the master) I just use a third node that has the exact same concatenated substring function. That way it doesn't self-reference when the value changes. I'll just publish *that* column to SharePoint (or push it into my double eval function) and it should avoid the entire fiasco.

    Thank you again for your help! You've provided me with many answers here at InfoPath dev.

Page 1 of 1 (7 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.