InfoPath Dev

Hallo,

Please the attached picture. Why does the filter not work properly in Browser Form?

The combo box uses essentially a double Eval filter, that is discussed in other posts. So I would filter out people, that already exist in the local list.

not(contains(concat(';', xdMath:Eval(xdMath:Eval(current()/preceding-sibling::my:TopicPersonReference, 'concat(@my:PersonID, ";")'), ".."), xdMath:Eval(xdMath:Eval(current()/following-sibling::my:TopicPersonReference, 'concat(@my:PersonID, ";")'), "..")), concat(';',@my:PersonID,';')))

It works perfect in Client Form.

Thanks for your replies.

Does the Design Checker have any additional information on the compatibility of your form?

I imagine that something in the formula might not supported in the browser, though on first glance I don't see what it could be. A Google search reveals similar questions around the internet, such as this one. The Microsoft page doesn't list specific functions as not being compatible, though.

If I were debugging this, I would try each of those functions separately in a browser form, to see if I can identify which one is failing in the browser (not, contains, concat, xdMath:Eval, current, preceding-sibling, following-sibling).

Thank.ernesto . you are right. that is the most effective approach. I will do that And post an update later. Best regards

I now use a different query, since the first used String compare functions in it (contains).

Here is one that checks fields:
/my:ResultProtocol/my:People/my:Person[not(@my:PersonID = current()/preceding-sibling::my:TopicPersonReference/@my:PersonID) and not(@my:PersonID = current()/following-sibling::my:TopicPersonReference/@my:PersonID)]
It says: Don't show Person nodes, that are already used in local fields before and after this one. 

I could change it a little bit more, if I want:
/my:ResultProtocol/my:People/my:Person[not (@my:PersonID = current()/preceding-sibling::my:TopicPersonReference/@my:PersonID or @my:PersonID = current()/following-sibling::my:TopicPersonReference/@my:PersonID)]

or do this:
/my:ResultProtocol/my:People/my:Person[not(@my:PersonID = current()/../descendant-or-self::node()/my:TopicPersonReference[not(@my:PersonID = current()/@my:PersonID)]/@my:PersonID)]

The Error still comes, so in my opinion it is a bug. Because one could maybe argue somehow, that string-functions are difficult to adapt into the browser-world (I have no idea). But these xpaths are much shorter, quite simple and should work.

I will just accept the bug/fact, because it has no priority and is comfort feature. Since it works perfectly well in client, the browser adaption of the preceding-sibling and following-sibling-Function must be faulty. At least I cannot see the error.

One side observation:
I like this field check a lot better, plus it should perform better, since the string would grow linearly, would it? I found that in large repating node lists (where large means more than 10 rows maybe :-)) , the infopath form would not perform any good, it would almost stop completey, if I use a ComboBox Control in every row. At first I thought it must be the string filter. But it is certainly not. I now hide the combobox as soon as a selection is made and only show a calculated value or maybe a textbox and the form is fast again.