InfoPath Dev

Strange...I just removed that action from the rules on the control and it still gives me that error.

Works as advertised, except I receive an "Unsupported Expression" error when I validate compatibility. 

Any ideas?

Same here - it doesn't appear to work in a browser-enabled form due to that unsupported expression.  I am not sure which part of the expression is unsupported, since it looks fairly plain, but I will be dissecting it to find out.

Actually, I just double-checked, and I'm NOT getting my error relative to that action.  My unsupported function is the first action of the first fCounter rule that sets the AccountName parameter of the UserProfileService query.  My design checker is telling me that this expression is not supported in the browser (it works great in rich client, though):

../my:replyToControl/my:Person[number(/my:myFields/my:fCounter)]/my:AccountId

The full error message is this:

The following expression could not be parsed because of a syntax error or because it uses an undefined namespace prefix or unsupported function:  ../my:Requestor/my:Person[number(/my:myFields/my:Counter)]/my:AccountID.

The field names of my data elements are different on purpose, but it's the same syntax otherwise.  It works perfectly and puts each email address separated by a semicolon in my LinkToEmail field.  It just will not validate against the SharePoint server and even though I can publish, it will not open in the browser due to this unsupported expression.  If I remove this action, the error goes away, but of course it doesn't work.  Interestingly, though, this means that the 3rd action in that list with the concatenation does NOT give me an error like WSU54...

For some reason I cant test web enabled form. Anyway, could you please try that XPath:

../my:Requestor/my:Person[0 + /my:myFields/my:Counter]/my:AccountId

Will you get the same error?

While troubleshooting Alec's solution, we stumbled across another method (i.e. using EVAL instead of CONCAT), check it out:

http://blogs.msdn.com/infopath/archive/2006/04/05/569338.aspx

Check it out...it is another (simpler) method for those looking to enable this type of functionality via browser-based forms.

Alec,

Sebastian was able to find this article http://blogs.msdn.com/infopath/archive/2006/04/05/569338.aspx that accomplishes the same goal with much, MUCH less work and complication.  Using the eval function seems to be a better way to go, because the eval function is built to do everything you did with your custom steps.  What you came up with was brilliant, but it appears the eval function already does all that stuff for us when nested within itself.  Here are the basic steps using this eval function:

1. Incorporate Contact Selector into your form
2. Create a single text data element to store your list of email addresses (same as the HLinkToEmail field in Alec's solution)
3. Simply set that field to default to this Xpath expression: xdMath:Eval(xdMath:Eval(../my:Requestor/my:Person, 'concat(my:AccountId, ";")'), "..")  In my case, Requestor is my name for replyToControl.

This is all you need to do!  You can then promote the HLinkToEmail property and use it in SPD workflows or whatever else.  It takes the string of concatenated, semicolon-separate AccountIds, converts them to the relevant emails, and sends the email perfectly.  This does not require you to setup the UserProfileService (although I still always use it but for other things), and does not require you to retrieve the actual email in order to send emails to those people.  It can't get much simpler, imo.

I believe everything is fixed now. Web-based forms are OK. Check my updated blog.

http://alecpojidaev.wordpress.com/2008/12/16/infopath-codeless-programming-walkthrough/

I still prefer to send email via InfoPath (submit to email) to eliminate workflow part. 

Thanks for 

xdMath:Eval(xdMath:Eval(../my:Requestor/my:Person, 'concat(my:AccountId, ";")'), "..") 

That thing really does the trick.

I have tried doing your 3 steps warrtalon:

 1. Add contact selector

- It is working properly.

2. Create a single text data element to store your list of email addresses

 Should this be a Field (element) or a field (attribute)?

3. Set that field to default to the Xpath expression.

 - I copied the XPath expression and changed "Requestor" to "gpContactSelector" (the name of my folder).  When I hit "verify formula", I get this error:

msxml5.dll
Reference to undeclared namespace prefix: 'my'.
Error occurred during a call to property or method 'Eval'.

I have tried a few other combinations.  I get errors saying that the apostrophe around 'concat(...)' was unexpected or the ";" expression argument is unexpected.  When I change the ";" argument to say a letter, the forumla went through.

Is there anything that you see that I may have done incorrectly?  I'd appreciate the help.

Copy and paste your exact Xpath expression.  You have to be very careful when copying and pasting things like apostrophes, commas, and quotes, because they get messed up in translation sometimes.  The "my" namespace error may be due to you having a different schema, but I'd need to either see the XSN itself, a screenshot of your myschema.xsd + the Xpath statement, or at least a screenshot of your main data source pane in InfoPath plus the Xpath statement.

1. Incorporate Contact Selector into your form
2. Create a single text data element to store your list of email addresses (same as the HLinkToEmail field in Alec's solution)
3. Simply set that field to default to this Xpath expression: xdMath:Eval(xdMath:Eval(../my:Requestor/my:Person, 'concat(my:AccountId, ";")'), "..")  In my case, Requestor is my name for replyToControl.

I have got the forumula to compile without errors.  Now, what is happening is that HLinkToEmail stores a ; by default and then when a contact is selected, it concatenates the AccountID with the ; (e.g. "AccountID;").  If I have 2 contacts selected, it displays the first contact's AccountID twice delimited by commas. 

Are these the correct return values?  If so, how can I get e-mail addresses using it?  Here is a screen of my data source:

http://www.freeimagehosting.net/uploads/fdc233e2fe.jpg

Thank you for your help warrtalon.  The only things I followed in this example were your 3 steps.

Well, it definitely works if you get it right.  I would have to troubleshoot your XSN directly to figure out what is still wrong.  It's easy to get the statement to compile without it actually being 100% right, since we're using so many contatenated items.  I will review your statement later, but I probably need to see the XSN to verify that each piece of the statement is exact and doesn't just look right.  Attach the XSN if you can...

Thank you so much warrtalon.  I attached my .xsn to this post.  I am getting close to being done with this form, so your timeliness is much apprecaited.

Heh, well, I'm headed to work, and this is on my free time, so bear with me.  If you can get Alec Pojidaev to help right away, then it might be worth a try.  You can see a link to his blog on my blog (right-hand side).

That is quite alright warrtalon, I was surprised I was getting any help at all.  Thanks again.  Oh and I won't be able to access Alec's blog from work as the site is blocked unfortunately

I am still having the problem with my HLink ToEmail variable, which is only storing the AccountID of the first person selected.  I attached my .xsn 1 or 2 posts back if someone would like to take a look at it.  Your time is much appreciated.